tldr公司;一张table仍然无法打开 system_schema.tables
已包含表中相应的记录
我试着同时使用Cassandra。Cassandra版本: [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native protocol v4]
我有两个python脚本使用 cassandra-driver==3.16.0
对于在不同进程中运行的消费者和生产者。
当生产者创建并填充表时,使用者将等待直到使用运行cql语句的python脚本创建表:
table_exists = False
while not table_exists:
cql = SimpleStatement(
"SELECT table_name FROM system_schema.tables WHERE keyspace_name = 'test_keyspace' AND table_name = 'test_table'"
)
results = cassandra_session.execute(cql)
table_exists = bool(results.current_rows)
在语句结果至少有一条记录之后,我得出一个结论,即表已经创建,并尝试用 SELECT
:
SELECT * FROM test_keyspace.test_table WHERE ...
但有时,我会犯一些非常恼人的错误:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/threading.py", line 916, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.6/threading.py", line 864, in run
self._target(*self._args,**self._kwargs)
File "/stress.py", line 128, in runner
for r in select(TEST_KEYSPACE, table_name):
File "/stress.py", line 63, in select
results = cassandra_session.execute(statement)
File "cassandra/cluster.py", line 2171, in cassandra.cluster.Session.execute
File "cassandra/cluster.py", line 4062, in cassandra.cluster.ResponseFuture.result
cassandra.InvalidRequest: Error from server: code=2200 [Invalid query] message="unconfigured table test_table"
根据这些信息,我发现select语句在使用尚未创建的表执行时会发生错误。那么一会儿呢 system_schema.tables
已包含有关该表的记录,该表尚不可访问。
也许有更可靠的方法来检查表的可访问性?还是常见的解决方法?
1条答案
按热度按时间tv6aics11#
对于单节点cassandra设置,我看到了结构上的变化,不会立即传播。i、 e.创建一个表,然后插入其中,插入失败,因为该表不存在。然后检查表是否存在,它是否存在。然后,因为一段时间过去了,插入工作。
使单节点cassandras行为一致的唯一方法是在每次结构更改后引入一秒钟的等待。我觉得这很好,因为单节点cassandras只在本地开发场景中使用。在生产环境中,我只是禁用等待。