У меня есть кластер cassandra из 2 узлов с коэффициентом репликации 2 и AutoBootStrap=true. При запуске все хорошо и оба узла видят друг друга. Назовем эти узлы А и В.
- Добавьте набор ключей и столбцов (давайте назовем этот набор K1) в cassandra через узел A.
- Подключитесь к узлу A и прочитайте набор K1. То же самое на узле B. Успех — хорошо
- Убить процесс Cassandra на узле B.
- Добавьте набор с К2 по А.
- Соединитесь с узлом A и прочитайте набор K2. Хорошо
- Перезапустите процесс Cassandra на узле B.
- Попробуйте прочитать все ключи из B... установите K1 в наличии, установите K2 в состоянии MISSING. (Даже через 30 минут)
- Добавьте K3 к A/B.
- Читать все ключи из A - возвращает набор K1, K2, K3
- Прочитать все ключи из B - возвращает набор K1, K3.
B никогда не синхронизирует набор K2... (Прошло более 12 часов) Почему узел B не видит набор K2... кто-нибудь знает?
Добавлена информация:
Хорошо ... это была проблема. По умолчанию для read_consistency_level установлено значение 1.
Поэтому, когда мы запрашиваем у узла B набор K2, а у него его нет (когда он должен быть из-за коэффициента репликации = 2), он немедленно возвращается с ошибкой «Не найдено».
Однако, если мы используем согласованность чтения для QUORUM или ALL, тогда B вынужден запрашивать A, который затем возвращает правильное значение, а B синхронизирует этот ключ (сохраняет его локально).
Это приводит к другой проблеме. Это означает, что когда появляется узел B, он не синхронизирует все данные с узла A даже спустя долгое время. Теперь, если узел А выйдет из строя, как мы сможем получить доступ к этим несинхронизированным данным? (Я только что проверил, что мы не можем)
Я думаю, должен быть способ принудительно синхронизировать данные. Я вижу INFO в выходных данных терминала о том, что передача 15 строк из A в B произошла, когда B появился, но B не имеет этих строк локально (потому что мы все еще не можем прочитать их из B с уровнем согласованности ONE). Что тут происходит?
