Менял мастер сервер
* Создал как реплику (ID 2)
* Дождался пока догонит мастера
* Отключил старый мастер (ID 1)
* Поменял IP созданной реплики на IP мастера
* Запустил новый сервер как мастер с новым id (ID 1)
Зачем-то поменял ID мастер сервера. Пока был репликой, был 2 - когда нагнал мастер и переключил на мастер, сделал 1 - как было на старом сервере мастера. Чтобы другие действующие реплики сами заработали - не заработали...
Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period
Со старого бэкапа, того что на мастер накатил - реплика восстанавливается, догоняет по бинлогам видимо до места отключения переключения старого мастера и останавливается с ошибкой.
Да сломали. Слейвы хотят кусок бинлога которого нет на новом мастере.
Чтобы работали такие цепочки репликации нужно включать log_slave_update на промежуточных серверах. Так в промежутках будут полные бинлоги. А сейчас на новом мастере есть только свои бинлоги, но в Executed_Gtid_Set есть куски от старого мастера, которых нет на старых слейвах. Вот их они и хотят. Сравните Executed_Gtid_Set на всех серверах.
У вас включены GTID поэтому ID сервера не влияет на бинлог. Бинлог подписывается Master_UUID, который генерируется автоматически.
Промежуточный, это тот, который для нового мастера создавался, верно? На нем нужно было включить log_slave_update - потом накатить бэкап со старого, дождаться пока он догонит мастера, выключить мастера, переключить слэйв в мастер + сменить IP/ID. Тогда другая(старая) реплика подхватит новый мастер без CHANGE MASTER - там же ID и IP будут как у старого мастера. Привилегии пользователь и пароль такие же как на старом.
Простой
