хочу странного. эпизодическая репликация

задача :
1. есть ларёчники коробейники (алексы)
2. со своей БД (каждый)
3. , с плохим без канала.

Иногда алексы "приезжают в город" [к юстасу], подключаются к серверам, и в этот момент надо скинуть очередь событий юстасу [merge -- репликация].

-- какие готовые велосипеды есть ?
-- какие лучше всего покрывают задачу ?


4. наряду с ними есть "ларёчники 1-й гильдии" -- с хорошим каналом

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

если кто делал на коленке -- из чего именно ? какие грабли найдены ?

PS дубль исходных данных в таблице[ах] событий (как в лондайсте) нежелателен (желательно только ключи OLD|NEW|OLD-and-NEW) -- в данных будут бинарники, и много.

?Ы

задача : 1. есть ларёчники коробейники (алексы) 2. со своей БД (каждый) 3. , с плохим без канала. Иногда алексы "приезжают в город" [к юстасу], подключаются к серверам, и в этот момент надо скинуть очередь событий юстасу [merge -- репликация]. -- какие готовые велосипеды есть ? -- какие лучше всего покрывают задачу ? 4. наряду с ними есть "ларёчники 1-й гильдии" -- с хорошим каналом -- решение должно покрывать оба случая, и быть достаточно оперативным для вторых (типа лондайста). если кто делал на коленке -- из чего именно ? какие грабли найдены ? PS дубль исходных данных в таблице[ах] событий (как в лондайсте) нежелателен (желательно только ключи OLD|NEW|OLD-and-NEW) -- в данных будут бинарники, и много.

Если Вы еще можете выбирать СУБД, то полностью покрываются Ваши потребности средствами репликации и синхронизации СУБД Sybase Anywhere

?Ы

задача : 1. есть ларёчники коробейники (алексы) 2. со своей БД (каждый) 3. , с плохим без канала. Иногда алексы "приезжают в город" [к юстасу], подключаются к серверам, и в этот момент надо скинуть очередь событий юстасу [merge -- репликация]. -- какие готовые велосипеды есть ? -- какие лучше всего покрывают задачу ? 4. наряду с ними есть "ларёчники 1-й гильдии" -- с хорошим каналом -- решение должно покрывать оба случая, и быть достаточно оперативным для вторых (типа лондайста). если кто делал на коленке -- из чего именно ? какие грабли найдены ? PS дубль исходных данных в таблице[ах] событий (как в лондайсте) нежелателен (желательно только ключи OLD|NEW|OLD-and-NEW) -- в данных будут бинарники, и много.

готовых велосипедов под задачу нет и не будет... уж очень специальная она в части 3.
Так что прийдется вам что то на уровне приложения делать или самому механизм писать.
Можно поверх slony сделать через http://slony.info/documentation/2.2/logshipping.html
скорее всего покроет и 3 и 4 (для 3 - sql logs для 4 - теже sql logs но доставляемые оперативно что сильно проще чем slony на десяток реплик настраивать).

при этом без "дубль исходных данных в таблице[ах] событий (как в лондайсте) нежелателе" вы никак не обойдетесь...
каким собственно образом вы себе представляете работу такой системы без лога всех изменений?

--Maxim Boguk
www.postgresql-consulting.ru

снкс.

Maxim Boguk
<> при этом без "дубль исходных данных в таблице[ах] событий (как в лондайсте) нежелателе" вы никак не обойдетесь... каким собственно образом вы себе представляете работу такой системы без лога всех изменений? <>

0. для простоты -- FK [как минимум -- на реплицируемые таблицы] в БД отсутствуют.

далее, -- тут 2 случая:
1. update PK разрешен
2. update PK запрещен.

если 2 -- то нас интересует [только] последнее событие с данным pk и [только] последнее актуальное данное по NEW.pk из самой таблицы, а не из лога. [если событие -- delete -- то кроме ключа тем паче ничего не нужно]

если 1 -- то видимо всё то же самое [интересует последнее событие по OLD.pk, и актулаьное состояние с NEW.pk [возможно -- вдоль цепи апдейтов пк]], но надо проверить, что в цепи событий с пк мы не обманем такой подход (пока тщательно не выверял диаграммы переходов).

покуда склоняюсь к тупому запрету смены всех pk триггерами. (это всё равно суррогаты)

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

?Ы

