(разводя руками)

Хорошо. Держи ({pk group}, hash).

В начале топика я предложил расширить шапку таблицы до "lastUpdateTime" чтоб трекать изменённые.
Но если тебе надо хеш - ОК. Пускай это будет + еще одно поле.

Хорошо. Давай твоё решение. Любое приму. Обсудим.

Дима Сибиряков. Мне кажется у тебя - какая-то глубокая проблема. И ты ее очень хочешь обсудить.

И я не понимаю почему ты ее хочешь обсуждать именно здесь. В пятничном топике.

Два варианта я-бы предложил. Давайте завяжемся на SHA1 и lastUpdateTime. Я все таки имею надежду
что владелец БД разрешит добавлять дополнительные колонки в таблицы. Глупо было-бы совсем пренебрегать
этой возможносьтю.

Отслеживание изменений

Поскольку топик все еще крутится вокруг теории и алгоритмизации - я закидываю следующий
воскресный requirement по практической имплементации.

1) Назовём приложение репликатором (replicator).



2) Репликатор должен запускаться как ОС-процесс с использованием cron, at e.t.c. Или вручную.

Пример:




2.1) Репликатор предоставляет справку о спецификации своих команд.




3) Репликатор может в делать upgrade схемы на Master или Slave как будет удобно кастомеру.

Пример:



Апгдейд будет заключаться в добавлении дополнительных колонок (alter table ... add column ...) hashcode, lastUpdateTime
для отслеживания изменений.

4) Репликатор может обозревать не все таблицы а только интересующий scope. Пример.



5) Репликатор имеет право использовать дополнительные дисковые ресурсы для выполнения своих задач


(по умолчанию это каталог временных файлов %TMP%, /tmp e.t.c)

Нет требований по сохранности временных данных между сеансами репликации.
Приложение должно сохранять работоспособность после очистки /tmp.

6) Репликатор не ограничен в ресурсах времени или процессора однако желательно чтобы процесс
репликации был завершен в течение суток.

7) Репликатор должен формировать лог файл важных событий (Error, Warn) для анализа проблем.

Пример.






8) Репликатор ставит своей целью минимально использовать ресурсы сети.

8.1) Репликатор может предоставлять отладночные сведения (DEBUG) для анализа причин репликации конкретных
data-rows



8.2) Репликатор предоставляет отчет о количестве детектированных удалений и изменений в целевой БД.




8.3) По завершению работы репликатор формирует коды ошибок в соотв. с соглашениями DOS/Unix на erroLevel/errorCode.

Пример


Нулевой статус соответствует успеху. Прочие значения - несут код ошибки.

9) Репликатор может быть разработан на любом языке программирования с открытым исходным кодом.

10) Репликатор - это свободное ПО которое разрабатывается в рамках форума SQL.ru.

11) Репликатор должен поддерживать максимальное число DBMS, или предоставлять возможности
легкого расширения функционала до поддержки требуемой конкретной DBMS без серъезных
изменений основной версии кода.

12) Репликатор не ограничен в используемых технологиях и может включать в себя любой сет
библиотек и зависимостей с выполнением пункта (9).

Зачем такое требование. Master БД работает в обычном режиме.

Разве ты когда запускаешь отчетность - требуешь read-only?

Я понял вас. Добавлю пункт.

13) Для DBMS: Oracle, PostgresQL, MSSQL, MySQL/Maria репликатор использует
режим транзакций transaction mode = { READ ONLY/SNAPSHOT, READ ONLY } для чтения данных из master в тех случаях
когда необходимо реализовать повторное чтение датасета в течение одного сеанса.

Ссылки:
Oracle (read only) : https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_10005.htm#SQLRF01705
PostgresQL (read only) : https://www.postgresql.org/docs/12/sql-set-transaction.html
MSSQL (snapshot) : https://docs.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-ver15

Прочие DBMS которые по каким-то причинам не поддерживают режимы транзакций
(noSQL-системы или упрощённые DBMS) используются в гарантированном maintanance
окне времени когда master БД не используется.

Данный пункт - to be discussed.

Лучше всех подобная схема реализована в Oracle в модели Primary/Standby.
Ты просто раз в сутки копируешь ARC-logs и на стендбай делаешь




И через короткое время получаешь ФИЗИЧЕСКИ точные копии датафайлов
консистентные



на момент последнего арк-лога. Физически - это означает побитово.
А не по-DML-но как делают например в альтернативных программных продуктах
где парсят парсерами WAL/REDO сегмент и пытаются по этому белому шуму понять
что делалось в БД.

Арк-логи в Oracle фиксировали поток LCR-s. Это достаточно тонкий уровень изменений.
Скажем так... это меньше чем dbBlock. Тоесть экономно.

Так было в 2000х. Сейчас схему они улучшили добавив какие-то data guards с которыми
я не работал но КМК они просто автоматизировали теже действия.

Позже Оракл создал Streams/Golden Gate но это уже было когда я распрощался с сектором
сопровождения и пошёл в разработку.

Так что в данном топике мне коробочные технологии не особо интересно обсуждать.
Разве что если я сам буду их кому-то парить в техподдержку.

А универсальное программное решение которое РОЖДАЕТСЯ просто как репликатор
может уже черз 20-30 спринтов стать совершенно другой системой.

Про JMS я в предыдущем топике написал вообще из другого интереса. Собственно плевать
на JMS. Можно Акторы. Можно Apache Storm. Лишь-бы была физическая среда где
есть виртуальная "труба" в сети и есть подписчики и издатели.

Кстати да. Это и был основной интерес. РАЗДАТЬ уведомления на множество Slave.
Но в данном топике я решил пока сделать только master-slave.

Хвост. Я тебя прошу.

Давай тему коллизий как-то вынесем из этого топика. Как инженер я вижу инженерное решение - поднять
разрядность хеша до SHA512 и как-то вообще отвязаться и отбиться от обсуждения этого здесь.

У нас уже был топик "дней рождений" и он хорошо коррелирует с этой высокой криптографией.