Два варианта я-бы предложил. Давайте завяжемся на SHA1 и lastUpdateTime. Я все таки имею надежду
что владелец БД разрешит добавлять дополнительные колонки в таблицы. Глупо было-бы совсем пренебрегать
этой возможносьтю.
Отслеживание изменений
Поскольку топик все еще крутится вокруг теории и алгоритмизации - я закидываю следующий
воскресный requirement по практической имплементации.
1) Назовём приложение репликатором (replicator).
В отличие от JMS-ного топика где нужна была инфраструктура брокеров и поставщиков и потребителей - у нас
будет 1 процесс. И модель взаимодействия будет простой. Репликатор соединяется с 2 БД и выполняет действия
по синхронизации сета требуемых таблиц в двух БД в одном направлении.
2) Репликатор должен запускаться как ОС-процесс с использованием cron, at e.t.c. Или вручную.
Пример:
2.1) Репликатор предоставляет справку о спецификации своих команд.
3) Репликатор может в делать upgrade схемы на Master или Slave как будет удобно кастомеру.
Пример:
1.
$ replicator --command upgrade --dbMasterUrl "localhost:5432/postgres?user=username&pwd=pwd1234"
Апгдейд будет заключаться в добавлении дополнительных колонок (alter table ... add column ...) hashcode, lastUpdateTime
для отслеживания изменений.
4) Репликатор может обозревать не все таблицы а только интересующий scope. Пример.
1.
2.
3.
4.
$ replicator --command replicate \
--dbMasterUrl "localhost:5432/postgres?user=username&pwd=pwd1234"
--dbSlaveUrl "remoteHost:5432/postgres?user=username&pwd=pwd1234"
--tables "Currencies,Countries,Organizations,ISIN,CUSIP,SEDOL....."
5) Репликатор имеет право использовать дополнительные дисковые ресурсы для выполнения своих задач
1.
2.
$ replicator {arguments} --tmpDir=/home/mayton/mnt/fuckenGarbageFolderWithHugeSpace
(по умолчанию это каталог временных файлов %TMP%, /tmp e.t.c)
Нет требований по сохранности временных данных между сеансами репликации.
Приложение должно сохранять работоспособность после очистки /tmp.
6) Репликатор не ограничен в ресурсах времени или процессора однако желательно чтобы процесс
репликации был завершен в течение суток.
7) Репликатор должен формировать лог файл важных событий (Error, Warn) для анализа проблем.
Пример.
1.
$ replicator {arguments} --logFile=/home/mayton/replicator/log
1.
2020-02-01 16:00:45.0012 [ERROR] Socket connection error. Unable to create socket remoteHost:5432 .....
8) Репликатор ставит своей целью минимально использовать ресурсы сети.
8.1) Репликатор может предоставлять отладночные сведения (DEBUG) для анализа причин репликации конкретных
data-rows
1.
2020-02-01 16:00:45.0012 [DEBUG] Detected newLine in "Currency" table with primary keySet = { USD } ...
8.2) Репликатор предоставляет отчет о количестве детектированных удалений и изменений в целевой БД.
1.
2.
3.
4.
2020-02-01 16:00:45.0012 [INFO] Statistics:
2020-02-01 16:00:45.0012 Insertions : 293545
2020-02-01 16:00:45.0012 Deletes: 0
2020-02-01 16:00:45.0012 Updates: 0
8.3) По завершению работы репликатор формирует коды ошибок в соотв. с соглашениями DOS/Unix на erroLevel/errorCode.
Пример
1.
2.
3.
4.
$ replicator {arguments}
$ echo $?
0
Нулевой статус соответствует успеху. Прочие значения - несут код ошибки.
9) Репликатор может быть разработан на любом языке программирования с открытым исходным кодом.
10) Репликатор - это свободное ПО которое разрабатывается в рамках форума SQL.ru.
11) Репликатор должен поддерживать максимальное число DBMS, или предоставлять возможности
легкого расширения функционала до поддержки требуемой конкретной DBMS без серъезных
изменений основной версии кода.
12) Репликатор не ограничен в используемых технологиях и может включать в себя любой сет
библиотек и зависимостей с выполнением пункта (9).
