v1.29_Резервирование SoftWLC

Общие сведения

Резервирование контроллеров SoftWLC необходимо для синхронизации критичных для работы системы файлов (настройки, файлы прошивок, выгрузки данных), баз данных MySQL, баз данных MongoDB, а также DHCP серверов. Такая схема обеспечивает доступность услуг и и актуальные данные на обоих контроллерах при выходе одного из строя, недоступности сети, проблем с электропитанием.

Настройка резервирования контроллеров SoftWLC состоит из следующих этапов:

установка и настройка keepalived (выполняется по схеме master-slave)
настройка rsync
настройка репликации MySQL (осуществляется путём встречной репликации по принципу master-master)
настройка replicaSet MongoDB (репликация осуществляется объединением 3 узлов в Replica Set)
настройка работы Eltex-PCRF в режиме кластера
изменение конфигурации модулей системы для работы с виртуальным IP

В примерах конфигурации в данном разделе для простоты ip-адреса будут указываться как <ip_server1>, <ip_server2> и <virtual_ip>, где:

<ip_server1> - реальный ip-адрес первого сервера
<ip_server2> - реальный ip-адрес второго сервера
<virtual_ip> - виртуальный ip-адрес

Для корректной работы требуется обеспечить L2 связность между двумя удаленными серверами.

Синхронизация токенов сервиса eltex-doors

Описание

После развертывания серверов SoftWLC, на них необходимо синхронизировать токены сервиса eltex-doors. Токены с сервера Primary копируются на потенциальный Secondary с заменой, затем перезапускаются зависящие от них сервисы и повторно генерируются записи в БД.

Порядок действий

Удалите содержимое папки "/etc/eltex-doors/keys/" на сервере Slave (файлы private.pem и public.pem).

Скопируйте содержимое папки "/etc/eltex-doors/keys/" с сервера Master на сервер Slave (файлы private.pem и public.pem).

Перезапустите на сервере Slave следующие сервисы:

sudo service eltex-disconnect-service restart
sudo service eltex-doors restart
sudo service eltex-johnny restart
sudo service eltex-portal restart
sudo service eltex-portal-constructor restart

На обоих серверах удалите из целевой БД в MySQL записи о токенах сервиса eltex-doors командой:

mysql -ujavauser -pjavapassword -e "delete from eltex_doors.auth_token;"

Перейдите к веб-интерфейсу личного кабинета на каждом сервере, адрес "http://<ip-адрес сервера>:8080/wifi-cab", внутри личного кабинета перейдите во вкладку "Сервисы и тарифы". Редактировать ничего не требуется, при переходе в указанный раздел ЛК - записи об удаленных на шаге "3" токенах сгенерируются в БД повторно.

Установка и настройка keepalived

Описание пакета

Пакет keepalived - это open source программное обеспечение, предназначенное для обеспечения функций высокой надежности (high availabilitty) и балансировки нагрузки (load-balancing). За первую функцию отвечает реализация протокола VRRP, а вторая основывается на модуле ядра Linux Vitrual Server (IPVS). Keepalived не разрабатывается сотрудниками Eltex и не включает доработок, за исключением конфигурации. Keepalived используется для организации резервирования контроллеров SoftWLC, при этом используется только функционал VRRP.

Установка keepalived

Для установки пакета, необходимо загрузить его на сервер и выполнить следующую команду (установка должна производиться от имени суперпользователя root на обоих серверах):

sudo apt update
sudo apt install keepalived

После установки необходимо добавить демона Keepalived в автозагрузку и запустить его:

sudo systemctl enable keepalived
sudo systemctl start keepalived

Основной файл конфигурации

На обоих серверах в файле /etc/keepalived/keepalived.conf меняем следующие параметры:

<interface> - наименование сетевого интерфейса (свой для каждого сервера) аналогично записи (eth1);

<virtual_ip> - виртуальный ip-адрес (с указанием префикса) аналогично записи (100.111.195.202 /24);

<ip_адрес другого сервера> - ip-адрес другого сервера аналогично записи (100.111.195.200);

/etc/keepalived/keepalived.conf

