Поддержка репликации данных

Для обеспечения отказоустойчивости Мессенджер и ВКС реализованы механизмы копирования всех сервисов и данных. При выходе из строя мастера (отсутствие сети, ошибки в коде) нагрузка переключается на реплику, и Мессенджер и ВКС продолжает работать «бесшовно». Для эксплуатации такой инфраструктуры обязательным условием является репликация данных между основной (main) и резервной (slave) частью бэкенда, чтобы в обеих частях были одинаковые данные в любой момент вАремени.

В документе описано, как отслеживать проблемы репликации данных и устранять их. Документ предназначен для использования администраторами организации.

Инструкция по подключению к внешней системе мониторинга — в документе описана настройка интеграции с внешними системами мониторинга — VictoriaMetrics и Prometheus.

Мониторинг Мессенджер и ВКС — в документе описана параметры инсталляции Мессенджер и ВКС, которые необходимо контролировать.

Чтобы узнать о проблемах репликации, используйте систему мониторинга согласно документации — она будет мгновенно присылать алерты в случае обнаружения проблем. Ниже описаны примеры алертов конкретных ошибок разрыва репликации и шагов для восстановления репликации данных.

Алерт:

 
2 snmpexec_mon_cox_1_status - - - replfailed (first: 2023-05-10/10:08:27, last: 2023-05-10/11:34:02, total: 3406)

Ниже рассмотрим, как устранить проблему репликации на примере сервиса Cox, инстанс 1:

1. Посмотрите карту сервиса при помощи команды:

    
   ic map cox

2. Найдите в карте slave для нужного инстанса:

    
   node   cox-1     (2147483648   buckets)    srv   cox.vkt-4vm-879-standart-01.cox-1      10.32.0.1:2510   alive   main    srv   cox.vkt-4vm-879-standart-02.cox-1     10.32.96.0:2510   alive   slave

3. Подключитесь к slave-ноде (в нашем примере это нода vkt-4vm-879-standart-02) и выполните команду:

    
   clean_kust_replica.sh cox-1

4. В выводе команды будет видно, что происходит удаление ряда файлов. Это нормально. В конце вывод должен быть таким:

    
   INFO: starting cox-1INFO: successfully started cox-1

   Если вывод отличается, обратитесь в техническую поддержку.

Алерт:

 
2 tarantool_badger_3_repl_master1 slave_lag=0.01s;500.0;1000.0 slave_lag=0.01s;500.0;1000.0 replication status stopped(!!) 2 tarantool_badger_3_replication - - problems on upstreams:1

Ниже рассмотрим, как устранить проблему репликации на примере сервиса Badger, инстанс 3:

1. Посмотрите карту проблемного сервиса:

    
   ic map badger

2. Найдите в карте slave для нужного инстанса для ноды, для которого есть алерт в сервисе Grafana. В нашем примере это нода vkt-4vm-675-standart-01, сервис Badger, инстанс 3:

    
   node   badger-3      (268435456   buckets)    srv   badger.vkt-4vm-675-standart-01.badger-3      10.32.0.1:2502   alive   slave    srv   badger.vkt-4vm-675-standart-02.badger-3     10.32.48.0:2502   alive   main

3. Подключитесь к slave-ноде и выполните команду:

    
   clean_tnt_replica.sh badger-3

   Дождитесь завершения процесса. Вывод в конце должен быть следующего вида:

    
   INFO: starting tarantool instance tarantool@badger-3INFO: successfully started tarantool@badger-3INFO: waiting 10 secondsINFO: starting IPROS instance badger-3INFO: successfully started badger-3

4. Если вывод команды НЕ такой, то дальше для текущего сервиса ничего НЕ делаем. Обратитесь в техническую поддержку.

   Если получен нужный вывод, через 5 минут на той же ноде, где выполняли шаг 3, выполните команду:

    
   ic flip <полное имя slave-ноды из шага 2>

   В выводе команды должно быть «started» или «ОК».

   Если возникла ошибка, повторите выполнение команды через 5 минут. Если ошибка снова повторилась, обратитесь в техническую поддержку.

5. Если шаг 4 выполнился успешно, через 5 минут на той же ноде, где выполняли шаг 3, выполните команду:

    
   ic map badger

   и проверьте, что slave стал main, а main стал slave.

6. Если пункт 4 выполнился успешно, подключитесь по SSH к бывшей main-ноде и выполните команду:

    
   systemctl restart tarantool@badger-3 badger-3

Алерт:

 
2 orch_topo_check - orch topology is BAD: see 'im_utils --check-orch' for details

