Альтернатива столбцу временной метки для синхронизации.

Question

У меня есть локальная mysql db и производная mysql db. Я делаю изменения локально и использую сторонний инструмент для синхронизации изменений с живым сервером. Инструмент использует функцию контрольной суммы для идентификации измененных строк. Моя структура db проста, одно поле varchar200 (действует как первичный ключ) и текстовое поле.

Проблема заключается в том, что синхронизация занимает много времени, так как есть тысячи строк. Я полагаю, что добавление поля временной метки будет проводиться для быстрого получения контрольной суммы, чтобы инструмент идентифицировал строки, которые будут синхронизированы. это создало еще больше проблем, так как поле метки времени отличается на локальных и prod-серверах из-за различий в часовых поясах.

Я ищу полезную идею или альтернативу временной метке, которая изменяется при изменении строки.

PS: Я разместил similar question, но не получил полезных ответов. Я не хочу полагаться на дополнительные таблицы.

Answer 1

Мой совет: Не используйте TIMESTAMP тип данных, используйте DATETIME. Они хранят одни и те же данные, но разница TIMESTAMP обновляется каждый раз, когда вы касаетесь строки, даже если вы не установите этот столбец, он будет обновлен с помощью «сейчас», включая вставки.

Это означает, что при использовании TIMESTAMP вы никогда не сможете по-настоящему синхронизировать две базы данных - этот столбец всегда будет отличаться. Если вы используете DATETIME, вы можете сохранить данные этого столбца.

Если вы не можете запрограммировать свои приложения для обновления столбца DATETIME с помощью «сейчас», просто создайте триггер, который сделает это за вас.

Answer 2

Вы можете сделать несколько вещей:

1. добавить колонку для «грязной» в исходной таблице. Сделайте это одним BIT, который вы переворачиваете, когда строка изменяется и отбрасывает ее, когда она синхронизируется. Если идентификатор строки является первичным ключом, это простая вставка ... при повторном обновлении ключа
2. хранить все свое время как GMT. Так что больше не борьба за часовой пояс. Это стандартная практика, где все время сохраняется.
3. настройка репликации между двумя серверами, поэтому MySQL выполнит копирование/обновление для вас. Это именно то, для чего он предназначен, и он работает хорошо.

Answer 3

Отслеживание строк на самом деле является плохой идеей, к тому моменту, когда клиент обновит собственное время синхронизации, многие строки могут обновляться на сервере, и вы можете пропустить их. Используйте счетчик, который увеличивается каждый раз при добавлении или изменении строк на сервере, самом обновлении клиента и получении последнего значения счетчика. Клиент может не получить последнее значение для счетчика (например, какая-то строка обновляется, пока клиент запрашивает обновление), но это гарантия догнать при следующем обновлении