! Configuration File for keepalived
 
global_defs {
 
   script_user root
   enable_script_security 
}

vrrp_script check_network {
    script "/etc/keepalived/check_ping.sh"
    interval 5
    weight 50
    fall 3
    rise 3
    init_fail
    user root
}

vrrp_instance VI_SWLC {
    state BACKUP
    interface <interface>
    virtual_router_id 1
    track_script {
        check_network
    }
    track_interface {
        <interface> weight 50
    }
    priority 150
    advert_int 1
    nopreempt
	# Uncomment and comment "nopreempt" if preemption needed
	#preempt_delay 180
    authentication {
        auth_type PASS
        auth_pass eltex
    }
    virtual_ipaddress {
        <virtual_ip> dev <interface> label <interface>:1
    }
 
    notify_master "/etc/keepalived/keep_notify.sh master"
    notify_backup "/etc/keepalived/keep_notify.sh backup"
    notify_fault "/etc/keepalived/keep_notify.sh fault"
 
    unicast_peer {
        <ip_адрес_другого_сервера>
    }
}

Тест-скрипт

Скрипт пингует шлюз по умолчанию и возвращает код результата. Таким образом, при успешном выполнении скрипта, гарантируется, что SoftWLC достижим для внешних клиентов.

В текущей реализации на обоих серверах, в качестве тестового скрипта, предлагается использовать следующий:

/etc/keepalived/check_ping.sh

#!/bin/bash

# host to ping
# there - default gw
HOST=<default_gw_ip>
# -q quiet
# -c nb of pings to perform
ping -q -c5 $HOST > /dev/null

# $? var keeping result of execution
# previous command
if [ $? -eq 0 ]
    then
        echo `date +"%T %F"` "OK gw reachable"
        EXIT_CODE=0
    else
        echo `date +"%T %F"` "ERROR gw unreacheble!"
        EXIT_CODE=1
fi

exit $EXIT_CODE

где <default_gw_ip> - шлюз по умолчанию для этого сервера аналогично записи (100.10.194.1);.

Конфигурация смены роли

При смене состояния сервера, выполняется скрипт keep_notify.sh, где <mysql_user> и <mysql_password> - логин и пароль от БД MySQL (по умолчанию root/root).

/etc/keepalived/keep_notify.sh

#!/bin/bash

MYSQL_USER="<mysql_user>"
MYSQL_PASSWORD="<mysql_password>"

mongo_set_role() {
    local role="$1"
    if [[ "$(which mongo)" ]]; then
        mongo --quiet --eval "var role=\"$role\"" admin /etc/keepalived/mongo_switch.js
        # Uncomment if using mongodb auth
        #mongo -u<username> -p<password> --quiet --eval "var role=\"$role\"" admin /etc/keepalived/mongo_switch.js
    fi
}

if ! lockfile-create --use-pid -r 5 /tmp/keep.mode.lock; then
    echo "Unable to lock"
    echo "Unable to lock" > /tmp/keep.mode.lock.fail
    exit 0
fi

case "$1" in
    master)
    #  ems_reload_all
    echo "MASTER" > /tmp/keep.mode
  
    mongo_set_role master
    service eltex-ems restart
    service tomcat8 restart
    service eltex-ngw restart

    # рестарт слейва MySQL чтобы при восстановлении связи - сразу получить изменения,
    # а не ждать периодического heartbeat от второго сервера
    mysql -u$MYSQL_USER -p$MYSQL_PASSWORD -e "stop slave"
    mysql -u$MYSQL_USER -p$MYSQL_PASSWORD -e "start slave"
  ;;
 backup)
    echo "BACKUP" > /tmp/keep.mode
    mongo_set_role slave
    service mongod restart
    service eltex-ems stop
    service tomcat8 stop
    service eltex-ngw stop
    mysql -u$MYSQL_USER -p$MYSQL_PASSWORD -e "stop slave"
    mysql -u$MYSQL_USER -p$MYSQL_PASSWORD -e "start slave"
 ;;
 fault)
    echo "FAULT" > /tmp/keep.mode
    mongo_set_role slave
    service mongod restart
 ;;
 *)
    echo "Usage: $0 {master|backup|fault}"
    exit 1
