Синхронизация содержимого таблицы для PostgreSQL 9.1 в 2020 году

Пиши на коленке. Я сомневаюсь, что даже pt-table-sync прокатит для такой задачи. На фоне постоянной потери ACID-овости я бы вообще подумал о том, чтобы отказаться от гарантий целестности и сохранности данных на уровне одного сервера. Правда, при тяжелых случаях отказов в итоге развалится ACID и на всей системе, но нужен ли он был тебе изначально?

тут проблема, как я понял, что у тебя имена таблиц совпадают на всех хостах, верно?
такой кейс сложно будет решить на postgres без жестких костылей.

Если всё таки имена таблиц хотя бы для вставки можно можно изменить в зависимости от хоста, то такая задача решается через londiste и вьюху сверху этих таблиц для чтения.

сорри, я не в теме, а

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

значит то, что пакеты тоже ставить нельзя, которые не входят в поставку с дистрибутивом?

Посмотри может longdiste что-то такое умеет.

модно дебезиумом вытаскивать изменения в кафки а потом оттуда взад.

Что нужно делать при совпадении ид записей? Перетирать?

Кстати какая версия постгре? По идее начиная 10 это можно сделать через логическую репликации.

Что нужно делать при совпадении ид записей? Перетирать?

ID будут пересекаться для разных инстансов. Это служебное поле для первичной сортировки в пределах одного инстанса и на него не нужно обращать внимания. Уникальность записей обеспечивается полем UUID.

Если UUID пересечется (что по сути невозможно), то ничего не делать, какая есть запись БД, такая и остается.

Кстати какая версия постгре? По идее начиная 10 это можно сделать через логическую репликации.

Неужели заголовок недостаточно крупный?

значит то, что пакеты тоже ставить нельзя, которые не входят в поставку с дистрибутивом?

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

Так я не читаю заголовки. А возможно ли переехать на более новый?

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

Просто в каждой базе заводи процедуру по таймеру, которая заселектит из соседних баз записи начиная с последнего таймстампа - дельта (на рассинхрон часов) , и сложит к себе в таблицу записи с неизвестными уидами.

Это значит, что каждый инстанс должен однозначно знать состав сети мастеров, и отслеживать каждый мастер-инстанс. Что делать, если в сети захотят добавить еще одного мастера, или наоборот убрать его?

Просто в каждой базе заводи процедуру по таймеру, которая заселектит из соседних баз записи начиная с последнего таймстампа - дельта (на рассинхрон часов) , и сложит к себе в таблицу записи с неизвестными уидами.

В общем, так не получится. Потому что в сети, помимо пяти хостов с PostgreSQL имеется куча хостов, которые на один PostgreSQL-хост складывают данные (он Мастером зовется, но не в смысле репликации master-slave).

Когда сеть распадается, в отвалившемся сегменте появляется свой Мастер. Далее возможна ситуация, когда в этом отвалившемся сегменте «проснулся» давно не работавший хост, и выстрелил на мастер из своего кеша старые данные (да у всех хостов еще есть SQLite-кеш). То есть, на Мастере отвалившегося сегмента появилась «вставка» старых данных. И таких вставок может быть несколько.

Потом сеть собирается, и встает вопрос: как основному Мастеру узнать о том, что в таблице Мастера отвалившейся сети появились не только новые данные, но и вставки старых данных? Как их засинхрить?

Это значит, что каждый инстанс должен однозначно знать состав сети мастеров, и отслеживать каждый мастер-инстанс.

возможна ситуация, когда в этом отвалившемся сегменте «проснулся» давно не работавший хост, и выстрелил на мастер из своего кеша старые данные

Тогда придётся заводить таблицу с данными репликации, т.е. на каждом хосте хранить в таблице адрес мастера и данные о последней синхронизации с ним. Соответственно синхронизацию вести в 2 этапа: сначала синк хвостов а ля днс (его кстати можно делать чаще), затем синк данных. Соответственно новый мастер достаточно будет записать хотя бы один раз. Есть конечно обратный вариант когда сам хост рассылает себя остальным.

Выходит всё как-то сложно по виду, но по сути любое решение твоей задачи в конце концов сведёт я именно к такому. Если не выделять специализированный мастер.

с древним Astra Linux 1.3

Хинт на будущее, хоть и не совсем по теме: у астры есть линейки Common Edition и Special Edition и нумерация версий у них разная. То есть в данном случае систему ты не идентифицировал.

Понятно, что в данном случае куда более важна версия самого PostgreSQL, чем Астры, но тем не менее.

Ни на официальном сайте, ни в википедии нет упоминания об Astra Linux 1.3 Common Edition. Так что, для тех, кто в теме, вариантов не остается: речь идет об Astra Linux 1.3 Special Edition.

Нумерация версий у разных edition’ов, однако, не пересекается (именно чтобы по номеру версии было всё ясно).