Несоответствие данных после миграции Cassandra с использованием NetworkTopology

У нас есть кластер Cassandra, работающий на AWS EC2 с 4 узлами в кольце. Мы хотели перенести всю среду в Azure. Мы использовали этот процесс для добавления нового центра обработки данных (Azure) к нашему существующему центру обработки данных (AWS EC2) и использовали стратегию NetworkTopology и GossipingPropertyFileSnitch.

После добавления нового центра обработки данных мы выполнили приведенную ниже команду на всех узлах в новом центре обработки данных. #nodetool восстановить -- "имя центра обработки данных"

Общий объем данных на всех узлах в существующем центре обработки данных составлял около 3 ТБ. Потребовалось около 6-7 дней, чтобы восстановить новый центр обработки данных, и однажды system.log сказал, что все сеансы завершены. мы проверили размер базы данных на каждом узле в новом центре обработки данных и обнаружили, что все 4 узла имеют меньший размер (около 75 ГБ каждый, т.е. всего около 300 ГБ), чем в существующем центре обработки данных.

Может кто-нибудь, пожалуйста, дайте мне знать, если это правильный способ проверить, совпадают ли данные в новом центре обработки данных с существующим центром обработки данных.


datastax cassandra-2.1
person Vivek Soni    schedule 12.10.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Размер данных не является правильным способом проверки несоответствия данных.

Размер может варьироваться по разным причинам, некоторые из них я могу придумать:

  1. Уплотнение: Каковы ваши стратегии уплотнения? Были ли ваши данные неизменными в приложении? Если да, то причина не в уплотнении, иначе может быть.
  2. Flush: Вы очищали узлы перед проверкой этих размеров? Если нет, то некоторые данные могут быть в memtables.
  3. Каковы размеры кэша ключей и т. д.? Как вы точно рассчитали размер данных? Был ли это простой «ду» в каталоге данных ИЛИ отдельные файлы таблиц, объединенные вместе? Поскольку каталог данных содержит индексные файлы, фактические данные в таблицах и т. д. Опять же, это неправильный способ сделать это.

Я предлагаю сначала посмотреть количество строк в каждой таблице. Убедитесь, что все настройки одинаковы для обоих контроллеров домена. Затем напишите искровое задание для проверки согласованности (через контрольную сумму или отдельные поля, контрольные суммы могут быть быстрее). Убедитесь, что задание искры работает оптимально и без перетасовки данных, оно должно работать и давать результат через несколько часов.

Примечание. Это лучшее, что я мог сделать, не зная подробностей.

person Sreekar    schedule 12.10.2016