esac

lockfile-remove /tmp/keep.mode.lock;

exit 0

Скрипт смены мастера replicaSet MongoDB.

/etc/keepalived/mongo_switch.js

// Предоставляется окружением
var role;

if (role != 'master' && role != 'slave') {
    throw "Role must be either master or slave";
}

var thisIsMaster = (role == 'master');
var status = rs.isMaster();
var thisHost = status.me;

print("Primary: " + status.ismaster + "; applying configuration ...");
var cfg = rs.conf();
for (var i = 0; i < cfg.members.length; i++) {
    var member = cfg.members[i];
    var self = (member.host == thisHost);
    if (self ^ thisIsMaster) {
        // Конфигурация для slave
        member.priority = 1;
        member.votes = 0;

        print(member.host + ": secondary");
    } else {
        // Конфигурация для master
        member.priority = 2;
        member.votes = 1;

        print(member.host + ": primary");
    }
}

var result = rs.reconfig(cfg, { force: !status.ismaster });
if (result.ok == 1) {
    print("Reconfiguration done");
} else {
    print(result);
}

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

sudo chmod +x /etc/keepalived/check_ping.sh
sudo chmod +x /etc/keepalived/keep_notify.sh
sudo chmod +x /etc/keepalived/mongo_switch.js

Выделение лога в отдельный файл

По умолчанию keepalived записывает лог в файл /var/log/syslog . Для удобства отладки, мониторинга и контроля работы keepalived, можно настроить ведение собственного, отдельного лог-файла.

Ниже приведен пример настройки rsyslog:

sudo nano -w /etc/rsyslog.d/10-keepalived.conf

Добавьте в файл 10-keepalived.conf следующее:

/etc/rsyslog.d/10-keepalived.conf

if $programname contains 'Keepalived' then /var/log/keepalived.log
if $programname contains 'Keepalived' then ~

Затем, нужно перезапустить rsyslog командой:

sudo service rsyslog restart

Теперь сообщения от демона keepalived попадут только в лог-файл /var/log/keepalived.log и не попадут в /var/log/syslog .

Способ запуска/остановки keepalived

Для запуска сервиса воспользуйтесь командой:

sudo service keepalived start

Остановка сервиса:

sudo service keepalived stop

Проверить состояние сервиса можно командой:

sudo service keepalived status

На одном из серверов, при корректной настройке, должен отображаться интерфейс с виртуальным ip.

Для проверки работы сервиса keepalived, отключите сервер, у которого в интерфейсах присутствует virtual_ip. Virtual_ip должен появиться на втором сервере.

Настройка rsync

Rsync в схеме резервирования отвечает за синхронизацию служебных файлов, сервисов Eltex-EMS и Eltex-APB, а также файлов прошивок, шаблонов конфигурации, выгрузок конфигураций точек. Rsync представляет собой клиент серверное ПО. В данной схеме master-сервер выступает в роли клиента и синхронизирует каталоги slave-сервера с локальными.

Конфигурация сервера rsync

Для активации сервера rsync, необходимо на каждом сервере в файле /etc/default/rsync установить значение:
RSYNC_ENABLE=true

Создать файл ,. Листинг файла приведен ниже.

hosts allow = <ip_другого_сервера> <virtual ip>

Запись hosts allow = <ip_другого_сервера> <virtual ip> в конфигурации встречается в 3 местах, не забудьте исправить все значения!

/etc/rsyncd.conf

[ems-conf]
path = /usr/lib/eltex-ems/conf/
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
# IP-адрес сервера, который будет иметь доступ к ресурсу, т.е. адрес второго сервера в паре
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz
 
[ems-tftp]
path = /tftpboot
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.tftp
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

[ems-wp]
path = /var/ems-data/WP
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.ems-wp
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

[radius-nbi-certs]
path = /var/lib/eltex-radius-nbi
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.radius
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

[radius-certs]
path = /etc/eltex-radius/certs
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.radius
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

