Репликация группы соединений узла MySQL не удалась из-за дополнительных транзакций после отработки отказа

Question

У меня 3-х узловый MySQL кластер InnoDB, развернутый на kubernetes(k8s). Каждый узел mysql является POD k8s. Чтобы проверить доступность, я вручную удалил соответствующий первичный узел контейнера Docker MySQL (с помощью команды 'docker rm xxxx -f). Как и ожидалось, k8s успешно воссоздал контейнер. Но вновь созданный не смог присоединиться к кластеру (точнее, не смог присоединиться к репликации группы). Он жаловался, что участник имеет транзакцию не в текущей группе. Но дополнительная транзакция - это операция для установки SESSION.GTID_NEXT в AUTOMATIC. Я не знаю, почему это в binlog и не удалось присоединиться. Кто-нибудь даст мне подсказку или предложение? Большое спасибо!

Версия MySQL: mysql-community-server-minimal-5.7.20-1. И это установлено с rpm.

Кластер InnodDB создается путем принятия существующей группы репликации. Это говорит, что я сначала создал группу репликации, а затем создал кластер.

Журнал MySQL это:

2018-03-12T08: 17: 21.208124Z 0 [Примечание] Плагин group_replication сообщил: "новое состояние x_run" 2018-03-12T08:17:21.218361Z 0 [ERROR] Плагин group_replication сообщил: "Этот элемент имеет больше выполненных транзакций, чем присутствует в группе. Локальные транзакции: 925deea1-75db-4e92-86a9-00259c8d8078:1-50 > Групповые транзакции: 925deea1-75db-4e92-86a9-00259c8d8078:1-2' 2018-03-12T08:17:21.218433Z 0 [ОШИБКА] Плагин group_replication сообщил: "Участник содержит транзакции, которых нет в группе. Теперь участник выйдет из группы. 2018-03-12T08:17:21.218444Z 0 [Примечание] Плагин group_replication сообщил: "Чтобы принудительно включить этого участника в группу, вы можете использовать параметр group_replication_allow_local_disjoint_gtids_join" 2018-03-12T08:17:21.218493Z 3 [Примечание] Плагин group_replication зарегистрирован: "Будем ждать модификации представления" 2018-03-12T08:17:21.218546Z 0 [Примечание] Плагин group_replication сообщил: "Был выбран новый первичный сервер с адресом t-baj3bsrg4cp000a1sp3g-mysql-0.mysql:3306, позволяющий обнаруживать конфликты пока новый первичный не применяет все журналы реле.' 2018-03-12T08:17:21.218597Z 15 [Примечание] Плагин group_replication сообщил: "Этот сервер работает как основной участник". 2018-03-12T08:17:21.218634Z 0 [Замечание] Плагин group_replication сообщил: "Членство в группе изменено на t-baj3bsrg4cp000a1sp3g-mysql-0.mysql:3306, t-baj3bsrg4cp000a1sp3g-mysql-1.mysql: 2242, 1242, с: 2206, представление:: 3 ". 2018-03-12T08:17:21.218655Z 0 [Примечание] Плагин group_replication сообщил: "Участник с адресом t-baj3bsrg4cp000a1sp3g-mysql-2.mysql:3306 был объявлен онлайн в группе репликации" 2018-03-12T08:17:21.218825Z 4 [ERROR] Плагин group_replication сообщил: "Невозможно обновить результат сертификации на стороне сервера, thread_id: 136" 2018-03-12T08:17:21.218838Z 4 [ERROR] Плагин group_replication сообщил: "Ошибка при обработке события! Получена ошибка: 1' 2018-03-12T08:17:21.218849Z 4 [ERROR] Плагин group_replication сообщил: "Неустранимая ошибка во время выполнения процесса Applier групповой репликации. Сервер теперь покинет группу. 2018-03-12T08:17:21.218864Z 4 [Предупреждение] Плагин group_replication сообщил: "Операция пропуска выхода: идет одновременная попытка покинуть группу". 2018-03-12T08:17:21.218996Z 7 [Примечание] Ошибка чтения события журнала ретрансляции для канала "group_replication_applier": подчиненный поток SQL был уничтожен

События журнала бина, показанные на отказавшем узле:

+ ------------------------------------------- + ----- + ---------------- + ----------- + ------------- + ------ ------------------------------------- + | Log_name | Pos | Event_type | Server_id | End_log_pos | Информация | +-------------------------------------------+-----+----------------+-----------+-------------+-------------------------------------------+ | t-baj3bsrg4cp000a1sp3g-mysql-0-bin.000003 | 4 | Format_desc | 100 | 123 | Версия сервера: 5.7.20-log, Binlog ver: 4 | | t-baj3bsrg4cp000a1sp3g-mysql-0-bin.000003 | 123 | Previous_gtids | 100 | 190 | 925deea1-75db-4e92-86a9-00259c8d8078:1-50 | +-------------------------------------------+-----+----------------+-----------+-------------+-------------------------------------------+

Транзакция 925deea1-75db-4e92-86a9-00259c8d8078: 1-50 показана в файле binlog:

К вашему сведению, согласно журналу mysql, установка параметра group_replication_allow_local_disjoint_gtids_join сработала для меня. Но, обратитесь к последнему документу опции group_replication_allow_local_disjoint_gtids_join, он будет удален в mysql 5.7.22. Итак, я должен выяснить причину проблемы. Спасибо!

Answer 1

Мой совет - перепроверить вашу инфраструктуру, так как вы видите, что у вас нет 1 дополнительной транзакции. Если вы посмотрите на информацию, которую вы вставили

925deea1-75db-4e92-86a9-00259c8d8078:1-50 > 925deea1-75db-4e92-86a9-00259c8d8078:1-2 

1-50 против 1-2 означает, что у вас есть 48 дополнительных транзакций.

Кроме того, вы смотрите на новый файл binlog, когда вы удаляли старые или произошла ротация. В этом новом файле единственная информация, которую вы видите, состоит в том, что информация Previous-GTID - 925deea1-75db-4e92-86a9-00259c8d8078:1-50, то есть более старые файлы binlog содержали информацию об этих 50 транзакциях.

Вы можете использовать команды

 SHOW BINARY LOGS;

А потом

SHOW BINLOG EVENTS [IN 'log_name']

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