Ведомый репликации MySQL получил 2147483647 (INT32_MAX) в столбце для отметки времени
Я установил двух подчиненных устройств репликации, один на CentOS(x86_64 5.1.37), другой на Ubuntu LTS(x86_64 mysql 5.5.38). Кажется, что они оба правильно копируют большую часть Master db (CentOS i686, mysql 5.5.37), за исключением одного столбца в таблице.
Проблемный столбец был создан как int(11) DEFAULT NULLзапись отметок времени в эпоху Unix, которая еще не достигла 2038 года. Однако, когда я попытался сравнить данные в ведущем и ведомом устройствах, я обнаружил, что недавно реплицированные строки на ведомых устройствах превратились в 2147483647или INT32_MAX. Кстати, это не так для Мастера.
Является ли архитектура двоичного формата журнала конкретной? Как я могу решить это? Или, по крайней мере, убедиться, что DB на ведомых не будет записывать больше ненормальных временных меток после переключения на Master?
1 ответ
Причина проблемы была глупой.
Я дважды проверил двоичный журнал MySQL и обнаружил, что операторы вставки были подозрительными.
В рассматриваемом столбце значения типа 0x3134...30 имеют значения меток времени, которые кажутся строковыми, а не целыми числами.
И, следуя этой подсказке, я обнаружил, что при вызовах привязки параметров на стороне PHP используется неверная сигнатура типа для этого столбца. Главный сервер молча принял неправильный тип и исправил его самостоятельно, в то время как подчиненные серверы не смогли реализовать проблемы с типами, что привело к переполнению целых чисел.