Одна вещь, которую вам нужно понять, кратко упоминается в этой статье, заключается в том, что каждая реализация GTID в MariaDB может вызвать проблемы в этой ситуации. Поскольку каждый узел поддерживает свой собственный список GTID, а транзакции Galera не имеют собственного идентификатора, возможно, что один и тот же GTID не указывает на одно и то же место на каждом сервере (см. эту статью).
Из-за этой проблемы я бы не стал пытаться делать то, что вы делаете, без MariaDB 10.1. Недавно была выпущена версия MariaDB 10.1.8, которая является первой общедоступной версией линейки 10.1. 10.1 изменяет реализацию GTID, поэтому транзакции galera используют свои собственные server_id (устанавливаются через переменную конфигурации). Затем вы можете отфильтровать репликацию на ведомых устройствах, чтобы реплицировать только идентификатор galera.
Чтобы переключиться на другой подчиненный сервер, вам нужно будет выполнить последний GTID на старом подчиненном сервере. gtid_slave_pos хранится в mysql.gtid_slave_pos, но mysql.* таблицы не реплицируются. Я не совсем уверен, и у меня нет способа проверить, передается ли исходный GTID транзакции другим подчиненным узлам galera (т. е. если galera server_id главного кластера равен 1, а galera server_id подчиненного кластера равен 2 и MDBDR-01 получает подчиненное событие с GTID 1-1-123, MDBDR-02 зарегистрирует его как 1-1-123 или 1-2-456). Я предполагаю, что это не так, поскольку новая реализация GTID должна изменить server_id, но вы можете это проверить. Поскольку вы, вероятно, не можете получить последний выполненный основной GTID с другого подчиненного узла galera, вам, вероятно, потребуется получить GTID от старого подчиненного устройства, что может быть невозможно, если вы изящно не отключите старый подчиненный узел. Вам может понадобиться найти GTID из последней выполненной транзакции в бинарном журнале на новом ведомом устройстве и попытаться сопоставить его с транзакцией в бинарном журнале мастера. Кроме того, если вы не используете sync_binlog = 1, бинлог ненадежен и может немного отставать.
Поскольку каждый подчиненный узел galera, вероятно, не знает о выполненных GTID и не может пропустить предыдущие события GTID, вам также может потребоваться поиграть с SQL_SLAVE_SKIP_COUNTER, чтобы добраться до правильной позиции, если найденный вами GTID отстает.
Когда вы получите GTID (или его предположение), вы затем настроите репликацию на новом ведомом устройстве так же, как вы настроили его на исходном ведомом устройстве. Это должны сделать следующие команды:
SET GLOBAL gtid_slave_pos = "{Last Executed GTID}";
CHANGE MASTER TO master_host="{Master Address}", master_port={Master Port}, master_user="{Replication User}", master_password={Replication Password}, master_use_gtid=slave_pos;
START SLAVE;
Вы также должны отключить репликацию на старом подчиненном устройстве перед его перезапуском, чтобы пропущенные события не реплицировались дважды.
До тех пор, пока исполняемый подчиненный GTID не будет реплицирован через galera, что может никогда не произойти, аварийное переключение, подобное этому, будет запутанным процессом.
20.10.2015
