ПОЛЕЗНАЯ репликация с несколькими мастерами для Postgres?


16
  1. Я пробовал Postgres-XC, и он еще не реализует полный SQL (как SERIAL)

  2. Postgres-R выглядит интересно, но, по словам разработчиков, он "не готов к производству".

Поэтому я использовал pgpool-II 3.0.1. Да, это работает хорошо. Но, насколько я вижу, это только для 2 PG узлов.

Есть ли что-нибудь, что действительно готово к работе И способно работать с несколькими узлами PG?


Несколько лет назад мы столкнулись с той же проблемой. В конце концов мы перенесли все наши вещи в Oracle. Надеюсь, вы сможете найти пригодную для использования мультимастерную репликацию в эти дни, я не смотрел ... Удачи, тем не менее.
Grufftech

2
В собственной документации PostgreSQL говорится, что нужно использовать приложение промежуточного программного обеспечения :) .. " Синхронная репликация с несколькими хозяевами . PostgreSQL не предлагает этот тип репликации, хотя двухфазная фиксация PostgreSQL (PREPARE TRANSACTION и COMMIT PREPARED) может использоваться для реализации этого в код приложения или промежуточное программное обеспечение "
Уоррен

Вы не ограничены двумя узлами.
foocorpluser

Ответы:


6

Вы рассматривали Bucardo ? Это асинхронный мультимастер. Это не полностью завоевало популярность и не является общим решением, но, возможно, стоит попробовать.


1
Очевидно, я не был достаточно конкретен: мне нужна синхронная репликация. Кроме того, что это значит в FAQ? «Может ли Bucardo реплицироваться между более чем двумя мастерами? Нет. В настоящее время Bucardo поддерживает только мастер-мастер (и, конечно, мастер для многих рабов)». Так это мультимастер или нет?
mrkafk

4
Только если ваше определение «мульти» равно «2»!
Гмаллетт

Обратите внимание, что начиная с Bucardo 5 было снято ограничение только на 2 мастера
Joril

3

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

Список возможных решений Википедии, которые вы можете захотеть исследовать:

PostgreSQL предлагает несколько решений для репликации с несколькими мастерами, включая решения, основанные на двухфазной фиксации. Это Bucardo, rubyrep, PgPool и PgPool-II, PgCluster и Sequoia, а также некоторые проприетарные решения. Еще один многообещающий подход, реализующий горячую (синхронную) репликацию, - это Postgres-R, однако он все еще находится в разработке. Еще одним проектом, реализующим синхронную репликацию, является Postgres-XC. Postgres-XC также находится в стадии разработки.


Ничего себе, только чтение этого списка вызывает у меня шок и ужас. :)
Питер Айзентраут

Для меня это депрессия и ненависть :-)
voretaq7

Я бы подумал, что было бы возможно использовать систему, аналогичную etcd, для конфигурации и связи, возможно, запустив любой оператор обновления в двухфазном коммите ... сложная часть заключалась бы в том, чтобы не допустить узла до тех пор, пока он не будет захвачен и не совпадет с другими узлами. Я действительно хотел бы почти автоматическое решение для этого
Tracker1

3

Это сильно ориентировано на Java, но собственные API-интерфейсы клиента базы данных могут быть соединены с источниками данных JDBC. Mygsotis из вольфрама является примером MySQL, встроенной в мост JDBC.


  • Tungsten Enterpriese хорош для мультимастерного асинхронного. Я думаю, что это работает для MySQL, PostgreSQL и Oracle. Он может работать автономно или встраиваться в приложение Java. Я видел, как это работает для MySQL, но они утверждают, PostgreSQL. Их компонент Replicator имеет открытый исходный код, но полное решение состоит из нескольких частей и требует затрат на лицензирование. Первоначально у Continuent была Sequoia для одновременной работы нескольких мастеров, но они отказались от нее и создали Tungsten вместо асинхронной работы с несколькими мастерами - они считают, что масштабирование бизнеса более стратегически важно, чем синхронная согласованность ACID. Вольфрам написан на Java, поэтому они предлагают Myosotis для мостового подключения клиентов баз данных.

  • SymmetricDS хорош для асинхронного мультимастера. Это с открытым исходным кодом. Он устанавливает / удаляет триггеры для захвата обновлений, а не ведение журнала. Он может работать автономно или встраиваться в приложение Java.

  • HA-JDBC хорош для одновременной работы нескольких мастеров. Это заменяет старое несуществующее программное обеспечение как C-JDBC и Sequoia. Это с открытым исходным кодом. Он использует двухфазную фиксацию и работает для PostgreSQL, MySQL, Oracle, SQL Server, Derby, Sybase и многих других через диалекты. Он в основном для встраиваемых систем, поэтому встраивайте его в Java-приложение, чтобы связать его с PostgreSQL. Распределенные блокировки, последовательности, время, ранд и т. Д. Обрабатываются jGroups из Redhat / JBoss. Приятной особенностью является режим транзакции «последовательный», а не «параллельный», если ваше приложение столкнулось с блокировками и не поддерживает откат. Я успешно использовал этот «последовательный» режим для модернизации устаревшего приложения, которое не было осведомлено о кластере БД, поэтому в нем отсутствовал код повторной транзакции. Последовательный режим спас день и избежал неприятного переписывания.

  • Н2 хорош для одновременного использования нескольких мастеров. Это с открытым исходным кодом. Он поддерживает автономные базы данных или кластеры с использованием двухфазной фиксации, аналогично архитектуре HA-JDBC, но все в одном, вместо того, чтобы требовать дополнительный компонент для двухфазной фиксации. Не уверен, что он сам распределяет блокировки или зависит от сторонних разработчиков, таких как jGroups или Hazelcast.

