Назад | Перейти на главную страницу

Репликация PostgreSQL

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

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

Короткий ответ - такого решения для 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 в 2008 году:

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

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

Я написал кое-что о Log Shipping, walmgr и Slony-I, см.

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

И закинуть в кольцо еще один раствор: рубинреп.

Для сравнения с вашими требованиями:

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

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

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

Судя по вашим требованиям, PITR - самый простой способ решить вашу проблему:

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

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

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

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

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

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

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

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

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

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

См. Обсуждение здесь, может быть, это поможет:

http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

и

Конкуренты первой версии Bucardo, указанные ниже на странице:

http://www.planetpostgresql.org/

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

Теперь это является можно сортировать собственную репликацию с помощью Postgres, используя отправку журнала записи (WAL):

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

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

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

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

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

Postgres-R выглядело многообещающим, но я не знаю, жив ли проект.

Я сейчас смотрю на репликатор Tungsten, я все еще далек от какого-либо определенного вывода, но, вероятно, стоит взглянуть.

www.continuent.com