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