Ковыряюсь сейчас с древним Astra Linux 1.3 (Debian Wheezy с ядром 3.2.0), и нужно мне сделать синхронизацию идентичных таблиц на 5-ти хостах.

Таблицы имеют идентичную структуру, имеют поле с PRIMARY KEY id, имеют поле с TIMESTAMP, имеют поле с UUID. Содержимое записей не меняется. Синхронизация должна быть двунаправленная (master-master?). То есть, нет никакой «главной» таблицы. Просто все записи, созданные на разных хостах, должны в итоге присутствовать на инстансах PostgreSQL на всех хостах.

Скорость репликации не важна. Достаточно, если синхронизация будет происходить периодически. В минуту каждый хост может добавить в таблицу от 0 до ~1000 новых записей. В любой момент сеть может «развалиться» и хосты не смогут видеть друг друга, при этом новые записи будут создаваться. После восстановления сети все новые записи должны засинхронизироваться на всех хостах.

Не факт, что все хосты будут работать одновременно. Может 4 хоста работать, а 1 быть выключен. После его включения он должен принять все данные, которые «пропустил» когда был выключен. Может быть и наоборот: работает только 1 хост, остальные выключены. После включения остальных хостов, данные с первого хоста должны перетечь на все остальные.

* * *

Сейчас я раздумываю, с помощью каких инструментов проще всего решить эту задачу. Насколько я понял, средства репликации, существующие для PostgreSQL 9.1 (тот же slony), умеют делать только master-slave репликацию, да и работа такой репликации в условиях нестабильной сети под большим вопросом.

Мне нужно что-то более простое, типа pt-table-sync от Percona, только не для MySQL, а для PostgreSQL. И чтобы оно работало на древних линухах.

Перед тем, как я начну писать решение на коленке, я хочу попробовать решить задачу уже готовыми инструментами . Кто что может предложить? Да, сменить дистрибутив не получится, ибо при аттестации/сертификации/лицензиации средства стандартного программного обеспечения зафиксированы.

Maxim BogukКстати, а что вы будете делать если на 2х хостах образуется 2 разные записи с одинаковым id.
Или если это невозможно в вашей архитектуре то как это обеспечивается?
Конечно, могут быть одинаковые id в разных базах. Для уникальной идентификации сделано поле UUID.

Да, не удасться. У нас сертифицирован Astra Linux 1.3, это да же не 1.5. Поэтому имеем PostgreSQL 9.1.

Есть идея синхронизироваться по "точкам синхронизации", которые и представляют из себя id. То есть, иметь, например, на каждом узле список точек синхронизации с другими узлами. Например, для 1-го узла будет таблица:




И тогда для получения новых данных нужно будет просто запросить новые строки с id больше, чем записано в таблице, после чего обновить значение id в таблице.

Запрашивать новые данные по точке во времени нельзя по следующей причине. В сети, помимо пяти хостов с PostgreSQL имеется куча хостов, которые на PostgreSQL-хост складывают данные (этот хост Мастером зовется, но не в смысле репликации master-slave). Когда сеть распадается, в отвалившемся сегменте появляется свой Мастер. Далее возможна ситуация, когда в этом отвалившемся сегменте «проснулся» давно не работавший хост, и выстрелил на мастер из своего кеша старые данные со старым временем (да у всех хостов еще есть SQLite-кеш). То есть, на Мастере отвалившегося сегмента появилась "вставка" старых данных. И таких вставок может быть несколько. И не надо забывать, что на нем же происходит и добавление новых данных. Потом сеть собирается, и Мастера должны засинхрить свои таблицы. Если ориентироваться по времени, то есть синхрить от последней временнОй точки синхронизации, то "вставка" старых данных обнаружена не будет.

А вот если синхрится по id, то старые данные со старым временем, в момент их приема Мастером, получат новый id, и при синхронизации с другими Мастерами они будут обнаружены.

Но и у этой идеи есть проблемы. Если на каком-то Мастере будет очищена база, или база будет "откатана" назад из какого-то бекапа, то новые id будут считаться с нуля. А в таблице синхронизации записаны какие-то большие id. И поэтому синхронизация заработает только после того, как id доберется до нужного значения. Или нужно каким-то образом следить, что если база обнулена, то и в таблице синхронизации нужно обнулить значение. Как такое слежение сделать, я пока не знаю.

Да, левые пакеты низзя, сертификацию не пройдешь. Можно, с гемором, самосборные из исходников пакеты, с полным описанием каждой переменной и функции на русском языке. Поэтому небольшой скрипт (до 10 тыщ строк) я смогу таки документировать, а что-то большее - это еще заняться автотрансляцией комментариев на руссиш и исправлением фраз их чтоб была связная речь а не бред транслятора. Для такого действия нужен очень серьезный повод: поставил, прописал IP хостов и имя синхронизирующейся таблицы, и оно сразу само заработало.