Вам понадобится какой-нибудь способ пометить записи для синхронизации. Мы используем такую систему, в которой каждая таблица для синхронизации имеет столбец, в котором хранится состояние синхронизации. Когда запись модифицируется, она также изменяет свое состояние (в триггере), и инструмент синхронизации запрашивает измененные записи каждые несколько минут.
Недостатком является то, что вам потребуется много кода для правильной обработки, особенно потому, что вы не можете удалять записи напрямую. Инструмент синхронизации сначала должен знать и выполнять фактическое удаление. Кроме того, сложно построить хорошую очередь таким образом, поэтому, если записи синхронизируются раньше, чем их родители, вы получите ошибку. И каждая таблица, которая должна быть синхронизирована, нуждается в дополнительном столбце.
Так что теперь есть новое решение, которое должно быть реализовано. Это решение использует отдельную таблицу для очереди. Очередь содержит указатели на записи в других таблицах (значение первичного ключа и ссылку на имя таблицы / имя поля). Эта очередь теперь является единственной таблицей для отслеживания изменений, поэтому все, что нужно сделать таблице, - это реализовать один триггер, который помечает измененные записи как измененные в очереди. Поскольку это отдельная очередь в отдельной таблице, это добавляет решения для проблем, о которых я упоминал ранее:
- Записи могут быть удалены немедленно. Инструмент синхронизации находит идентификатор в очереди, проверяет, что он больше не существует, поэтому он также удаляет его из другой базы данных
- Зависимости дочерних родителей решаются автоматически. Новый родитель будет в очереди до своих потомков, а удаленный родитель будет позади своих потомков. Единственная проблема, которую вы можете найти в сшитых записях, хотя отсроченные коммиты могут быть решением для этого.
- Нет необходимости в дополнительном столбце во всех таблицах. Только одна очередь, несколько вспомогательных таблиц и один триггер, содержащий один вызов функции для каждой таблицы для синхронизации.
К сожалению, мы не полностью реализовали это решение, поэтому я не могу сказать вам, будет ли оно работать лучше, хотя тесты определенно указывают на это.
Имейте в виду, что эта система делает одну на одну копию записей. Я думаю, что это лучший подход. Скопируйте данные, а затем (впоследствии) обработайте их на целевом сервере. Я не думаю, что это хорошая идея для обработки данных при копировании. Если что-то пойдет не так, у вас будет адски отладка и восстановление / пересчет данных.