Комментарии 6
А не подскажите, встречались ли вы с решениями, которые реализуют следующую задачу: представим, что мы сделали копию работающего мастера1 и назвали её мастер2, тем самым мы создали грубо говоря форк основной базы данных (таких форков может быть много) далее с течением времени производится работа (без изменения схемы таблиц) как в мастере1, так и в мастере2 (то есть только добавляются новые записи, изменяются или удаляются существующие). Затем спустя какое-то время, принимается решение слить изменения сделанные в мастере2 в мастер1. Как итог — в мастере1 должны сохраниться изменения, которые были сделаны в нем ранее и примениться изменения, которые были сделаны в мастере2.
0
Возможно так. Сделать на серверах таблицы tbl_master1 и tbl_master2. На первом сервере рабочая таблица tbl_master1, а на втором — tbl_master2 (можно настроить через представление). И репликация tbl_master1 идет с первого на второй, а tbl_master2 — со второго на первый.
В таблицах сделать некое поле idserv — на первом оно по-умолчанию имеет значение «1», а на втором -«2».
Обработку реплик сделать либо отдельной процедурой в приложении, либо повесить триггер на таблицы именно на операции реплицирования. А чтоб зацикливания не произошло — проверять поле idserv, по которому определять, кто из серверов добавлял/модифицировал запись и свою же операцию не повторять по кольцу.
Если синхронизацию надо делать не постоянно, а только эпизодически, то использовать не триггеры, а приложение, запускаемое по крону или по команде пользователя.
Если хочется update записей без коллизий, то можно добавить либо блокировки из приложения на обоих серверах через что-то типа pg_try_advisory_lock на время правки записи, либо в таблицу сохранять начало и конец идентификаторов транзакции с обоих серверов (можно конечно время, но это не надежно), чтоб потом при накате реплицированной записи разрешать корректно имеющиеся коллизии.
В такой схеме объединить три и более сервера уже сложнее, понадобится tbl_master3 и т.д. Если б логические репликации можно было делать между таблицами с разными именами, то у всех можно было бы использовать рабочую tbl_master, а подписки на нее со всех серверов оформлять на таблицу tbl_master_rpl.
Кстати, последовательность для первичного ключа сделать на первом сервере нечетной, на втором — четной. Или просто задать разные диапазоны.
Сам я делал слив таблицы с нескольких серверов на один архивный и обработку на нем реплицируемых данных с помощью триггера в другую таблицу.
В таблицах сделать некое поле idserv — на первом оно по-умолчанию имеет значение «1», а на втором -«2».
Обработку реплик сделать либо отдельной процедурой в приложении, либо повесить триггер на таблицы именно на операции реплицирования. А чтоб зацикливания не произошло — проверять поле idserv, по которому определять, кто из серверов добавлял/модифицировал запись и свою же операцию не повторять по кольцу.
Если синхронизацию надо делать не постоянно, а только эпизодически, то использовать не триггеры, а приложение, запускаемое по крону или по команде пользователя.
Если хочется update записей без коллизий, то можно добавить либо блокировки из приложения на обоих серверах через что-то типа pg_try_advisory_lock на время правки записи, либо в таблицу сохранять начало и конец идентификаторов транзакции с обоих серверов (можно конечно время, но это не надежно), чтоб потом при накате реплицированной записи разрешать корректно имеющиеся коллизии.
В такой схеме объединить три и более сервера уже сложнее, понадобится tbl_master3 и т.д. Если б логические репликации можно было делать между таблицами с разными именами, то у всех можно было бы использовать рабочую tbl_master, а подписки на нее со всех серверов оформлять на таблицу tbl_master_rpl.
Кстати, последовательность для первичного ключа сделать на первом сервере нечетной, на втором — четной. Или просто задать разные диапазоны.
Сам я делал слив таблицы с нескольких серверов на один архивный и обработку на нем реплицируемых данных с помощью триггера в другую таблицу.
0
Эх. Жаль, что логическая репликация не работает с фрагментированными таблицами, а создавать подписку и подписчика для каждого фрагмента муторно.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Логическая репликация между версиями PostgreSQL