У меня есть двухузловой кластер PostgreSQL, настроенный через repmgr.
Топология базы данных выглядит так:
db1 - 10.10.10.50 ( master )
db2 - 10.10.10.60 ( standby )
wit - 10.10.10.70 ( witness )
Создание кластера (как репликация, так и автоматический переход на другой ресурс) работает как положено, но проблема в следующем.
Допустим, что в моем кластере db1 узел выходит из строя, то ожидается, что db2 узел становится новым мастером. Это все хорошо, и журналы подтверждают это:
[WARNING] connection to upstream has been lost, trying to recover... 60 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 50 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 40 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 30 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 20 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 10 seconds before failover decision
[ERROR] unable to reconnect to upstream after 60 seconds...
[ERROR] connection to database failed: could not connect to server: No route to host
Is the server running on host "10.10.10.50" and accepting
TCP/IP connections on port 5432?
[ERROR] connection to database failed: could not connect to server: No route to host
Is the server running on host "10.10.10.50" and accepting
TCP/IP connections on port 5432?
[NOTICE] promoting standby
[NOTICE] promoting server using '/usr/lib/postgresql/9.3/bin/pg_ctl -D /var/lib/postgresql/9.3/main promote'
[NOTICE] STANDBY PROMOTE successful. You should REINDEX any hash indexes you have.
В db2 узел теперь повышен до нового мастера, и все в порядке, пока db1 узел возвращается в рабочее состояние.
В этом сценарии ожидается, что db1 to стал новым резервным, но это не тот случай, поскольку в итоге оба узла действуют как ведущие ?!
Итак, мой вопрос: после аварийного переключения, как я могу предотвратить, чтобы оба узла действовали как ведущие (в документации говорится, что нужно включить третий узел в качестве свидетеля - у меня это есть), но желаемого эффекта нет.
Вот пример моего файла repmgr.conf:
cluster=test_cluster
node=1
node_name=db1
conninfo='host=10.10.10.50 dbname=repmgr user=repmgr'
master_response_timeout=60
reconnect_attempts=6
reconnect_interval=10
failover=automatic
promote_command='repmgr standby promote -f /etc/repmgr/repmgr.conf'
follow_command='repmgr standby follow -f /etc/repmgr/repmgr.conf'
pg_bindir=/usr/lib/postgresql/9.3/bin
И состояние кластера после db1 узел возвращается:
repmgr -f /etc/repmgr/repmgr.conf cluster show
Role | Connection String
* master | host=10.10.10.50 dbname=repmgr user=repmgr
* master | host=10.10.10.60 dbname=repmgr user=repmgr
witness | host=10.10.10.70 dbname=repmgr user=repmgr port=5499
Огромное спасибо,
С уважением
Часто желательно вернуть отказавший мастер обратно в репликацию в качестве резервного. Во-первых, убедитесь, что главный сервер PostgreSQL больше не работает; тогда используйте repmgr standby clone для повторной синхронизации своего каталога данных с текущим мастером, например:
repmgr -f /etc/repmgr/repmgr.conf --force --rsync-only -h node2 -d repmgr -U repmgr --verbose standby clone
Здесь важно использовать параметры командной строки --force, чтобы убедиться, что repmgr будет повторно использовать существующий каталог данных, и --rsync-only, что заставляет repmgr использовать rsync скорее, чем pg_basebackup, так как последний можно использовать только для клонирования нового резервного.
Затем узел можно перезапустить. Затем узел необходимо будет повторно зарегистрировать в repmgr; снова --force опция необходима для обновления существующей записи:
repmgr -f /etc/repmgr/9.5/repmgr.conf --force standby register
Несколько месяцев назад я изучал возможность автоматического переключения при отказе с помощью repmgr. Кажется, что repmgr работает должным образом.
IIRC repmgr не запускает старый мастер в качестве нового резервного, вам нужно будет запустить --force standby clone. Вы можете настроить другие резервные узлы так, чтобы они следовали новому мастеру, если произойдет аварийное переключение (за ним следует резервный repmgr).