Для аутентификации, необходимо настроить пользователя rsync, для этого, на каждом сервере создайте файлы /etc/rsyncd.secrets, в которых необходимо указать пароль.

/etc/rsyncd.secrets

backup:rspasswd

Назначить права доступа к файлам, выполнив на обоих серверах:

sudo chmod 600 /etc/rsyncd.secrets

Настройка запуска синхронизации
Создайте файлы /etc/rsync_client.secrets, в которых укажите пароль:

echo "rspasswd" | sudo tee /etc/rsync_client.secrets && sudo chmod 600 /etc/rsync_client.secrets

Начиная с версии rsync 3.2.0 добавлена по умолчанию защита каталога /usr, /boot, /home (защиту home в дальнейшем убрали) Решением является переопределение защищающей опции rsync.
Для этого необходимо на обоих хостах:
прописать команду
systemctl edit rsync
в открывшемся файле в начале прописать:
[Service]
ProtectSystem=off
перезапустить службу
service rsync restart

Способ запуска/остановки

Для запуска сервиса используется команда:

sudo service rsync start

Для остановки сервиса используется команда:

sudo service rsync stop

Для проверки — запущен ли сервис в данный момент, используется команда:

sudo service rsync status

Конфигурация скрипта для eltex-ems

Операцию синхронизации файлов осуществляет задача cron, в которой выполняется скрипт /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh. Скрипт запускает rsync клиент и синхронизирует локальные директории с директориями на втором (backup) сервере. Синхронизация запускается только в случае, если сервер в состоянии master.
В 6 строке заменить HOST на ip-адрес другого сервера (Пример: HOST=100.111.195.201)

/usr/lib/eltex-ems/scripts/rsync_ems_backup.sh

#!/bin/bash

LOCKFILE="/run/lock/rsync_ems_backup"

# IP address backup server
HOST=<ip_адрес_другого_сервера>
# Check if we're root
if [ `whoami` != "root" ]
    then
	echo "This script should be run by root."
	exit 1
fi

# Check and create lock file
if ! lockfile-create --use-pid -r 0 $LOCKFILE &> /dev/null ; then
    echo "Backup is already running"
    exit 0
fi

# Check - if we're master - try to perform backup to slave
SRVMODE=`cat /tmp/keep.mode`
if [ "$SRVMODE" == "MASTER" ]
    then
	rsync -urlogtp --delete-after --password-file=/etc/rsync_client.secrets /usr/lib/eltex-ems/conf/ backup@$HOST::ems-conf > /tmp/rsync_ems_conf.log 2>&1
	echo $? >> /tmp/rsync_ems_conf_result.log
	rsync -urlogtp --delete-after --password-file=/etc/rsync_client.secrets /tftpboot/ backup@$HOST::ems-tftp > /tmp/rsync_ems_tftpboot.log 2>&1
	echo $? >> /tmp/rsync_ems_tftpboot_result.log
    rsync -urlogtp --delete-after --password-file=/etc/rsync_client.secrets /var/ems-data/WP/ backup@$HOST::ems-wp > /tmp/rsync_ems_wp.log 2>&1
    echo $? >> /tmp/rsync_ems_wp_result.log
else
	echo "Not master. No action will be performed."
fi

lockfile-remove $LOCKFILE

Конфигурация скрипта для eltex-radius/eltex-radius-nbi

Сервис eltex-radius-nbi генерирует для каждой из нод свой собственный CA и серверный сертификат, после чего копирует их в eltex-radius:

/var/lib/eltex-radius-nbi/wireless-ca.crt > /etc/eltex-radius/certs/ca/local.pem
/var/lib/eltex-radius-nbi/certificates/server.crt > /etc/eltex-radius/certs/server.crt
/var/lib/eltex-radius-nbi/certificates/server.key > /etc/eltex-radius/certs/server.key

На основании wireless-ca.crt буду генерироваться клиентские сертификаты (создаются через ЛК) в директории /var/lib/eltex-radius-nbi/certificates/
При создании сертификата пользователя через ЛК он будет сгенерирован на только ноде, на которой сейчас вы находитесь и на основании его собственного wireless-ca.crt.
Поэтому при переходе мастерства вторая нода не будет ничего знать о клиентских сертификатах.

