November 2019

S M T W T F S
      12
34 5 678 9
10111213141516
17181920212223
24252627282930

Style Credit

Expand Cut Tags

No cut tags
Thursday, May 11th, 2017 03:48 pm

На бэкапном MySQL сервере slave отвалился с очень странной ошибкой, с которой я раньше не встречался:
Could not execute Update_rows event on table foobar.nodes; Can't find record in 'nodes', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log live-master.001765, end_log_pos 13453210
Попробовал перезапустить slave, та же ошибка вылезает. Покопался в базе, а там никаких event’ов вовсе не зарегистрировано. Посмотрел в master, там тоже нету.

Классический способ STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; в данном случае не подходил, ибо в этой бэкапной базе нужно иметь в точности то же самое, что и в основной. А если часть операторов пропустить, то что-нибудь может подпортиться.

Самое противное, что непонятно, какой оператор эту ошибку вызвал. Обычно-то он явно указывается, а тут нету — сам ищи, что там за ключ не нашёлся, и каким образом он использовался..
Попробовал сдампить log-файл на master’е mysqlbinlog’ом, а там фигня какая-то: виднеются операторы типа SET TIMESTAMP=1494413401, BEGIN, COMMIT,, а в какой записи этот timestamp SET — фиг знает, сам угадай.. Но виднеются какие-то куски BINLOG в base64. Попробовал сдампить ещё раз с --base64-output=decode-rows, так эти куски пропали, а подробности операторов так и не появились.

Ну, как водится, эти грабли мне тоже удалось обойти. Нашёл нужную опцию -vv для mysqlbinlog’а, и тогда в дампе появились подробности, хотя и не про сами операторы, но хотя бы про записи, над которыми эти операторы выполнялись:

### UPDATE `foobar`.`nodes`
### WHERE
###   @1=345 /* INT meta=0 nullable=0 is_null=0 */
###   @2=2 /* INT meta=0 nullable=0 is_null=0 */
###   @3=0 /* INT meta=0 nullable=0 is_null=0 */
###   @4='string1' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */
###   @5='string2' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */
###   @6='string3' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */
###   @7='' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */
###   @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @10=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @11=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @12=1469704055 /* INT meta=0 nullable=0 is_null=0 */
###   @13=1489490052 /* INT meta=0 nullable=0 is_null=0 */
###   @14=1494410253 /* INT meta=0 nullable=0 is_null=0 */
###   @15=-1 /* INT meta=0 nullable=0 is_null=0 */
### SET
###   @1=345 /* INT meta=0 nullable=0 is_null=0 */
###   @2=2 /* INT meta=0 nullable=0 is_null=0 */
###   @3=0 /* INT meta=0 nullable=0 is_null=0 */
###   @4='string1' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */
###   @5='string2' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */
###   @6='string3' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */
###   @7='' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */
###   @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @10=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @11=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @12=1469704055 /* INT meta=0 nullable=0 is_null=0 */
###   @13=1489490052 /* INT meta=0 nullable=0 is_null=0 */
###   @14=1494413401 /* INT meta=0 nullable=0 is_null=0 */
###   @15=-1 /* INT meta=0 nullable=0 is_null=0 */

Посмотрел структуру таблицы, @1 – это id, первичный ключ. Поискал запись с таким id, а её нету.. Ни в slave, ни в master. Ну, видать, из master’а её потом удалили, а в slave придётся добавить, чтоб этот UPDATE сработал. Добавил её руками, перезапустил slave, заработало! Но через некоторое время вылезла аналогичная ошибка. Поискал в дампе, опять там меняли запись, которой тут нету. Добавил и её, перезапустил slave, и так далее. Короче, всего пришлось добавить штук 10 записей в паре таблиц, хотя потом их все всё равно удалили. Ну зато slave больше не ругается, нормально работает.

Но вот как эти записи пропали в slave, когда в master’е их ещё только подправляли — так и осталось загадкой. Видать, кто-то руками удалил, но кто, когда, как, и главное — зачем, выяснить не удалось.

Оригинал этой записи в личном блоге.

Reply

This account has disabled anonymous posting.
If you don't have an account you can create one now.
No Subject Icon Selected
More info about formatting