Любая репликация на основе JDBC для PostgreSQL и других баз данных требует нативного моста JDBC, если ваше приложение уже не написано на Java. Для MySQL Tungsten Enterprise предлагает дополнительный компонент под названием Myosotis. Я успешно использовал это для соединения PHP / Perl / C / mysqlclient с JDBC, где источником данных JDBC оказался прокси-источник данных HA-JDBC, указывающий на 4-узловый кластер MySQL / InnoDB.

Tungsten поддерживает PostgreSQL в своих компонентах Replicator и Router, но не уверен насчет компонента Myosotis. Может быть. Компоненты Tungsten Replicator / Router предназначены для асинхронной работы нескольких мастеров, но Myosotis может соединить вас с альтернативным внутренним интерфейсом JDBC, таким как HA-JDBC или H2, для синхронного.

Если есть PostgreSQL, родной для моста JDBC, я хотел бы услышать об этом. Теоретически, любая база данных с драйвером JDBC типа 4 может быть соединена мостом. JDBC типа 4 говорит на собственном протоколе базы данных так же, как и на собственном клиентском интерфейсе для этой базы данных, поэтому должно быть однозначное сопоставление собственных вызовов с вызовами JDBC.


2

Ответ на это - оглушительное нет.


Прошло несколько лет с тех пор, как я проводил исследования, но моя компания пришла к такому выводу, когда мы попробовали.
Grufftech

1

Последние два года я использую londiste для репликации нескольких мастеров в postgresql.

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

Вы можете прочитать о londiste здесь ( http://pgfoundry.org/projects/skytools/ ), это то, что ребята из Skype используют для своего кластера, также они создали его, так что это вдвойне круто :)


Хм, это интересно, но согласно тому, что я видел здесь: wiki.postgresql.org/wiki/… , Londiste - Ведущий и Асинхронный? Так как это может быть мульти-мастер? Кроме того, мне действительно нужна синхронная репликация: транзакция должна завершиться неудачей, если произойдет сбой любого из (активных) узлов кластера.
mrkafk

Эта репликация является посттранзакционной, иначе она будет довольно медленной
lynxman

Я не хочу звучать как боль в заднице (придирчивость), но ... 1. Я использовал pgpool-II и транзакции проходили довольно быстро (хотя я не делал тесты), и 2. даже если Отдельная транзакция может быть медленнее, я не вижу веской причины для низкой пропускной способности транзакций. В любом случае, возможно, более важный момент - как Londiste multi-master? Могу ли я записать на pg сервер 1 и скопировать его на 2, и записать на pg сервер 2 и скопировать на сервер 1?
mrkafk


-2

Я нашел пригодную для использования систему репликации "multi-master":

  1. получить RabbitMQ http://www.rabbitmq.com/ - это промежуточное ПО для сообщений.

  2. настроить кластер Rabbit MQ в Rabbit.

  3. создайте очередь для каждого узла в кластере и свяжите их с обменом типа fanout.

Таким образом, сообщение отправляется на любой узел и любая очередь реплицируется на все остальные узлы. У меня есть рабочий код для этого!


2
@mrafk - не могли бы вы опубликовать / связать ваш "рабочий код"?
Уоррен

2
Какое это имеет отношение к репликации с postgres? Это будет распространять сообщения, но где вы получаете сообщения / обновления данных из БД и как он обновляет узлы, получающие сообщения в очереди сообщений?
Monksy

3
Это может быть решением фундаментальной проблемы, с которой вы столкнулись, но это не ответ на этот вопрос.
Том Андерсон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.