Я настраиваю HA Proxy в качестве балансировщика нагрузки и отработки отказа на репликации master / master + slave.У меня есть два скрипта xinetd bash, которые прослушивают порты 9200 и 9201. Один на порту 9200 проверяет состояние главного устройства, а другой на порту 9201 проверяет состояние ведомого устройства и то, как он находится за основным.
MyФайл конфигурации HA Proxy выглядит следующим образом:
global
log 127.0.0.1 local0 notice
defaults
log global
retries 2
timeout connect 10000
timeout server 28800000
timeout client 28800000
// writes and critical reads goes here
// critical reads are the ones we can't afford any latency at all
listen mariadb-writes
bind 0.0.0.0:3307
mode tcp
option allbackups
option httpchk
balance roundrobin
// 9200 check master status
server mariadb1 1.1.1.1:3306 check port 9200 // master1
server mariadb2 2.2.2.2:3306 check port 9200 backup // master2
// heavy reads that we can afford some latency
listen mariadb-reads
bind 0.0.0.0:3308
mode tcp
option allbackups
option httpchk
balance roundrobin
// 9201 check slave status and seconds behind
server mariadb1 1.1.1.1:3306 check port 9201
server mariadb2 2.2.2.2:3306 check port 9201
server mariadb3 3.3.3.3:3306 check port 9201
// 9200 on backups check the master status
server mariadb1b 1.1.1.1:3306 check port 9200 backup
server mariadb2b 2.2.2.2:3306 check port 9200 backup
Причина, по которой я использую два сценария, заключается в том, что я нашел единственный способ решить проблему с поврежденной репликацией, но он также создает новую проблему.Я решил сделать два разных сценария, потому что проверка состояния ведомого на моей репликации мастер-мастер может деактивировать одного из мастеров, если другой выйдет из строя, так как это нарушит репликацию.Таким образом, вместо проверки статуса ведомого, на своих мастерах я просто пишу на один из узлов и продолжаю писать на него, если он работает.Если по какой-то причине мой мастер выйдет из строя, основная резервная копия будет хранить запросы.
Проблема, с которой я сталкиваюсь, заключается в том, что, если мастер1 выйдет из строя, мастер2 получит записи и, в зависимости от того, как долго он остается выключенным, когдаона идет вверх, репликация будет сильно отставать, и ее активация вызовет серьезные проблемы с согласованностью данных до тех пор, пока репликация не будет захвачена.
Я подумываю провести две проверки в главном сценарии 9200, один из которых будетстатус подчиненного и, если он включен, проверьте, сколько секунд он отстает, но если подчиненный выключен, проверьте статус ведущего.Другими словами, не возвращайте 503, если подчиненное устройство сломано, поскольку оно может быть вторым ведущим, отключившимся и нарушившим репликацию.Но это также имеет некоторые недостатки, так как, когда master1 запущен, репликация будет прервана, пока MariaDB не подключится к другому master2, поэтому в течение этого времени записи не могут быть направлены на этот узел.Я могу настроить HA Proxy так, чтобы он подождал несколько секунд, прежде чем активировать неработающий узел, но мне это не кажется правильным решением.
В основном я пытаюсь понять, как управлять соединениями, если мой master1 выходит из строя.up и HA Proxy пересылают запросы к нему, пока он догоняет время простоя, реплицируя данные с master2.Кто-нибудь знает лучший подход к этому вопросу?