Чтобы проверить, есть ли проблема с репликацией у MySQL, посмотрите детали по топологии MySQL — выполните команду /usr/local/bin/orch_topo.sh на любой ноде.

Штатный вывод должен быть таким:

 
files-mysql-mysql-cluster-im-db-mysql-0.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]keycloak-mysql-mysql-cluster-im-db-mysql-0.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ keycloak-mysql-mysql-cluster-im-db-mysql-1.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]store-mysql-mysql-cluster-im-db-mysql-0.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ store-mysql-mysql-cluster-im-db-mysql-1.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]

Инстансы без символов "+" в начале являются мастерами, с "+" — рабочими репликами.

Если в выводе видим, что запущено запущено 2 мастера:

 
files-mysql-mysql-cluster-im-db-mysql-0.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-1) [null,nonreplicating,8.0.27-18,ro,ROW,>>,GTID:errant]keycloak-mysql-mysql-cluster-im-db-mysql-0.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ keycloak-mysql-mysql-cluster-im-db-mysql-1.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]store-mysql-mysql-cluster-im-db-mysql-0.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ store-mysql-mysql-cluster-im-db-mysql-1.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]

или запущена реплика без мастера (статус null, nonreplicating):

 
files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-1) [null,nonreplicating,8.0.27-18,ro,ROW,>>,GTID:errant]keycloak-mysql-mysql-cluster-im-db-mysql-0.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ keycloak-mysql-mysql-cluster-im-db-mysql-1.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]store-mysql-mysql-cluster-im-db-mysql-0.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ store-mysql-mysql-cluster-im-db-mysql-1.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]

То нужно обратиться в техническую поддержку.

Если в выводе видно некорректно работающую реплику (с символом "-" в начале строки):

 
files-mysql-mysql-cluster-im-db-mysql-0.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]- files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-1) [null,nonreplicating,8.0.27-18,ro,ROW,>>,GTID:errant]

то имеются проблемы с репликацией, которые надо устранить.

Для этого:

1. Выполните на любой ноде команду:

    
   im_utils --reup-mysql-replica <replica_name>

   где <replica_name> — имя реплики, которую нужно перереплицировать с мастера, например, files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306.

   Вывод должен быть таким:

    
   # im_utils --reup-mysql-replica files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:330625 Feb 25 15:29:31 854622 | WARN  | pkg/weave/report.go:134 > assuming weave is ready |25 Feb 25 15:29:31 854622 | INFO  | pkg/weave/weave.go:140 > weave is ready |25 Feb 25 15:29:31 854622 | WARN  | pkg/weave/report.go:134 > assuming weave is ready |25 Feb 25 15:29:31 854622 | INFO  | cmd/utils/main.go:497 > deleting pvc files:data-files-mysql-mysql-cluster-im-db-mysql-1 |25 Feb 25 15:29:31 854622 | INFO  | cmd/utils/main.go:499 > deleting pod files:files-mysql-mysql-cluster-im-db-mysql-1 |

2. Дождитесь запуска нового пода. Чтобы вывести список подов, на любой из master-нод выполните команду:

    
   kubectl -n <namespace> get po

   где namespace — имя Kubernetes namespace, в котором запущена база. Определить namespace можно из вывода выше после фразы «deleting pvc» или «deleting pod».

   Дождитесь, когда у нового пода появится READY 5/5:

    
   NAME                                      READY   STATUS    RESTARTS   AGEfiles-mysql-mysql-cluster-im-db-mysql-1   5/5     Running   0          9m

3. Выполните команду /usr/local/bin/orch_topo.sh и проверьте, что больше нет ошибки «nonreplicating». Корректный вывод выглядит так:

    
   files-mysql-mysql-cluster-im-db-mysql-0.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]keycloak-mysql-mysql-cluster-im-db-mysql-0.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ keycloak-mysql-mysql-cluster-im-db-mysql-1.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]store-mysql-mysql-cluster-im-db-mysql-0.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ store-mysql-mysql-cluster-im-db-mysql-1.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]

Чтобы проверить, есть ли на реплике MySQL транзации, которых нет на мастере, выполните команду /usr/local/bin/orch_topo.sh на любой ноде. Если в выводе есть статус «errant», то такие транзакции есть. Например:

 
files-mysql-mysql-cluster-im-db-mysql-0.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID:errant]

В данном примере проблемный инстанс — files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306.

Чтобы исправить эту ошибку:

1. Выполните на любой ноде команду:

    
   im_utils --orch-fix-errants <replica>

   где replica — имя реплики, на которой нужно исправить errant-транзакции, например, files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306.

2. Через 2 минуты выполните команду /usr/local/bin/orch_topo.sh. Проверьте, что в выводе больше нет ошибок. Корректный вывод выглядит так:

    
   files-mysql-mysql-cluster-im-db-mysql-0.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ files-mysql-mysql-cluster-im-db-mysql-1.mysql.files:3306 (files-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]keycloak-mysql-mysql-cluster-im-db-mysql-0.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ keycloak-mysql-mysql-cluster-im-db-mysql-1.mysql.keycloak:3306 (keycloak-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]store-mysql-mysql-cluster-im-db-mysql-0.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ store-mysql-mysql-cluster-im-db-mysql-1.mysql.store:3306 (store-mysql-mysql-cluster-im-db-mysql-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]

Алерт:

 
2 ctlr_topo_check - ctlr topology is BAD:  ctlr has no active replicas, check ctlr logs on vkt04

В данном случае алерт указывает на проблему с репликой на ноде vkt04 сервиса Ctlr. Убедитесь, что мастер сервиса Ctlr запущен и работает на ноде vkt03:

 
vkt03# echo ipros_cluster_show |nc $(fgrep compot_bind /usr/local/etc/ctlr-1.conf |cut -d' ' -f2 |cut -d':' -f1) 4020vkt03.weave.local      10.32.88.0:2410  self mainvkt04.weave.local      10.32.96.0:2410  dead

В выводе ожидается строка вида:

 
vkt03.weave.local      10.32.88.0:2410  self main

Она означает, что мастер контроллера запущен на ноде vkt03.

Чтобы восстановить репликацию на vkt04, выполните:

 
vkt04# systemctl stop ctlr-1vkt04# mv /data/ctlr-1 /data/ctlr-1.$(date +%Y%m%d_%H%M)vkt04# mkdir -p  /data/ctlr-1/{backup,df,log}; chown -R quantum:quantum /data/ctlr-1/vkt04# /usr/local/bin/im_deployer --ctlr-repl --updatevkt04# systemctl disable ctlr-1

После выполнения команды выше проверьте топологию контроллера:

 
vkt03# /usr/lib/check_mk_agent/local/ctlr_topo_check.sh0 ctlr_topo_check - ctlr topology is OK  vkt03# echo ipros_cluster_show |nc $(fgrep compot_bind /usr/local/etc/ctlr-1.conf |cut -d' ' -f2 |cut -d':' -f1) 4020vkt03.weave.local      10.32.88.0:2410 self mainvkt04.weave.local      10.32.96.0:2410 alive

В выводе обе ноды контроллера должны иметь статус «self main» или «alive».

В кластере Мессенджер и ВКС штатно работает 2 инстанса контроллера. Один из этих контроллеров имеет роль мастера, второй — реплики. Роль контроллера задается в конфигурационном файле /usr/loca/etc/ctlr-1.conf, например:

 
vkt03# fgrep ipros_cluster /usr/local/etc/ctlr-1.confipros_clustered trueipros_cluster_add vkt04.weave.local 10.32.96.0:2410ipros_cluster_add vkt03.weave.local 10.32.32.0:2410ipros_cluster_main vkt03.weave.local

В данном случае мастером является инстанс контроллера, запущенный на vkt03.

Эти параметры должны быть согласованы между двумя инстансами контроллера. То есть на vkt04 конфигурационный файл будет выглядеть так же:

 
vkt04# fgrep ipros_cluster /usr/local/etc/ctlr-1.confipros_clustered trueipros_cluster_add vkt04.weave.local 10.32.96.0:2410ipros_cluster_add vkt03.weave.local 10.32.32.0:2410ipros_cluster_main vkt03.weave.local

Алерт:

 
2 ctlr_topo_check - ctlr topology is BAD:  ctlr has no active replicas, check ctlr logs on vkt03

может указывать на наличие двух запущенных мастеров сервиса Ctlr.

Посмотреть текущую топологию контроллера можно командой:

 
vkt03# echo ipros_cluster_show |nc $(fgrep compot_bind /usr/local/etc/ctlr-1.conf |cut -d' ' -f2 |cut -d':' -f1) 4020vkt03.weave.local      10.32.88.0:2410 self mainvkt04.weave.local      10.32.96.0:2410 alive

Если по какой-то причине в кластере запущено 2 мастера, вывод будет следующим:

 
vkt03# echo ipros_cluster_show |nc $(fgrep compot_bind /usr/local/etc/ctlr-1.conf |cut -d' ' -f2 |cut -d':' -f1) 4020vkt03.weave.local      10.32.88.0:2410 self mainvkt04.weave.local      10.32.96.0:2410 dead vkt04# echo ipros_cluster_show |nc $(fgrep compot_bind /usr/local/etc/ctlr-1.conf |cut -d' ' -f2 |cut -d':' -f1) 4020vkt03.weave.local      10.32.88.0:2410 deadvkt04.weave.local      10.32.96.0:2410 self main

То есть контроллер на vkt03 считает себя мастером и контроллер на vkt04 тоже считает себя мастером. Таким образом, мы обнаружили проблему с ролями контроллеров вручную.

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

Какой из контроллеров выбирать мастером — зависит от истории инцидента. Правильнее всего выбрать мастером тот контроллер, который штатно получил роль мастера, а за реплику принять контроллер, который ошибочно получил роль мастера (как правило недавно, контроллер получает ошибочную роль в последнюю очередь).

Например, мы принимаем за мастер контроллер на vkt04.

На vkt03 выполните:

 
systemctl stop ctlr-1cp -rp /data/ctlr-1 /data/ctlr-1.$(date +%Y%m%d_%H%M)/usr/local/bin/im_deployer --ctlr-repl --updatesystemctl disable ctlr-1

После выполнения команды проверьте топологию контроллера:

 
vkt03# /usr/lib/check_mk_agent/local/ctlr_topo_check.sh0 ctlr_topo_check - ctlr topology is OK  vkt03# echo ipros_cluster_show |nc $(fgrep compot_bind /usr/local/etc/ctlr-1.conf |cut -d' ' -f2 |cut -d':' -f1) 4020vkt03.weave.local      10.32.88.0:2410 selfvkt04.weave.local      10.32.96.0:2410 alive main

Если команды выполняются на vkt03, в выводе нода vkt03 должна быть в статусе «self», а vkt04 — «alive main».

Если master сервиса вышел из строя и автоматическое переключение разрешено, то нагрузка переключится на slave и сервис продолжит работать. Последующие переключения блокируются, пока снова не будут разрешены.

Алерт:

В случае переключения ролей и последующей блокировки автофлипа для какой-то из нод сервиса в мониторинге появится алерт, в котором перечислены карты, для которых обнаружена блокировка:

 
ctlr_topo_check - - ctlr topology is BAD: autoflip blocked for maps: [prof-st]

Ниже рассмотрим, как устранить проблему блокировки повторного автоматического переключения ролей на примере сервиса Prof-st:

1. Посмотрите карту сервиса при помощи команды:

    
   ic map prof-st -autoflip

2. Убедитесь, что есть ноды, для которых повторное переключение запрещено — статус «autoflip blocked» для проблемных нод:

    
   autoflip:   enablenode   prof-st-1     (2147483648   buckets)    srv   prof-st.vkt-01.prof-st-1     10.10.10.10:2525   alive   main      srv   prof-st.vkt-02.prof-st-1     10.10.10.11:2525   alive   slave  node   prof-st-2     (2147483648   buckets)   (autoflip   blocked)    srv   prof-st.vkt-03.prof-st-1     10.10.10.12:2525   alive   main      srv   prof-st.vkt-04.prof-st-1     10.10.10.13:2525   alive   slave

   В этом примере повторное переключение ролей заблокировано для ноды prof-st-2.

3. Проверьте наличие алертов порванной репликации для проблемного сервиса. Если такие есть, выполните действия по восстановлению репликации, описанные в разделе Проблемы репликации сервисов и контроллера.

   Если алертов нет и сервисы в статусе alive, перейдите к следующему пункту.

4. Включите автоматическое переключение ролей:

   Чтобы вернуть переключение для конкретной ноды сервиса:

    
   ic reset_autoflip_block prof-st prof-st-2

   Чтобы вернуть переключение для всех нод сервиса:

    
   ic reset_autoflip_block prof-st all

5. Посмотрите карту сервиса:

    
   ic map prof-st -autoflip

6. Убедитесь, что переключение ролей разрешено — нет статуса «autoflip blocked»:

    
   autoflip:   enablenode   prof-st-1     (2147483648   buckets)    srv   prof-st.vkt-01.prof-st-1     10.10.10.10:2525   alive   main      srv   prof-st.vkt-02.prof-st-1     10.10.10.11:2525   alive   slave  node   prof-st-2     (2147483648   buckets)    srv   prof-st.vkt-03.prof-st-1     10.10.10.12:2525   alive   main      srv   prof-st.vkt-04.prof-st-1     10.10.10.13:2525   alive   slave

Технический писатель: Белова Ирина