Сначала настройте репликацию, затем можно настроить автоматическое резервное переключение с помощью keepalived или использовать переключение вручную.
Шаги настройки:
В этой инструкции:
При реальной настройке замените значения из примеров своими.
Также обратите внимание, что в некоторых системах, не использующих systemctl (например, в старых версиях CentOS), команды будут отличаться от приведённых ниже.
Технические требования:
create.sql).Важно: в этой инструкции предполагается, что у вас подключён модуль виртуализации и при переключении между серверами лицензия будет активироваться автоматически.
Проверьте, что на master-сервере включён firewall. Если включён, разрешите любые соединения к master, исходящие от IP-адреса backup к порту MySQL.
По умолчанию используется порт 3306, если в ваших файлах конфигурации другой порт — укажите его. Пример:
ufw allow from 192.168.35.2 to any port 3306
Отредактируйте файл конфигурации MySQL на master. Укажите настройки, необходимые для репликации БД.
Для этого откройте конфигурационный файл MySQL — как правило /etc/mysql/mysql.conf.d/mysqld.cnf.
Путь может быть другим — это зависит от системы, версии MySQL и директории установки.
В секции [mysqld] укажите параметры, необходимые для настройки репликации. Пример:
[mysqld]
server-id = 1
bind-address = 192.168.35.1,127.0.0.1
log_bin = /var/log/mysql/mysql-bin.log
log_bin_index = /var/log/mysql/mysql-bin.log.index
relay_log = /var/log/mysql/mysql-relay-bin
relay_log_index = /var/log/mysql/mysql-relay-bin.index
binlog_do_db = billing
auto_increment_increment = 2
auto_increment_offset = 1
binlog_expire_logs_seconds = 86400
max_binlog_size = 1G
log_bin_trust_function_creators = 1
relay_log_recovery = ON
replica_parallel_workers = 4
replica_parallel_type = LOGICAL_CLOCK
relay_log_space_limit = 10G
max_relay_log_size = 1G
Уберите опцию disable-log-bin или skip-log-bin, если она есть.
Описание параметров:
server-id — идентификатор сервера, с помощью которого различаются узлы репликации. Это значение должно быть уникальным и не повторяться на остальных связанных серверах.
bind-address — IP-адрес master-сервера. Если требуется доступ к БД снаружи по каким-то другим адресам — этот параметр должен их включать (подробнее в документации MySQL). Либо он должен быть bind-address = 0.0.0.0 для прослушивания всех интерфейсов.
Перед тем как указывать пути к файлам bin-логов и relay-логов, заранее предусмотрите место на диске. Размер зависит от нагрузки на биллинг. Можно исходить из расчёта 10-20% размера БД, но не менее 20ГБ. Проверить размер БД: du -hs /var/lib/mysql/billing/
опции log_bin и log_bin_index — путь к bin-логам сервера. Master будет указывать в них произведённые изменения для использования backup-сервером.
опции relay_log и relay_log_index — путь к relay-логам сервера. Их заполняет backup для использования master-сервером.
чтобы ограничить размеры лог-файлов, можно использовать опцию relay_log_space_limit — она определяет максимальный суммарный размер всех файлов relay-логов.
max_binlog_size — максимально допустимый размер bin-лог файла. Минимальное значение — 4096 байт, максимальное — 1 ГБ. Если не указано значение, используется по умолчанию 1 ГБ. Максимальный размера кэша транзакций настраивается в опции max_binlog_cache_size.
max_relay_log_size — максимальный размер файла relay-лога на backup-сервере.
binlog_do_db — название БД, которую требуется реплицировать. Необходимо указать ту БД, которую использует биллинг. Если реплицируемых БД несколько, повторить для каждой.
auto_increment_increment и auto_increment_offset — правила выбора автоинкрементных идентификаторов: шаг и начальное значение. Позволяет избежать конфликтов автоматического инкремента.
В примере выше указан шаг 2 (auto_increment_increment) и начальное значение 1 (auto_increment_offset) — идентификаторы будут генерироваться, начиная с 1 и прибавляя по 2 — 1, 3, 5, 7 и т.д.
binlog_expire_logs_seconds — время хранения bin-логов (в секундах). Значение должно быть 86400 (1 сутки).
log_bin_trust_function_creators — при значении 1 разрешает обычным пользователям создавать хранимые функции и триггеры при включенном бинарном логировании.
relay_log_recovery — при значении ON включает автоматическое восстановление relay-логов после резкого сбоя или аварийного перезапуска сервера.
replica_parallel_workers — задаёт количество потоков для параллельного применения транзакций репликации.
replica_parallel_type — определяет, каким именно способом backup-сервер будет распределять и выполнять поступающие от master-сервера транзакции в несколько параллельных потоков. Используйте значение LOGICAL_CLOCK.
Примечания:
Если в файле конфигурации есть настройки log_slave_updates и log_replica_updates, у них должно быть значение ON.
Если названия БД на master- и backup-серверах отличаются, добавьте в конфигурацию опцию replicate-rewrite-db. Она определяет, из какой БД в какую нужно реплицировать данные. Формат: <название БД backup-сервера>-><название БД master-сервера>. Пример: replicate-rewrite-db = backupbilling->billing.
Создайте пользователя для репликации на master в консоли MySQL. Используйте команду mysql --login-path=root-local для доступа к БД.
Можно использовать существующего пользователя. При создании нового нужно выдать права, необходимые для репликации.
Вместо replica укажите имя пользователя, вместо password — пароль пользователя.
mysql> CREATE USER 'replica'@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
mysql> FLUSH PRIVILEGES;
Перезапустите MySQL с новой конфигурацией на master.
systemctl restart mysql
Для некоторых систем (например, старых версий CentOS) команда может выглядеть так:
service mysqld restart
Или так:
/etc/init.d/mysqld.service restart
Проверьте, что на backup включён firewall. Разрешите любые соединения к backup, исходящие от IP-адреса master к порту MySQL. По умолчанию используется порт 3306, если в ваших файлах конфигурации другой порт — укажите его. Пример:
ufw allow from 192.168.35.2 to any port 3306
Сначала определите, куда будете снимать дамп на master-сервере. Для этого может потребоваться много места. Чтобы оценить размер, можно выполнить запрос:
select
round(sum(data_length)/1024/1024/1024, 4) as Gdata
from information_schema.tables where table_schema='billing';
``
Как правило, сжатый дамп занимает 5-15% от этого объёма (в ГБ).
Обратите внимание: рекомендуется выполнять дамп в период наименьшей нагрузки на биллинг.
Далее создайте дамп.
Настройка --routines указывает, что нужно копировать хранимые процедуры/функции.
Пример:
mysqldump --login-path=root-local billing --source-data=2 --single-transaction --routines --triggers --events |zstd > billing.sql.zst
``
После создания дампа проверьте его размер:
ls -ahl billing.sql.zst
``
Найдите на backup-сервере директорию, куда можно скопировать такой объём. При копировании замените /%dir%/ в следующей команде на корректный путь:
scp billing.sql.zst username@192.168.35.2:/%dir%/
``
Перейдите на backup-сервер. Убедитесь что на backup сервере у Вас создана БД, в которую будут реплицироваться данные.
Используйте команду mysql --login-path=root-local для доступа к БД.
Разверните дамп, вместо /%dir%/ укажите путь к директории, в которую ранее скопировали дамп:
zstdcat /%dir%/billing.sql.zst | mysql --login-path=root-local billing
``
Отредактируйте файл конфигурации MySQL на backup-сервере.
Выполняется аналогично настройкам в кофигурации master-сервера — меняется идентификатор сервера, указывается адрес backup-сервера, другое название реплицируемой БД (если отличается) и обратный порядок БД в replicate-rewrite-db (если отличаются названия).
В примере ниже для backup-сервера настройки автоинкремента auto_increment_increment и auto_increment_offset заданы так, чтобы значения выбирались в виде 2, 4, 6, 8,… и не пересекались с master.
[mysqld]
server-id = 2
bind-address = 192.168.35.2,127.0.0.1
log_bin = /var/log/mysql/mysql-bin.log
log_bin_index = /var/log/mysql/mysql-bin.log.index
relay_log = /var/log/mysql/mysql-relay-bin
relay_log_index = /var/log/mysql/mysql-relay-bin.index
binlog_do_db = billing
auto_increment_increment = 2
auto_increment_offset = 2
binlog_expire_logs_seconds = 86400
max_binlog_size = 1G
log_bin_trust_function_creators = 1
relay_log_recovery = ON
replica_parallel_workers = 4
replica_parallel_type = LOGICAL_CLOCK
relay_log_space_limit = 10G
max_relay_log_size = 1G
Зайдите в MySQL под пользователем root. Используйте команду mysql --login-path=root-local для доступа к БД.
Выполняется аналогично созданию пользователя для репликации на master. Можно использовать существующего пользователя. При создании нового также выдайте права, необходимые для репликации.
Вместо replica укажите имя пользователя, вместо password — пароль пользователя.
mysql> CREATE USER 'replica'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
mysql> FLUSH PRIVILEGES;
Перезапустите MySQL с новой конфигурацией на backup.
systemctl restart mysql
Определите позицию, в которой снимался дамп. Для этого выполните команду на master-сервере:
zstdcat billing.sql.zst |grep 'CHANGE REPLICATION'|head -n 1
``
Пример выводимого результата:
- CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='mysql-bin.000002', SOURCE_LOG_POS=754745642;
``
Вам потребуются значения SOURCE_LOG_FILE и SOURCE_LOG_POS.
На backup-сервере подключите репликацию.
CHANGE REPLICATION SOURCE TO SOURCE_HOST укажите свой адрес master-сервера.SOURCE_USER и SOURCE_PASSWORD — имя пользователя для репликации и его пароль.SOURCE_LOG_FILE и SOURCE_LOG_POS — соответствующие значения, полученные на master-сервере в предыдущем шаге (п.1).mysql> STOP REPLICA;
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST = '192.168.35.1', SOURCE_USER = 'replica', SOURCE_PASSWORD = 'password', SOURCE_LOG_FILE = 'mysql-bin.000002', SOURCE_LOG_POS = 754745642;
mysql> START REPLICA;
``
Периодически проверяйте статус, чтобы убедиться, что реплика вошла в нормальный режим работы:
mysql> SHOW REPLICA STATUS\G
``
Параметры, которые нужно отслеживать:
Replica_IO_Running — должно быть значение Yes,Replica_SQL_Running — должно быть значение Yes,Seconds_Behind_Source — должно быть значение 0 или очень близко к нулю. Этот параметр показывает отставание реплики от источника (master) в секундах.Может возникнуть ошибка:
Last_IO_Error: Error connecting to source 'replica@192.168.35.1:3306'. This was attempt 1/10, with a delay of 60 seconds between attempts. Message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.
``
Чтобы её исправить, смените тип авторизации пользователя реплики для обеих БД:
ALTER USER 'replica'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
FLUSH PRIVILEGES;
``
Как только статус покажет, что реплика успешно запущена и не отстаёт от master-сервера, нужно получить статус бинарных логов на backup-сервере.
show binary log status\G
``
Из него вам потребуются значения File и Position.
mysql> show binary log status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 | 157 | billing | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0,00 sec)
``
На master-сервере настройте обратную репликацию.
SOURCE_HOST укажите адрес backup-сервера.SOURCE_USER и SOURCE_PASSWORD — имя пользователя для репликации и его пароль.SOURCE_LOG_FILE — значение File, полученное в предыдущем шаге (п.4)SOURCE_LOG_POS — значение Position, полученное в предыдущем шаге (п.4)mysql> STOP REPLICA;
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST = '192.168.35.2', SOURCE_USER = 'replica', SOURCE_PASSWORD = 'password' ,SOURCE_LOG_FILE = 'mysql-bin.000003', SOURCE_LOG_POS = 157;
mysql> START REPLICA;
``
Чтобы проверить статус репликации, выполните запрос:
mysql> show replica status\G;
``
В Replica_IO_State указан текущий статус, в Last_IO_Error — последняя ошибка (если есть).
Откройте файл billing.conf.
В настройке database укажите пользователя БД с адресом из bind_address.
Такой пользователь должен иметь все права, необходимые для работы с БД биллинга.
Если биллинг на master-сервере по какой-то причине станет недоступен, можно автоматически переключаться на backup-сервер. Для этого используется инструмент keepalived, работающий по протоколу VRRP.
Установите keepalived и на master-, и backup- сервере. Также установите утилиту netcat.
На Debian/Ubuntu:
apt install keepalived netcat-openbsd
На CentOS:
yum install keepalived netcat
Также можно собрать keepalived из исходных файлов (подробнее — в документации keepalived).
Если состояние установки биллинга изменится, этот скрипт сигнализирует об этом системе.
На master- и backup-серверах создайте /etc/keepalived/state-notifier.sh:
#!/bin/sh
umask -S u=rwx,g=rx,o=rx
exec echo "[$(date -Iseconds)]" "$0" "$@" >>"/var/run/keepalived.$1.$2.state"
Скрипт должен иметь достаточные права для выполнения (на обоих серверах)
chmod 775 /etc/keepalived/state-notifier.sh
Когда состояние узла меняется (например, он получает статус основного), эти скрпиты автоматически выполняют определённые действия (например, запускают LBcore).
На backup-сервере создайте два скрипта, которые будут выполняться, когда сервер получит статус основного или когда вернётся в статус резервного. Например, запускать или останавливать определённые компоненты биллинга.
Примеры:
/etc/keepalived/run_on_master.sh
#!/bin/sh
logger -t Keepalived_vrrp "launching resources on switching to master mode..."
systemctl start lbcore
logger -t Keepalived_vrrp "launching resources complete"
/etc/keepalived/run_on_backup.sh
#!/bin/sh
logger -t Keepalived_vrrp "stopping resources on switching to master mode..."
systemctl stop lbcore
logger -t Keepalived_vrrp "stopping resources complete"
Вы можете отредактировать содержимое этих скриптов в соответствии с установленными компонентами и модулями биллинга, которые требуется запускать/останавливать при изменении статуса backup-сервера.
Все скрипты должен иметь достаточные права для выполнения утилитой:
chmod 775 /etc/keepalived/*sh
Примечание: если вы хотите, чтобы на master-сервере автоматически выполнялись какие-то действия, когда он теряет статус основного или когда ему возвращается этот статус, на нём тоже можно создать схожие скрипты.
Этот скрипт будет проверять, корректно ли работает узел.
Скрипт должен возвращать:
Что проверяется:
На master-сервере:
На backup-сервере следует проверять только связь с устойчивым внешним узлом, т.к. биллинг и его компоненты будут запущены только при получении статуса основного узла.
Устойчивый внешний узел нужно проверять для того, чтобы не возникла ситуация работы одновременно двух мастеров (напр., master-сервер отключился, основным запустился backup, связь между master и backup нарушилась, после этого master запустился, и два сервера стали работать независимо друг от друга, не зная об этом — при синхронизации БД могут возникнуть проблемы).
В примерах ниже в качестве устойчивого узла проверяется сервер лицензирования, и на master-сервере проверяется доступность LBcore (можно проверять другие модули или сервисы дополнительно).
На master-сервере создайте скрипт /etc/keepalived/check_con.sh
#!/bin/sh
/usr/bin/ping -c1 lic.lanbilling.ru > /dev/null && /bin/nc -z -w 2 127.0.0.1 1502 && exit 0 || exit 1
``
На backup-сервере — скрипт /etc/keepalived/check_con.sh
#!/bin/sh
/usr/bin/ping -c1 lic.lanbilling.ru > /dev/null && exit 0 || exit 1
``
Все скрипты должен иметь достаточные права для выполнения утилитой:
chmod 755 chmod 775 /etc/keepalived/*sh
На master-сервере создайте (если ещё не создан) и отредактируйте конфигурационный файл /etc/keepalived/keepalived.conf:
global_defs {
enable_script_security
}
vrrp_script lbcore_check {
script /etc/keepalived/check_con.sh
interval 10
user root
}
vrrp_instance lbcore_balancer {
state MASTER
interface ens18
virtual_router_id 5
priority 100
advert_int 1
notify /etc/keepalived/state-notifier.sh root
authentication {
auth_type PASS
auth_pass 111111
}
virtual_ipaddress {
192.168.49.50
}
track_script {
lbcore_check
}
}
global_defs — раздел глобальных настроек:
enable_script_security — разрешает использование скриптов. Без этой опции невозможно настроить скрипты проверки состояния.vrrp_script — раздел с описанием проверки сервиса. Название «lbcore_check» можно изменить на любое удобное.
script — путь к исполняемому скрипту, который должен выполнять проверку доступности биллинга. Например, использовать netcat для проверки соединения и т.п. Скрипт должен возвращать 0, если биллинг и сеть работает, и другой код, если нет.interval — периодичность проверки (в секундах).user — пользователь, от лица которого выполняется скрипт.vrrp_instance — раздел настроек экземпляра сервиса. Название «lbcore_balancer» можно заменить на своё.
state — начальное состояние узла. Может принимать значения MASTER или BACKUP. В случае, когда в конфигурации указана опция nopreempt (см. ниже), может быть только BACKUP. Укажите на master-сервере MASTER.interface — название сетевого интерфейса, на который будет добавлен виртуальный адрес, когда сервер становится основным.virtual_router_id — идентификатор VRRP (от 1 до 255). У всех узлов это значение должно быть одинаковым.priority — приоритет выбора данного экземпляра в качестве основного. Основным назначается активный сервер, у которого значение параметра priority выше. Если у нескольких серверов priority одинаковый, то выбирается из них случайным образом.advert_int — время (в секундах), с которой основной сервер должен сообщать о себе другим узлам. Если за данное время он не успеет отправить широковещательный сигнал, начнутся выборы другого основного сервера.notify — скрипт, который будет вызываться при каждом изменении состояния сервера (в описываемом случае это скрипт из п. 2), и имя пользователя, от которого он будет выполняться.authentication — опции авторизации. Включает:
auth_type — тип проверки, рекомендуется использовать PASS (авторизация по паролю),auth_pass — значение проверочной строки. Требования к паролю: не длиннее 8 символов.virtual_ipaddress — блок, задающий виртуальный IP-адрес.track_script — блок, в котором указывается скрипт, проверяющий работоспособность сервиса. Укажите название раздела vrrp_script.Примечания:
В разделе vrrp_script может быть указана опция fall — количество срабатываний скрипта с ненулевым кодом, после которого начнётся выбор нового мастера. Опция может помочь в случаях «ложного» срабатывания проверочного скрипта (например, когда он не успевает отдать 0 из-за таймаута).
В разделе vrrp_instance может быть указана опция nopreempt. В этом случае у всех узлов в конфигурации начальное состояние state должно иметь значение BACKUP.
Если такая опция указана, то при восстановлении работы прежнего основного сервера он не будет забирать управление на себя, т.е. работа всегда будет продолжаться на текущем выбранном узле, пока он доступен.
В данном случае рассматривается пример, когда есть приоритетный master-сервер, который должен использоваться всегда, когда доступен, поэтому nopreempt не нужно указывать.
Если используются раздельные L2-сети, в разделе vrrp_instance требуется указать адреса для связности, например:
unicast_peer {
192.168.30.10
}
unicast_peer {
192.168.35.1
}
Если на master-сервере требуется выполнять какие-то скрипты при возвращении статуса основного или при потере статуса, то их нужно указывать вместе с пользователем, от лица которого они будут выполняться. Это нужно указать в разделе vrrp_instance в настройках:
notify_master — выполнится при получении статуса MASTER,notify_backup — выполнится при получении статуса BACKUP,notify_fault — выполнится при получении состояния FAULT.Пример:
notify_master /etc/keepalived/run_on_master.sh root
notify_backup /etc/keepalived/run_on_backup.sh root
notify_fault /etc/keepalived/run_on_fault.sh root
Обратите внимание**: `notify_master` выполнится также при первоначальном запуске keepalived на master-сервере.
При составлении скрипта для vrrp_script важно учитывать не только проверку доступности биллинга на этом сервере, но и проверку доступности сети (какого-то внешнего устойчивого узла) — если этого не сделать, то может сложиться ситуация, когда связь между master- и backup- серверами пропадёт, master восстановит работу биллинга, и образуется два основных сервера, действующих одновременно и независимо друг от друга.
На backup-сервере создайте (если ещё не создан) и отредактируйте конфигурационный файл /etc/keepalived/keepalived.conf:
global_defs {
enable_script_security
}
vrrp_script lbcore_check {
script /etc/keepalived/check_con.sh
interval 10
user root
}
vrrp_instance lbcore_balancer {
state BACKUP
interface ens18
virtual_router_id 5
priority 50
preempt_delay 30
advert_int 1
notify /etc/keepalived/state-notifier.sh root
notify_master /etc/keepalived/run_on_master.sh root
notify_backup /etc/keepalived/run_on_backup.sh root
authentication {
auth_type PASS
auth_pass 111111
}
virtual_ipaddress {
192.168.49.50
}
track_script {
lbcore_check
}
}
Настройки схожи с теми, что указывались на master-сервере.
Меняется только статус узла BACKUP. Приоритет выставляется ниже, чем на master. Название раздела vrrp_instance и виртуальный адрес указываются те же, что и на master.
В раздел vrrp_instance добавляется настройка preempt_delay — время (в секундах), после которого сервер с более высоким приоритетом заберет обратно себе роль мастера (если он активен). Если настроен параметр nopreempt, то этот параметр задавать не нужно.
В notify_master и notify_backup обязательно укажите скрипты, выполняемые при сменах статуса (п.3).
Включите автозапуск сервиса и запустите его сначала на master-сервере, затем на backup:
systemctl enable keepalived
systemctl start keepalived
``
Проверьте статус:
systemctl status keepalived
``
Если всё выполнено верно, то на master-сервере вы увидите дополнительный виртуальный адрес (ip a) при работающем биллинге.
Если при запуске keepalived произошла ошибка, её можно увидеть, например, в логе, как и смены статусов узлов.
journalctl -u keepalived -f
Таким же образом настройте дополнительные backup-узлы, если нужно.
На master-сервере в скрипте check_con.sh закомментируйте строку с проверкой. На следующей строке напишите exit 1. Сохраните изменения.
Наблюдая за журналом keepalived, убедитесь что переключение состоялось:
journalctl -u keepalived -f
``
Пример результата:
авг 18 16:48:24 main Keepalived_vrrp[16233]: (lbcore_balancer) Entering MASTER STATE
авг 18 16:51:10 main Keepalived_vrrp[16233]: Script `lbcore_check` now returning 1
авг 18 16:51:10 main Keepalived_vrrp[16233]: VRRP_Script(lbcore_check) failed (exited with status 1)
авг 18 16:51:10 main Keepalived_vrrp[16233]: (lbcore_balancer) Entering FAULT STATE
``
На backup-сервере должны включиться сервисы и поменяться статус:
авг 18 16:51:10 slave Keepalived_vrrp[16473]: (lbcore_balancer) Entering MASTER STATE
``
На master-сервере в скрипте check_con.sh раскомментируйте строку с проверкой и удалите строку exit 1. Сохраните изменения — режим работы переключится.
На master-сервере в журнале появятся записи вида:
авг 18 16:52:20 main Keepalived_vrrp[16233]: Script `lbcore_check` now returning 0
авг 18 16:52:20 main Keepalived_vrrp[16233]: VRRP_Script(lbcore_check) succeeded
авг 18 16:52:20 main Keepalived_vrrp[16233]: (lbcore_balancer) Entering BACKUP STATE
авг 18 16:52:21 main Keepalived_vrrp[16233]: (lbcore_balancer) received lower priority (50) advert from 192.168.35.2 - discarding
авг 18 16:52:22 main Keepalived_vrrp[16233]: (lbcore_balancer) received lower priority (50) advert from 192.168.35.2 - discarding
авг 18 16:52:23 main Keepalived_vrrp[16233]: (lbcore_balancer) received lower priority (50) advert from 192.168.35.2 - discarding
авг 18 16:52:24 main Keepalived_vrrp[16233]: (lbcore_balancer) Entering MASTER STATE
``
На backup-сервере:
авг 18 16:52:23 slave Keepalived_vrrp[16473]: (lbcore_balancer) Master received advert from 192.168.35.1 with higher priority 100, ours 50
авг 18 16:52:23 slave Keepalived_vrrp[16473]: (lbcore_balancer) Entering BACKUP STATE
``
Изменения, совершённые в БД, должны быть синхронизированы при появлении связности.
На master-сервере запустите биллинг с необходимыми компонентами.
На backup-сервере установите такой же набор модулей биллинга, но не запускайте.
На backup-сервере добавьте скрипты следующего вида:
start_lb.sh
#!/bin/sh
systemctl start lbcore
stop_lb.sh
#!/bin/sh
systemctl stop lbcore
Вы можете отредактировать содержимое этих скриптов в соответствии с установленными компонентами и модулями биллинга, которые требуется запускать/останавливать при переключении master- и backup-серверов.
При отказе master-сервера выполните скрипт start_lb.sh на backup-сервере.
Перед восстановлением работы master выполните stop_lb.sh на backup-сервере.
Обратите внимание: обязательно проверяйте, что сервисы LANBilling остановлены на том сервере, с которого вы переключаетесь: - когда переключаетесь на backup — убедитесь, что на master-сервере отключены LBcore и другие сервисы (например, LBarcd), - когда переключаетесь на master — убедитесь что на backup-сервере отключены LBcore и другие сервисы.
Есть вопросы по документации? Пожалуйста, напишите их