У меня запущен и работает кластер Cassandra с двумя узлами, и я выполняю построенные запросы CQL через API драйвера python. Я провожу модульное тестирование серии моделей, которые я создал, чтобы абстрагироваться от большей части API Cassandra для простоты использования другими разработчиками. Все мои тесты проходят успешно при тестировании на кластере с одним узлом, но после добавления еще одного узла тесты совершенно несовместимы, либо не работают, выдают ошибки, либо проходят с минимальной рифмой или причиной.
Я сравниваю объект, вставленный в Cassandra, и объект, полученный в результате запроса Cassandra с помощью self.__dict__ == other.__dict__, поскольку я заполняю поля класса на основе значений столбцов, полученных от Cassandra.
Я считаю, что изолировал проблему. На моем начальном узле:
cqlsh:mykeyspace> select id,created_at from users;
id | created_at
----+--------------
10 | 139621386780
11 | 139621386780
8 | 139621386780
7 | 139621386780
6 | 139621386780
9 | 139621386780
12 | 139621386780
(7 rows)
На моем втором узле:
cqlsh:mykeyspace> select id,created_at from users;
id | created_at
----+--------------
8 | 139621370181
7 | 139621370181
9 | 139621370181
(3 rows)
, где первый столбец — целочисленный идентификатор, а второй столбец — объект Python datetime. Я считаю, что происходит то, что когда я вставляю строку в users, строка вставляется либо в первый, либо во второй узел, но когда я пытаюсь получить этот объект обратно из Cassandra, я читаю с узла, отличного от того, который я только что вставил, так как Cassandra это позволяет. Однако, если у меня есть consistency_level=ALL (что для моих вызовов CQL Python), не должен ли я получать самые последние данные строки, а не строку из вставки, предшествующей самой последней?
Обновлять
Обратите внимание, что уникальные идентификаторы намеренно удалены.
На начальном узле:
$ nodetool status
Datacenter: 243
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN IP Address 0 136.47 KB 256 100.0% ownsuuid 58
$ nodetool gossipinfo
/IP Address 0
HOST_ID:ownsuuid
SCHEMA:schema
RPC_ADDRESS:0.0.0.0
RELEASE_VERSION:2.0.4
STATUS:NORMAL,-1102599059356328037
SEVERITY:0.0
RACK:58
LOAD:150498.0
DC:243
NET_VERSION:7
/IP Address 1
SCHEMA:schema
HOST_ID:ownsuuid
RPC_ADDRESS:0.0.0.0
RELEASE_VERSION:2.0.4
STATUS:NORMAL,-1102599059356328037
SEVERITY:0.0
RACK:181
LOAD:148937.0
DC:241
NET_VERSION:7
На другом не начальном узле:
~$ nodetool status
Datacenter: 241
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN IP Address 1 145.45 KB 256 100.0% ownsuuid 181
$ nodetool gossipinfo
/IP Address 0
STATUS:NORMAL,-1102599059356328037
LOAD:139743.0
RELEASE_VERSION:2.0.4
RACK:58
SCHEMA:schema
SEVERITY:0.0
NET_VERSION:7
HOST_ID:ownsuuid
RPC_ADDRESS:0.0.0.0
DC:243
/IP Address 1
STATUS:NORMAL,-1102599059356328037
LOAD:164405.0
RELEASE_VERSION:2.0.4
RACK:181
NET_VERSION:7
SCHEMA:schema
SEVERITY:0.0
HOST_ID:ownsuuid
RPC_ADDRESS:0.0.0.0
DC:241