Обязательно убедитесь, что в файле /etc/eltex-radius-nbi/radius_nbi_config.txt в переменной tomcat.host установлен ваш виртуальный ip-адрес

Чтобы это исправить нужно:

выбираем ноду, которая будет владеть актуальными данными, например первую ноду
Добавить ip-адрес второго хоста в переменную окружения
```
echo "export SLAVE_HOST="YOUR_IP"" | sudo tee /etc/environment && source /etc/environment
```

/usr/lib/eltex-radius-nbi/rsync_radius_cert_synchronization.sh

#!/bin/bash
# You mustn't change this script. After new installation it will be replaced.

LOCKFILE="/run/lock/rsync_radius_cert_synchronization"

# IP address server for synchronization.
# Please before all define SLAVE_HOST for your environment.
SLAVE_HOST=${SLAVE_HOST:-SLAVE_HOST_DEFAULT}
# Check if we're root
if [ `whoami` != "root" ]
    then
    echo "This script should be run by root."
    exit 1
fi

# Check and create lock file
if ! lockfile-create --use-pid -r 0 $LOCKFILE &> /dev/null ; then
    echo "Backup is already running"
    exit 0
fi

# Check - if we're master - try to perform backup to slave
SRVMODE=`cat /tmp/keep.mode`
if [ "$SRVMODE" == "MASTER" ]
    then
    rsync -urlogtp --password-file=/etc/rsync_client.secrets /var/lib/eltex-radius-nbi/ backup@$SLAVE_HOST::radius-nbi-certs > /tmp/rsync_radius_nbi_certs.log 2>&1
    echo $? >> /tmp/rsync_radius_nbi_certs.log
    rsync -urlogtp --password-file=/etc/rsync_client.secrets /etc/eltex-radius/certs/ backup@$SLAVE_HOST::radius-certs > /tmp/rsync_radius_certs.log 2>&1
    echo $? >> /tmp/rsync_radius_certs.log
else
    echo "Not master. No action will be performed."
fi

lockfile-remove $LOCKFILE

Запустить команды с выбранной вами ноды в статусе "MASTER"

rsync -rlogtp --delete-after --password-file=/etc/rsync_client.secrets /var/lib/eltex-radius-nbi/ backup@$SLAVE_HOST::radius-nbi-certs > /tmp/rsync_radius_nbi_certs.log 2>&1
rsync -rlogtp --delete-after --password-file=/etc/rsync_client.secrets /etc/eltex-radius/certs/ backup@$SLAVE_HOST::radius-certs > /tmp/rsync_radius_certs.log 2>&1

эти команды синхронизируют данные с вашей второстепенной нодой

убедитесь, что файлы в директориях /var/lib/eltex-radius-nbi/ и /etc/eltex-radius/certs/ совпадают
выполнить команду на двух нодах
systemctl restart eltex-radius.service

Статус можно проверить в файле /tmp/keep.mode

Настройка cron

Cоздать задачу в cron на обоих серверах, для запуска синхронизации раз в минуту:

sudo crontab -l | { cat; echo "*/1 * * * * /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh"; } | sudo crontab
sudo crontab -l | { cat; echo "*/1 * * * * /usr/lib/eltex-radius-nbi/rsync_radius_cert_synchronization.sh"; } | sudo crontab

Проверяем список задач:

sudo crontab -l
*/1 * * * * /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh
*/1 * * * * /usr/lib/eltex-radius-nbi/rsync_radius_cert_synchronization.sh

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

sudo crontab -e

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.tiny
  3. /usr/bin/code
  4. /bin/ed

Choose 1-4 [1]: 1                                 # выбираем в каком редакторе открыть

Проверить работу rsync можно в EMS. Во вкладке "Информация"-Состояние системы резервирования-Rsync service.

На обоих серверах должна быть запись такого типа:

