Во-первых, сообщение об ошибке
Последние коллеги проекта обновления системы на поле test.test_tab_t1, чтобы сделать изменения, SQL заявление выглядит следующим образом:
ALTER TABLE TEST.TEST_TAB_T1 ИЗМЕНИТЬ BXXX УАКСНАК (200);
MySQL подчиненной ошибка синхронизации в проекте после выполнения обновления системы, появляется сообщение об ошибке выглядит следующим образом:
MySQL> показать подчиненный статус \ G Master_Log_File: binlog.000233 Read_Master_Log_Pos: 274415020 Relay_Log_File: реле-bin.000253 Relay_Log_Pos: 175535154 Relay_Master_Log_File: binlog.000233 Slave_IO_Running: Да Slave_SQL_Running: Нет .............. ...: Last_Errno: 1677 lAST_ERROR: Колонка 28 таблицы 'test.test_tab_t1' не может быть преобразован в тип VARCHAR (30) (байт)) 'с типом 'VARCHAR (400 (байт) GBK)' Skip_Counter: 0 Exec_Master_Log_Pos: 175536357 Relay_Log_Space: 274410464
MySQL журнал тревог сообщения об ошибке:
2020-03-24T16: 53: 16.051244Z 11686 [ОШИБКА] Ведомый SQL для канала '': Колонка 28 таблицы 'test.test_tab_t1' не может быть преобразован в тип VARCHAR (30 байт) () 'для типа «VARCHAR (400 (байты) GBK)», Error_Code: 1677 2020-03-24T16: 53: 16.051269Z 11686 работает [ОШИБКА] Ошибка запрос, ведомое SQL поток прерван. Устранить эту проблему, и перезапустить подчиненный SQL нить с «SLAVE START». Мы остановились при входе в систему «» binlog.000233 позиции 175536357.
Во-вторых, экологическая информация
Сообщество MySQL версии 5.7.24 проекта является использование набора символов: GBK, Двоичный формат является ROW, используя keepalived + двойной мастер (мастер-мастер) архитектуры.
MySQL> выберите @@ версии, @@ character_set_server, @@ binlog_format; + ----------- + ------------------------ + ------------ ----- + | @@ версия | @@ character_set_server | @@ binlog_format | + ----------- + ------------------------ + ------------ ----- + | 5.7.24 | GBK | ROW | + ----------- + ------------------------ + ------------ ----- +
В-третьих, процесс диагностики
1, в соответствии с разрывами репликации MySQL с ошибкой 1677: колонкой таблицы .. «...» не может быть конвертирован (Doc ID 2037712,1) данного термин документа колонн вида анализа информации err1677 test.test_tab_t1 таблицы (столбец 28), там были связаны с ошибками преобразования набора символов.
Первое сравнение (master1-Master2) набор символов информация:
После сравнения (master1-Master2) базы данных, таблицы, на уровне столбцов набора символов информации:
базы данных master1, таблица, столбец уровня набора символов информация:
MySQL> выберите * из information_schema.schemata где schema_name = 'тест'; + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH | DEFAULT_ENCRYPTION | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | Защита | тест | GBK | gbk_general_ci | NULL | НЕТ | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + MySQL> выберите table_schema, имя_таблицы, TABLE_TYPE, table_collation от INFORMATION_SCHEMA.TABLES , где table_name = 'test_tab_t1'; + -------------- + ------------ + ----- ------- + ----------------- + | TABLE_SCHEMA | TABLE_NAME | TABLE_TYPE | TABLE_COLLATION | + -------------- + ------------ + ----------- - + ----------------- + | тест | test_tab_t1 | БАЗА СТОЛ | gbk_chinese_ci | + -------------- + ------------ + ------------ + -------- --------- + MySQL> выберите имя_таблицы, имя_столбца, CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTH, CHARACTER_SET_NAME, collation_name от INFORMATION_SCHEMA.COLUMNS , где table_name = 'test_tab_t1' и table_schema = 'тест' и ORDINAL_POSITION = 29; + ------------ + ------------- + ---------------------- ---- + ------------------------ + -------------------- + ---------------- + | TABLE_NAME | COLUMN_NAME | CHARACTER_MAXIMUM_LENGTH | CHARACTER_OCTET_LENGTH | CHARACTER_SET_NAME | COLLATION_NAME | + ------------ + ------------- + ---- ---------------------- + ------------------------ + - ------------------ + ---------------- + | test_tab_t1 | BXXX | 200 | 400 | GBK | gbk_chinese_ci | + ------------ + ------------- + ---------------------- ---- + ------------------------ + -------------------- + ---------------- +
базы данных Master2, таблица, столбец уровня набора символов информация:
MySQL> выберите * из information_schema.schemata где schema_name = 'тест'; + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH | DEFAULT_ENCRYPTION | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + | Защита | тест | GBK | gbk_general_ci | NULL | НЕТ | + -------------- + ------------- + -------------------- -------- + ------------------------ + ---------- + ----- --------------- + MySQL> выберите table_schema, имя_таблицы, TABLE_TYPE, table_collation от INFORMATION_SCHEMA.TABLES , где table_name = 'test_tab_t1'; + -------------- + ------------ + ----- ------- + ----------------- + | TABLE_SCHEMA | TABLE_NAME | TABLE_TYPE | TABLE_COLLATION | + -------------- + ------------ + ----------- - + ----------------- + | тест | test_tab_t1 | БАЗА СТОЛ | gbk_chinese_ci | + -------------- + ------------ + ------------ + -------- --------- + MySQL> выберите имя_таблицы, имя_столбца, CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTH, CHARACTER_SET_NAME, collation_name от INFORMATION_SCHEMA.COLUMNS , где table_name = 'test_tab_t1' и table_schema = 'тест' и ORDINAL_POSITION = 29; + ------------ + ------------- + ---------------------- ---- + ------------------------ + -------------------- + ---------------- + | TABLE_NAME | COLUMN_NAME | CHARACTER_MAXIMUM_LENGTH | CHARACTER_OCTET_LENGTH | CHARACTER_SET_NAME | COLLATION_NAME | + ------------ + ------------- + ---- ---------------------- + ------------------------ + - ------------------ + ---------------- + | test_tab_t1 | BXXX | 200 | 400 | GBK | gbk_chinese_ci | + ------------ + ------------- + ---- ---------------------- + ------------------------ + - ------------------ + ---------------- +
Согласно документу ((Doc ID 2037712,1) выглядят действительно изменить столбец обновления системы (ALTER TABLE TEST.TEST_TAB_T1 ИЗМЕНИТЬ BXXX VARCHAR (200), соответствующих полей таблицы;) есть проблема.
报错: last_error: Колонка 28 таблицы 'test.test_tab_t1' не может быть преобразован из типа 'VARCHAR (30 (байт))' к типу «VARCHAR (400 (байт) GBK)
Test.test_tab_t1 изменения таблицы поле bxxx вопросы (ORDINAL_POSITION = 29) набора символов возникли в процессе копирования, GBK 2 байта в размере до изменения bxxx действительно VARCHAR (16).
MySQL> выберите * из information_schema.character_sets где CHARACTER_SET_NAME = 'GBK'; + -------------------- + ---------------------- + ----- ------------------- + -------- + | CHARACTER_SET_NAME | DEFAULT_COLLATE_NAME | ОПИСАНИЕ | MAXLEN | + -------------------- + ---------------------- + ----- ------------------- + -------- + | GBK | gbk_chinese_ci | GBK упрощенный китайский | 2 | + -------------------- + ---------------------- + ----- ------------------- + -------- +
Но сравнивая (master1-Master2) базы данных, таблицы информации на уровне столбцов набора символов такой же, проблема непоследовательного набора символов не существует . Тогда чувствую , что проблема не так проста, а затем анализировали вниз.
Я начал думать о том или нет, мы реализуем персонал для работы в соответствии с требованиями, потому что окружающая среда является двойным мастером, то ли в обеих случаях одновременно выполнить эту инструкцию, нашел во время поиска неисправностей клиента /etc/my.cnf набора внутри character_set_client на master1 является utf8, является GBK на Master2. Таким образом, мы посмотрим на информационной точке провала Двоичного времени внутри, ошибка в binlog.000233, положение остановка составляет 175 536 357.
mysqlbinlog --no-умолчанию --start-позиция = 175536357 --database = тест /opt/mysql/log/binlog/binlog.000233 --verbose # на 175536357 # 200325 0:53:16 идентификатор сервера 1 end_log_pos 175536422 CRC32 0xddd5d37 Anonymous_GTID last_committed = 271185 sequence_number = 27186 rbr_only = да / * 50718 SET TRANSACTION ИЗОЛЯЦИЯ LEVEL READ COMMITTED * // * /!; SET @@ SESSION.GTID_NEXT = 'АНОНИМНЫЙ' / * * /!; # На 175536422 # 200325 0:53:16 ID сервера 1 end_log_pos 175536505 CRC32 0x3799f3b Запрос thread_id = 14154792 exec_time = 0 error_code = 0 SET TIMESTAMP = 1585068796 / * * /!; SET @@ session.pseudo_thread_id = 14154792 / * * /!; SET @@ session.foreign_key_checks = 1, @@ session.sql_auto_is_null = 0, @@ session.unique_checks = 1, @@ session.autocommit = 1 / * * /!; SET @@ session.sql_mode = 1075838976 / * * /!; SET @@ session.auto_increment_increment = 2, @@ session.auto_increment_offset = 2 / * * /!; ! / * \ C GBK * // * /!; SET @@ session.character_set_client = 28, @@ session.collation_connection = 28, @@ session.collation_server = 28 / * * /!; SET @@ session.lc_time_names = 0 / * * /!; SET @@ session.collation_database = DEFAULT / * * /!; НАЧАТЬ / * * /!; # На 175536505 # 200325 0:53:16 идентификатор сервера 1 end_log_pos 175536685 CRC32 0xe3db6b6b Table_map: `test`.`test_tab_t1` отображается на номер 23434 # на 175536685 # 200325 0:53:16 идентификатор сервера 1 end_log_pos 175537481 CRC32 0xf1343123 Update_rows: Таблица ID 2334 флаги: STMT_END_F ### UPDATE `test`.`test_tab_t1` ### WHERE ### @ 1 = '........' ### .......... ### @ 29 = '........' ### .......... ### @ 40 = '...' ### SET ### @ 1 = '........' ### .......... ### @ 29 = '........' ### ........ .. ### @ 40 = '...'
Двоичный увидеть внутреннюю часть SET @@ session.character_set_client = 28, @@ session.collation_connection = 28, @@ набор session.collation_server = 28 символов действительно GBK
MySQL> выберите * из information_schema.collations где ID = 28; + ---------------- + -------------------- + ---- + ------ ------ + ------------- + --------- + --------------- + | COLLATION_NAME | CHARACTER_SET_NAME | ID | IS_DEFAULT | IS_COMPILED | SORTLEN | PAD_ATTRIBUTE | + ---------------- + -------------------- + ---- + ------ ------ + ------------- + --------- + --------------- + | gbk_chinese_ci | GBK | 28 | Да | Да | 1 | PAD ПРОСТРАНСТВА | + ---------------- + -------------------- + ---- + ------ ------ + ------------- + --------- + --------------- + 1 строка набор (0,01 сек)
Конечно более чем достаточно набора символов не является причиной противоречивой. Поэтому использовать официальный рекомендуемый метод, установить параметры slave_type_conversions = ALL_LOSSY / ALL_NON_LOSSY в адрес не является действительным, но метод также риск потери преобразования данных.
Кроме того, согласно https://bugs.mysql.com/bug.php?id=83461 также описаны полям основных символов, скопированные из пакетов err1677 противоречивых проблем ошибок, но также упомянуть другой случай binlog_format = ROW потому что разбор проблемы разбора журнала ретрансляции, вы можете рассмотреть binlog_format = MIXED формат, попробуйте вытащить ведомое не в состоянии потянуть.
С помощью этого анализа, я чувствую, ни одна идея, она продолжает находить информацию, иногда этот путь, бедный комплекс горная вода имеет серебряную подкладку. Наконец-то я нашел очень представительные ссылки: https: //bugs.mysql.com/bug.php ID = 88595, это ошибка # 88595 на 5.6.37, Роу на основе мастер-мастер репликации нарушен? добавить столбец или столбец капли. Но среда проекта 5.7.24, архитектура binlog_format = ROW двойной магистра.
Контраст Двоичной информации, которую я отправил, не наличие вышеупомянутого обновления таблицы точки test.test_tab_t1 во время от прерывания. Здесь я говорю передать, хотя противоречивые версии, но в соответствии с симптомом почти близко.
АЛГОРИТМ = нижний INPLACE (по умолчанию), где:
master1 выполняется: ALTER TABLE MODIFY TEST.TEST_TAB_T1 BXXX VARCHAR (200), в пресс записаны Двоичный,
В случае, если информация об изменении поля личных данных синхронизации Master2, во время работы, наличие обновлений test.test_tab_t1 Master2 таблицы путем одновременного вытягивания Двоичного (отношения изменения утверждений поля для завершения)
При master1 синхронизации обновлений оператора test.test_tab_t1 таблицы, так как он изменил поле, структура таблицы изменилась, и заявление обновления информации или первоначальная структура, так что была ошибка err1677.
В основном переходит, но вот два вопроса, один является двойной записью этого бизнес не настроен писать только один пример, единственной интерпретируемые, реализация коллег (master1) осуществляются на не пишущие примерах действие DDL. Существует версия этой проблемы, а затем консультировалась с его реализацией коллег проекта, база данных на основе обновления с 5.6. Редкий ...? Редкий ...? В настоящее время ограниченные возможности, первая запись, а затем более глубокий последующий анализ.
В-четвертых, решение
Здесь нет ссылки решения этой ситуации не для меня, и после приведенного выше анализа, и на основе бизнес-ситуации за стол, решил пропустить ошибку, после проверки целостности данных.
остановить раб;
Означает пропустить шаг # ошибка, цифровая переменная назад, пропустить шаг 1 представляет
набор глобальный SQL_SLAVE_SKIP_COUNTER = 1;
начать ведомый;
пт-таблица контрольная сумма может быть использована для определения целостности данных master1-Master2 базы данных тестовой test_tab_t1 таблицы, если есть несоответствие в использовании этого инструмента для ремонта.
PT-таблица контрольной сумма --nocheck-репликация фильтры --databases = проверить --replicate = test.test_tab_t1 --create-повторность стол --host = ххй --port 3306 -uroot -pxxx
В-пятых, резюме неудача
Приведенный выше анализ отказов и неисправностей в процессе, мы обнаружили, что BUG, так что я думаю, что с оракулом GoldenGate скопировать только DML, DDL исходная таблица была изменена OGG-01161 и OGG-01163 очень похожи.
Многие онлайн OGG-01161, OGG-01163 исходной таблицы структуры изменения приводят к процессу replicat авост статьи ссылались на одной и той же структуры таблицы сравнения источника и целевой стороны, процесс повторного запуска R или ошибок.
Хотя длина стороны источника поля и назначения модифицирована, и ДЕФ файлы были изменены, но информация мета-файл, сгенерированный в след не будет обновляться. replicat следовать файл информации мета след процесса по умолчанию. Так что это еще ошибка. ПРИОРИТЕТ вариант необходимость добавлять новую информацию метаконтент четкости, чтобы скрыть след.
Так что этот случай аналогичен отказ Master2 заявления обновления является до DDL изменений перед синхронизацией информации меты master1 таблицы изменяется, и master1 уже больше после структуры информации таблицы метаданных, так что там будет ошибка.
Вещи действительно связаны между собой, база данных не является исключением.