Игнорировать предупреждения с помощью pt-online-schema-change

Question

Я пытаюсь обновить таблицу, которая отлично работала минуту назад, но теперь я обнаружил ошибку, которая у меня была в прошлом, которая крайне неудобна.

09:32:57 Copying rows caused a MySQL error 1300:
    Level: Warning
     Code: 1300
  Message: Invalid utf8mb4 character string: '94C494'

Есть ли вариант или что-то, чтобы я мог игнорировать эти предупреждения? В конце концов, это всего лишь предупреждение, поэтому MySQL все еще имеет возможность двигаться вперед и копировать строки в любом случае.

Другие решения тоже подойдут, например, способ найти значение в таблице, которое нарушает работу, или удалить недействительные фрагменты, или просто что-то, чтобы я мог изменить свою таблицу, было бы замечательно.

Мой поиск в Google о том, как найти / заменить неработающие последовательности utf8 в MySQL, приводит меня к этим ссылкам (которые не очень полезны)

• https://dba.stackexchange.com/questions/77101/how-to-find-non-utf8-data-in-mysql/77154
• Обнаружение неработающих символов в MySQL

Я даже попытался найти все столбцы, в которых гекс содержит недопустимую последовательность, и все же как-то безуспешно

select * from `notifications` 
where hex(`Description`) like '%94C494%' 
or hex(`Title`) like '%94C494%' 
or hex(`NotificationID`) like '%94C494%' 
or hex(`ToUserID`) like '%94C494%' 
or hex(`FromUserID`) like '%94C494%'
or hex(`Link`) like '%94C494%' 
or hex(`Icon`) like '%94C494%';

MySQL - это версия 5.7.18-15-57-log и pt-online-schema-change 3.0.8

---

Еще более странно, я решил потешить себя и искать ВСЕ столбцы (не только utf8mb4), и я получил строки! Но единственные строки, которые я получил, были из моих двоичных столбцов? Почему наличие недопустимых последовательностей utf8 имеет значение в двоичном столбце? Теперь я думаю, что это может быть ошибка с инструментом

select * ,hex(`notificationid`), hex(`notificationbid`), hex(`fromuserid`), hex(`touserid`), hex(`title`), hex(`description`), hex(`read`), hex(`datetimeadded`), hex(`link`), hex(`icon`), hex(`shown`), hex(`_linkdescriptionsha256`), hex(`_touseridlinkdescription+sha3-224`)
from `notifications` 
where hex(`notificationid`) like '%94C494%'
or hex(`notificationbid`) like '%94C494%'
or hex(`fromuserid`) like '%94C494%'
or hex(`touserid`) like '%94C494%'
or hex(`title`) like '%94C494%'
or hex(`description`) like '%94C494%'
or hex(`read`) like '%94C494%'
or hex(`datetimeadded`) like '%94C494%'
or hex(`link`) like '%94C494%'
or hex(`icon`) like '%94C494%'
or hex(`shown`) like '%94C494%'
or hex(`_linkdescriptionsha256`) like '%94C494%'
or hex(`_touseridlinkdescription+sha3-224`) like '%94C494%';

Answer 1

После работы с поддержкой Percona по этой проблеме мы в конечном итоге привели к созданию этого билета: https://jira.percona.com/browse/PT-1528

Хитрость для игнорирования проблем сортировки (или обхода этой ошибки) заключается в добавлении --charset binary флаг к pt-online-schema-change команда.

Кажется, что это происходит, когда первичный ключ представляет собой двоичный столбец, а кодировка либо установлена ​​в utf8(mb4), либо выведена как одна из них в настройках MySQL.