Репликация VoltDB

1 Как работает репликация

replica - "живая" и постоянно обновляемая копия БД.

K-safety обеспечивает резервные копии партиций, что защищает кластер от сбоев отдельных его узлов.

replica может использоваться:
  • для разгрузки (Offloading) read-only объемов работ, подлежащих выполнению (workloads), таких как отчётность (reporting);
  • как оперативный резерв (hot standby) в случае аварии master-а.
DR agent работает следующим образом:
  1. запрашивает у master-а завершенные транзакции и применяет их на replica;
  2. отслеживает процесс репликации и сообщает о возможных ошибках.

DR agent лучше разместить на том же сервере что и replica, это снизит тормоза. Но лучше всего разместить DR agent на отдельном сервере, но в непосредственной близости от replica.

replica создается путем запуска БД действием create и флагом --replica.

Алгоритм активации (promoting) replica в качестве master:
  1. убедиться в том что master не доступен (мы же не хотим две живые копии одной БД), а если master доступен, но не работает должным образом, то нужно его выключить (shut it down);
  2. остановить DR agent, если он еще не остановлен;
  3. активировать режим master на replica командой voltadmin promote
  4. сделать redirect клиентских приложений на новый master.
Не гарантируется что содержимое master и replica идентичны в любой момент времени. Некоторые завершенные транзакции на master могут не быть воспроизведены на replica. Придется выбирать из двух зол: либо потерять одну или несколько транзакций и активировать режим master на replica или простаивать ожидая восстановления master-а с помощью command log-a .



2 Репликация на практике

Допустим master-сервер это будет serverA, а replica-сервер это будет serverB.

2.1 Запуск репликации

Шаг 1. Запустить master:
$ voltdb create catalog.jar \
    -d deployment.xml \
    -H serverA \
    -l license.xml \
    --externalinterface=10.11.169.10 \
    --internalinterface=10.12.171.14
Вместо create может использоваться recover. Обязательно нужно указывать какие интерфейсы сервер использует для внутренних и внешних коммуникаций.

Шаг 2. Создание replica БД:
$ voltdb create --replica catalog.jar \
    -d deployment.xml \
    -H serverB \
    -l license.xml
На replica должны быть:
  • та же самая версия VoltDB;
  • тот же самый каталог;
  • то же самое количество серверов;
  • то же самое значение sites per host;
  • то же самое значение K-safety;

Шаг 3. Запуск DR-агента:
$ dragent master serverA:6666 replica serverB:23232

2.2 Остановка репликации

Чтобы остановить репликацию достаточно остановить процесс DR agent или остановить БД replica.

Более аккуратный способ:
  1. поставить master на паузу (voltadmin pause), БД перейдет в admin mode и остановит клиентскую деятельность;
  2. дождаться (см. мониторинг) когда все транзакции пройдут через DR agent и остановить его;
  3. остановить replica БД (voltadmin shutdown);
  4. снять master с паузы (voltadmin resume).

2.3 Активация master на replica

  1. остановить DR agent;
  2. выполнить на replica БД команду: $ voltadmin promote --host=serverB

2.4 Мониторинг репликации

При репликации в master БД в памяти создаются очереди данных, а если не помещаются то выгружаются по пути voltdbroot/dr_overflow

Есть два способа мониторинга:
  1. сообщения в консоли;
  2. выполнить на master-e хранимую процедуру @Statistics, которая выдаст информацию о текущей очереди репликации (The "DR" keyword returns information about the amount of replication data currently in memory (waiting to be sent to the agent). One VoltTable reports the amount of memory used for queuing transactions and another reports on the current status of any snapshots (if any) waiting to be sent.).
Сообщения в консоли можно перенаправить:
$ export LOG4J_CONFIG_PATH="mylogconfig.xml"
$ dragent master serverA replica serverB

2.5 Перезапуск репликации в случае ошибок

  1. * остановить DR agent;
  2. * shutdown и restart для replica БД;
  3. если master не запущен то сделать для него restart;
  4. * restart для DR agent-a.
* - обязательно

Перезапуск надо делать в следующих случаях:
  • остановка replica БД;
  • остановка master БД;
  • остановка DR agent;
  • If communication between the master and the DR agent is delayed to the point where the master cluster's replication queues overflow.
  • If any transaction replayed on the replica fails. Note that only successfully completed transactions are sent to the replica. So if a transaction fails, the replica is no longer in sync with the master.
  • If any transaction replayed on the replica returns a different result than received on the master. The results are hashed and compared. Just as all replicated transactions must succeed, they must produce the same results or the two databases are out of sync.

Теги: