Репликация PostgreSQL


45

Мы постоянно бьем это по офису, и этот вопрос продолжает возникать. Как вы справляетесь с репликацией PostgreSQL? Я даже не говорю о продвинутых кластерах, я просто говорю о простоте с Master-Slave, Master-MultiSlave и Master-Master. Я считаю, что настроить его для MySQL, как правило, довольно просто. Отказоустойчивость проста, если не идеальна, особенно в том, как легко ее настроить. Мы играли со Slony, но он слишком сложный (изменения схемы требуют вмешательства, новые базы данных требуют вмешательства и т. Д.). PGPool2 был довольно хорош, пока узел не вышел из строя, и мы не смогли найти изящный способ (кроме сброса всего и повторного заполнения упавшего узла), чтобы вернуть репликацию обратно в синхронизацию. В основном вот что я обычно ищу:

  • Простая настройка (я согласен на сложную настройку, но ее легко расширить)
  • Упрощенное переключение при сбое
  • Чтобы вернуть упавший узел обратно, требуется время (то есть, как, например, mysql. Сервер отключается, вы запускаете его и ждете, пока репликация наверстает упущенное)
  • Изменения схемы не нарушают репликацию
  • Добавление новой базы данных на сервер происходит незаметно (то есть, как и MySQL, вы можете реплицировать весь сервер БД, поэтому на главном сервере создается новая база данных, которая автоматически распространяется на ведомый)

MySQL справляется с большинством из них довольно хорошо, но я очень люблю PostgreSQL. Кроме того, у нас есть несколько ситуаций, когда это наш единственный вариант, и мы хотели бы добавить репликацию к миксу. Что вы используете в настоящее время, и как вы относитесь к своему решению? Обещаю, что это не пост MySQL против PostgreSQL, потому что это не то, что я пытаюсь начать. :)


3
Я заинтересован в ответе на это. Исходя из фона MySQL, параметры репликации для PSQL являются, по меньшей мере, сельскохозяйственными.
Дейв Чейни

Да, до сих пор каждый вариант, с которым я играл, имел существенные недостатки.
Надеюсь,

Я подозреваю, что больше ничего нет, но мне не терпится, чтобы кто-то доказал, что я не прав
Винко Врсалович

Кстати, вы пробовали pgsql-general@postgresql.org?
Винко Врсалович

Ответы:


9

Краткий ответ - пока нет такого решения для PostgreSQL, если вам нужны онлайн-ведомые устройства только для чтения.

В настоящее время в этой области ведется два крупных проекта разработки, которые включены в PostgreSQL 9.0 (весна / лето 2010), а именно:

  • Синхронная репликация:

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

  • Только для чтения горячих резервных рабов:

http://wiki.postgresql.org/wiki/Hot_Standby

которые в совокупности направлены на достижение простоты использования репликации в стиле MySQL за вычетом ошибок / проблем, которые имеет MySQL, плюс надежность, известную пользователям из PostgreSQL.

Все это было запущено манифестом из PostgreSQL Core Team в 2008 году:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

На сегодняшний день решениями репликации PostgreSQL с самой большой базой пользователей являются Slony-I (более дорогой для записи, вносит изменения в схему), WAL shipping / walmgr (Slaves не могут быть использованы онлайн) и pgQ / londiste из Skype / Skytools ( больше инструментов / строительных блоков, чем готовое решение).

Я написал несколько вещей о журнале доставки, Walmgr и Slony-I, смотрите

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 для получения дополнительной информации.


6
Синхронная репликация + горячее резервирование теперь доступны - см. Wiki.postgresql.org/wiki/… для хорошего обзора доступных методов
Дэвид Фрейзер

5

И бросить другое решение в кольцо: rubyrep.

Чтобы сравнить с вашими требованиями:

  • Простая настройка
    Да, это на самом деле основной фокус rubyrep.
  • Упрощенное аварийное переключение
    Да. На самом деле rubyrep выполняет репликацию master-master - для восстановления после сбоя никаких действий не требуется. Просто начните использовать другую базу данных.
  • Изменения схемы не нарушают репликацию.
    Да.
    Для изменений не первичного ключа репликация даже не должна останавливаться (но убедитесь, что схема изменяется с обеих сторон одновременно).
    Чтобы добавить / удалить таблицы, просто перезапустите демон репликации. Только изменение столбца первичного ключа таблицы занимает немного усилий.
  • Добавление новой базы данных на сервер происходит незаметно (то есть, как и MySQL, вы можете реплицировать весь сервер БД, поэтому новая база данных создается на главном сервере, она автоматически распространяется на ведомое устройство).
    Это поддерживается только ограниченным образом: каждый rubyrep Программа установки реплицирует только одну базу данных одновременно. (Но очень легко настроить репликацию для нескольких баз данных.)

4

Вы не упомянули наличие горячего чтения-ведомого в качестве требования, поэтому я собираюсь предложить использовать Heartbeat либо с общим хранилищем, либо с DRBD. Это только делает правильные вещи, и администрация - бриз. Это Linux-эквивалент более старой кластеризации Microsoft SQL Server. Один узел активен, а другой - пассивен, в то время как данные распределяются между ними. Вам не нужно беспокоиться о репликации на основе SQL, поскольку все это обрабатывается ниже на уровне блоков.

Серьезно, это безусловно лучшее решение, если вам не нужно читать рабов. Архивные материалы WAL были в лучшем случае легкими, и вы должны все настроить заново, если вы когда-нибудь нарушите процесс доставки для перезагрузки сервера. Слони и лондист не режут горчицу. Если вы хотите остаться в главном дереве исходных текстов и не выходить на рынок, Heartbeat - ваш лучший выбор.


2

Из ваших требований кажется, что PITR - это самый простой способ решить вашу проблему:

Оперативное резервное копирование и восстановление на момент времени (PITR)

Вы не сказали, что вам нужно запрашивать подчиненный сервер, поэтому PITR может быть правильным.

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

Если вы находите инструкции слишком подробными, взгляните на SkyTools WalMgr, который сделает процесс создания / перехода к горячим резервным данным с помощью одной команды.

Для более сложных сценариев репликации у меня был хороший опыт Slony-1, но в PostgreSQL есть много хороших вариантов репликации / HA.


а эти варианты есть ...?
Дейв Чейни

... перечислено в сообщении в блоге blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html упоминается в одном из ответов ...
dpavlin

2

Если вы хотите асинхронную репликацию master / slave, рассмотрите Londiste (часть пакета skytools из Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

Его легко установить, добавить новую БД легко, репликация просто «догоняет».

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

Некоторые изменения схемы просты. Другие сложнее. Это зависит от вашего приложения. Предполагается, что следующая версия skytools (версия 3.0) будет обрабатывать DDL и включать средства, облегчающие отработку отказа.

Мы переехали в Лондон, когда нашли Слони слишком болезненным для использования.



1

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

Теперь, есть возможность сортировать рулона собственный репликации с Postgres , используя протокол записи головки (WAL) Доставка:

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

Это в основном то, где вы можете перевести вторичный узел в режим непрерывного восстановления и импортировать в него журналы транзакций каждый {небольшой интервал}. Конфигурация Postgres имеет «заглушки», позволяющие вам делать определенные вещи, когда Postgres завершает WAL и т. Д. Нет, и именно на этом основана эта настройка - с использованием этих «заглушек».

Однако это не позволяет выполнять мастер-мастер и / или циклическую репликацию.

В любом случае, это определенно работает для аварийной ситуации, но я бы не назвал это «простой настройкой», «упрощенным переключением при отказе», «бесшовным» или чем-то в этом роде.


этот ответ дублирует предложение PITR, поскольку PITR использует WAL :-)
dpavlin

1

За исключением добавления новой базы данных, вы можете попробовать Mammoth Replicator ( https://projects.commandprompt.com/public/replicator ). Он с открытым исходным кодом, прост в настройке и поддерживает аварийное переключение. Основными ограничениями являются единая база данных и невозможность реплицировать изменения DDL, оба находятся в списке TODO.



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