снкс. Maxim Boguk <> при этом без "дубль исходных данных в таблице[ах] событий (как в лондайсте) нежелателе" вы никак не обойдетесь... каким собственно образом вы себе представляете работу такой системы без лога всех изменений? <> 0. для простоты -- FK [как минимум -- на реплицируемые таблицы] в БД отсутствуют. далее, -- тут 2 случая: 1. update PK разрешен 2. update PK запрещен. если 2 -- то нас интересует [только] последнее событие с данным pk и [только] последнее актуальное данное по NEW.pk из самой таблицы, а не из лога. [если событие -- delete -- то кроме ключа тем паче ничего не нужно] если 1 -- то видимо всё то же самое [интересует последнее событие по OLD.pk, и актулаьное состояние с NEW.pk [возможно -- вдоль цепи апдейтов пк]], но надо проверить, что в цепи событий с пк мы не обманем такой подход (пока тщательно не выверял диаграммы переходов). покуда склоняюсь к тупому запрету смены всех pk триггерами. (это всё равно суррогаты) другое дело, если на события репликации надо реагировать на подписчике в том же порядке, как на события на паблишере -- тогда, с необходимостью, всё катать строго по логам.

Я понял вашу идею... как правило бизнес логика требует чтобы изменения накатывались в том же порядке что происходят в мастере... иначе на реплике будет несогласованные данные время от времени что недопустимо.
Если в вашей задаче это нормально - тогда 100% придется что то свое писать.

Я бы предложил например вариант:
триггер который обновляет mtime строки при любом обновлении.
Внешняя база хранит у себя время последней синхронизации... и когда ей надо пересинхронизироваться просто выбирает все обьекты c мастер базы с mtime>"время последней синхронизации".
Работает и для 3 и для 4 (просто 4ре делают это регулярно автоматически).
Если надо синхронизировать 2-5-10 таблиц - решение простое и вполне дубовое (но надо реализовывать в приложении конечно).

--Maxim Boguk
www.postgresql-consulting.ru

Maxim Boguk,

да, с ~~mtime -- интересно, напомнили
(вместо таймстампа -- генератор id "тика" -- во избежание провалов при синхронизации времени).

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


+ -- при ~mtime~ технике можно размножать подписчиков (у них персональные журналы).

?Ы

0. для простоты -- FK [как минимум -- на реплицируемые таблицы] в БД отсутствуют. далее, -- тут 2 случая: 1. update PK разрешен 2. update PK запрещен. если 2 -- то нас интересует [только] последнее событие с данным pk и [только] последнее актуальное данное по NEW.pk из самой таблицы, а не из лога. [если событие -- delete -- то кроме ключа тем паче ничего не нужно] если 1 -- то видимо всё то же самое [интересует последнее событие по OLD.pk, и актулаьное состояние с NEW.pk [возможно -- вдоль цепи апдейтов пк]], но надо проверить, что в цепи событий с пк мы не обманем такой подход (пока тщательно не выверял диаграммы переходов). покуда склоняюсь к тупому запрету смены всех pk триггерами. (это всё равно суррогаты) другое дело, если на события репликации надо реагировать на подписчике в том же порядке, как на события на паблишере -- тогда, с необходимостью, всё катать строго по логам.

я бы предложил
update РК запрещен, только тип данных PK использовал бы не serial, а uuid
+ mtime

Есть ли новости в вопросе merge-репликации?
Диспозиция: есть приложение на 2 сервера (75 онлайн клиентов на одном, 25 на другом) и 50 офлайн-подписчиков, merge репликация, настроенное на MS SQL сервер. Некоторые таблицы двунаправленная репликация (заказы, фактуры), некоторые только чтение (справочники), код сервера тоже реплицируется как DDL (процедуры, функции, тригеры). Аппликация не очень большая (база порядка 1,5 гигабайта), большая часть логики на сервере.

Лицензия на сервер истекает в 2020, рассматриваем вариант перевести это всё на PostgreSQL. Реально ли эту инфраструктуру настроить as it is (поточная репликация серверов, мультимастер между серверами и офлайном? Или придётся вешать костыли и самомтоятельно решать технические детали? Или merge-репликации в понятии MS SQL в PostgreSQL (отложенная выборочно двунаправленная репликация данных и структур) нет и не будет?

Шыфл,

1 . посмотрите баккардо. (не смотрел)

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


/*если же число серверов потенциально велико -- то планы деградируют.*/

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

> mtime

нужно только потом не

> mtime>"время последней синхронизации".

а

mtime>"время последней синхронизации" - "максимально возможное время длительности транзакции на изменение данных".

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


а так да -- я бы в первую очередь смотрел на londiste -- если по месту из-за появления лога-буфера в размер интервала синхронизации пролазите ну и с учетом асинхронностей всех этих