OK. Успешная синхронизация файлов из директории: /usr/lib/eltex-ems/conf/* 
OK. Успешная синхронизация файлов из директории: /tftpboot/* 
OK. Успешная синхронизация файлов из директории: /var/ems-data/WP/*

Настройка репликации MySQL

Резервирование данных, хранящихся СУБД MySQL, осуществляется путём встречной репликации по принципу master-master (ведущий-ведущий). То есть, каждый из серверов одновременно является и master и slave. При такой схеме работы, все изменения в БД на одном сервере записываются в специальный бинарный лог, который в реальном времени вычитывает второй сервер и применяет изменения. Второй сервер реплицирует данные с первого, а первый со второго. Это позволяет получить актуальную копию БД на двух хостах одновременно. При разрыве связи, изменения накапливаются, после восстановления происходит синхронизация.

Перенос дампа данных и перенос на второй сервер

При настройке резервирования в процессе эксплуатации (то есть если в MySQL на действующем сервере уже имеются данные), необходимо перенести эти данные на второй сервер. Это можно сделать при помощи утилиты mysqldump.

Для этого, необходимо на первом сервере заблокировать таблицы, снять дамп, разблокировать таблицы и скопировать получившийся файл на второй сервер:

sudo mysql -uroot -proot -e "FLUSH TABLES WITH READ LOCK;"
sudo mysqldump -uroot -proot --databases ELTEX_PORTAL eltex_alert eltex_auth_service eltex_ems radius wireless > mysqldump_master.sql
sudo mysql -uroot -proot -e "UNLOCK TABLES;"
sudo scp mysqldump_master.sql <username>@<ip_server2>:/home/<username>/

Затем, развернуть dump на втором сервере:

sudo mysql -uroot -proot < /home/<username>/mysqldump_master.sql

Конфигурация MySQL

Конфигурация самого демона mysqld заключается в настройке параметров ведения бинарных логов. Обозначения первый сервер и второй сервер далее условны, и применяются лишь для обозначения различий в конфигурации серверов.

В секции [mysqld] файла конфигурации /etc/mysql/mysql.conf.d/mysqld.cnf произвести следующие изменения:

В файл /etc/mysql/my.cnf добавить путь к файлу /etc/mysql/mysql.conf.d/

Закомментировать либо удалить строку на обоих серверах:

/etc/mysql/mysql.conf.d/mysqld.cnf

bind-address = 127.0.0.1

Указать server-id. Для серверов необходимо задать уникальные идентификаторы, к примеру, для первого:

/etc/mysql/mysql.conf.d/mysqld.cnf

server-id = 1

для второго:

/etc/mysql/mysql.conf.d/mysqld.cnf

server-id = 2

Включить бинарные логи на обоих серверах:

/etc/mysql/mysql.conf.d/mysqld.cnf

log_bin = /var/log/mysql/mysql-bin.log

указать параметры auto_increment_increment (шаг приращения) и auto_increment_offset (стартовую точку).

Для первого сервера:

/etc/mysql/mysql.conf.d/mysqld.cnf

auto_increment_increment= 2
auto_increment_offset = 1

Для второго сервера:

/etc/mysql/mysql.conf.d/mysqld.cnf

auto_increment_increment= 2
auto_increment_offset = 2

На обоих серверах: указать базы, для которых будут вестись логи:

/etc/mysql/mysql.conf.d/mysqld.cnf

binlog-do-db = eltex_alert
binlog-do-db = eltex_ems
binlog-do-db = wireless
binlog-do-db = radius
binlog-do-db = eltex_auth_service
binlog-do-db = ELTEX_PORTAL
binlog-do-db = eltex_doors
binlog-do-db = eltex_ngw
binlog-do-db = eltex_bruce

yказать базы, для которых не будут вестись логи:

/etc/mysql/mysql.conf.d/mysqld.cnf

binlog-ignore-db = mysql
binlog-ignore-db = Syslog
binlog-ignore-db = performance_schema
binlog-ignore-db = information_schema

Перезапустить сервис mysql на каждом сервер и создать БД для репликации:

sudo service mysql restart

Создание учетных записей

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

Создать в консоли MySQL учетную запись для репликации на первом сервере: