Плановая перезагрузка серверов¶

В статье описана поочерёдная перезагрузка двух серверов Compass с настроенной отказоустойчивостью. Перед началом создайте резервную копию приложения и баз данных.

Предупреждение

Рекомендуем проводить работы в нерабочее время: во время переключения серверов пользователи могут ненадолго потерять связь с Compass, а текущие звонки — прерваться. Если результат команды не совпадает с ожидаемым, не переходите к следующему шагу и обратитесь в поддержку.

Команды ниже используют переменную VIP - её значение подставляется из конфигурации keepalived на первом шаге. Переменная действует только в текущем сеансе терминала: если вы переподключились к серверу, перейдите в директорию установщика и выполните первый шаг заново.

Этап 1. Проверка состояния серверов¶

На обоих серверах перейдите в директорию установщика и задайте переменную:
```
VIP=$(sudo grep -A3 virtual_ipaddress /etc/keepalived/keepalived.conf | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | head -1); \
echo "виртуальный IP: $VIP"
```
Команда выведет внутренний IP-адрес VIP. На обоих серверах он должен совпадать.
На обоих серверах проверьте роли:
```
systemctl is-active keepalived; \
systemctl is-enabled keepalived; \
sudo python3 script/replication/check_current_master_server.py; \
ip a | grep $VIP
```
- На активном сервере команда выведет active, enabled, сообщение «Данный сервер является активным мастер сервером» и строку с VIP.
- На неактивном сервере команда выведет active, enabled и сообщение «Данный сервер НЕ является активным мастер сервером». Строки с VIP нет.
На неактивном сервере проверьте состояние репликации:
```
sudo python3 script/replication/show_slave_replication_status.py --all-types --all-teams --log-level=3
```
В выводе будет статус репликации базы monolith и каждой команды. Для каждой базы:
- Master_Host — IP-адрес активного сервера;
- Slave_IO_Running: Yes и Slave_SQL_Running: Yes;
- Seconds_Behind_Master: 0 seconds;
- Last_IO_Error: None и Last_SQL_Error: None.
На активном сервере проверьте синхронизацию файлов:
```
sudo tail -n 20 /var/log/rsync-replication/rsync_files.log | grep ERROR
```
Если команда ничего не вывела — ошибок синхронизации нет.

На обоих серверах проверьте поисковый кластер:

sudo docker exec $(sudo docker ps -q -f name=_php-monolith | head -1) mariadb --skip-ssl -h manticore-d1 -P 9306 -e "SHOW STATUS LIKE 'cluster%'" | grep -E "cluster_size|node_state"

В выводе значение cluster_size должно быть 2, а node_state — synced.

Этап 2. Перезагрузка неактивного сервера¶

Остановите keepalived:
```
sudo systemctl disable --now keepalived; \
systemctl is-active keepalived
```
Последней строкой команда должна вывести inactive.

Остановите MySQL:

for service in $(sudo docker service ls | grep mysql | awk '{print $1}'); do sudo docker service scale "$service"=0; done

Проверьте, что MySQL остановлен:
```
sudo docker service ls | grep mysql
```
У всех сервисов в колонке REPLICAS должно быть значение 0/0. Если отображается 1/0, MySQL ещё завершает работу — повторите команду через 10 секунд.
Перезагрузите сервер:
```
sudo systemctl reboot
```
После загрузки перейдите в директорию установщика и снова задайте переменную VIP — после перезагрузки её значение сбрасывается:
```
VIP=$(sudo grep -A3 virtual_ipaddress /etc/keepalived/keepalived.conf | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | head -1); \
echo "виртуальный IP: $VIP"
```
Команда выведет внутренний IP-адрес VIP.
Проверьте правила доступа к портам репликации:
```
sudo python3 script/replication/configure_replication_firewall.py --check; \
echo $?
```
Если команда вывела 0 — правила на месте. Если выведено другое значение, восстановите правила и повторите проверку:
```
sudo python3 script/replication/configure_replication_firewall.py; \
sudo python3 script/replication/configure_replication_firewall.py --check; \
echo $?
```

Запустите MySQL:

for service in $(sudo docker service ls | grep mysql | awk '{print $1}'); do sudo docker service scale "$service"=1; done

Через 1–2 минуты проверьте состояние сервисов:
```
sudo docker service ls
```
У всех сервисов в колонке REPLICAS должно быть значение 1/1, кроме default-file-pivot и jitsi-custom-jitsi — для них штатно отображается 0/1.

Примечание

После загрузки сервис nginx-monolith может несколько раз перезапуститься с ошибкой host not found in upstream, пока не запустятся PHP-сервисы. Это штатно и обычно занимает до минуты.
Повторите шаги 3–5 этапа 1.
Включите keepalived:
```
sudo systemctl enable --now keepalived; \
sleep 15; \
sudo python3 script/replication/check_current_master_server.py; \
ip a | grep $VIP
```
Команда выведет сообщение «Данный сервер НЕ является активным мастер сервером». Строки с VIP нет — сервер остался неактивным.

Этап 3. Переключение VIP¶

На неактивном сервере удалите файл блокировки автоматического перехода, если он есть:
```
sudo rm -f /etc/keepalived/block_master
```
На активном сервере перезапустите keepalived:
```
sudo systemctl restart keepalived
```
Через 30 секунд на обоих серверах проверьте переключение:
```
sudo python3 script/replication/check_current_master_server.py; \
ip a | grep $VIP; \
sudo tail -n 1 /var/log/keepalived-state.log
```
- На сервере, который был неактивным, команда выведет сообщение «Данный сервер является активным мастер сервером», строку с VIP и запись MASTER: --- Завершили работу изменения состояния ---.
- На сервере, который был активным, команда выведет сообщение «Данный сервер НЕ является активным мастер сервером» и запись BACKUP: --- Завершили работу изменения состояния ---. Строки с VIP нет.

Этап 4. Перезагрузка второго сервера¶

Выполните этап 2 на сервере, который стал неактивным.
Если трафик должен вернуться на первый сервер, выполните этап 3.

После выполнения этих шагов оба сервера перезагружены, данные между ними синхронизированы, а резервный сервер готов принять трафик при сбое активного.

Напишите нам в пространстве поддержки On-premise, Telegram или на почту support@getcompass.ru, чтобы получить индивидуальную демонстрацию функционала и помощь по вопросам интеграции мессенджера в вашей компании.