Мы постоянно бьем это по офису, и этот вопрос продолжает возникать. Как вы справляетесь с репликацией PostgreSQL? Я даже не говорю о продвинутых кластерах, я просто говорю о простоте с Master-Slave, Master-MultiSlave и Master-Master. Я считаю, что настроить его для MySQL, как правило, довольно просто. Отказоустойчивость проста, если не идеальна, особенно в том, как легко ее настроить. Мы играли со Slony, но он слишком сложный (изменения схемы требуют вмешательства, новые базы данных требуют вмешательства и т. Д.). PGPool2 был довольно хорош, пока узел не вышел из строя, и мы не смогли найти изящный способ (кроме сброса всего и повторного заполнения упавшего узла), чтобы вернуть репликацию обратно в синхронизацию. В основном вот что я обычно ищу:
- Простая настройка (я согласен на сложную настройку, но ее легко расширить)
- Упрощенное переключение при сбое
- Чтобы вернуть упавший узел обратно, требуется время (то есть, как, например, mysql. Сервер отключается, вы запускаете его и ждете, пока репликация наверстает упущенное)
- Изменения схемы не нарушают репликацию
- Добавление новой базы данных на сервер происходит незаметно (то есть, как и MySQL, вы можете реплицировать весь сервер БД, поэтому на главном сервере создается новая база данных, которая автоматически распространяется на ведомый)
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 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 для получения дополнительной информации.
источник
И бросить другое решение в кольцо: rubyrep.
Чтобы сравнить с вашими требованиями:
Да, это на самом деле основной фокус rubyrep.
Да. На самом деле rubyrep выполняет репликацию master-master - для восстановления после сбоя никаких действий не требуется. Просто начните использовать другую базу данных.
Да.
Для изменений не первичного ключа репликация даже не должна останавливаться (но убедитесь, что схема изменяется с обеих сторон одновременно).
Чтобы добавить / удалить таблицы, просто перезапустите демон репликации. Только изменение столбца первичного ключа таблицы занимает немного усилий.
Это поддерживается только ограниченным образом: каждый rubyrep Программа установки реплицирует только одну базу данных одновременно. (Но очень легко настроить репликацию для нескольких баз данных.)
источник
Вы не упомянули наличие горячего чтения-ведомого в качестве требования, поэтому я собираюсь предложить использовать Heartbeat либо с общим хранилищем, либо с DRBD. Это только делает правильные вещи, и администрация - бриз. Это Linux-эквивалент более старой кластеризации Microsoft SQL Server. Один узел активен, а другой - пассивен, в то время как данные распределяются между ними. Вам не нужно беспокоиться о репликации на основе SQL, поскольку все это обрабатывается ниже на уровне блоков.
Серьезно, это безусловно лучшее решение, если вам не нужно читать рабов. Архивные материалы WAL были в лучшем случае легкими, и вы должны все настроить заново, если вы когда-нибудь нарушите процесс доставки для перезагрузки сервера. Слони и лондист не режут горчицу. Если вы хотите остаться в главном дереве исходных текстов и не выходить на рынок, Heartbeat - ваш лучший выбор.
источник
Из ваших требований кажется, что PITR - это самый простой способ решить вашу проблему:
Оперативное резервное копирование и восстановление на момент времени (PITR)
Вы не сказали, что вам нужно запрашивать подчиненный сервер, поэтому PITR может быть правильным.
Это стандартная часть PostgreSQL начиная с версии 8.0, поэтому у вас, вероятно, уже есть все необходимое для его запуска и работы.
Если вы находите инструкции слишком подробными, взгляните на SkyTools WalMgr, который сделает процесс создания / перехода к горячим резервным данным с помощью одной команды.
Для более сложных сценариев репликации у меня был хороший опыт Slony-1, но в PostgreSQL есть много хороших вариантов репликации / HA.
источник
Если вы хотите асинхронную репликацию 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 Version One, находящиеся внизу страницы:
http://www.planetpostgresql.org/
источник
Там действительно нет никаких бесплатных / с открытым исходным кодом способов обеспечить то, что вы ищете. Если вы хотите что-то, что так под ключ, посмотрите на различные сторонние коммерческие решения репликации.
Теперь, есть возможность сортировать рулона собственный репликации с Postgres , используя протокол записи головки (WAL) Доставка:
Это в основном то, где вы можете перевести вторичный узел в режим непрерывного восстановления и импортировать в него журналы транзакций каждый {небольшой интервал}. Конфигурация Postgres имеет «заглушки», позволяющие вам делать определенные вещи, когда Postgres завершает WAL и т. Д. Нет, и именно на этом основана эта настройка - с использованием этих «заглушек».
Однако это не позволяет выполнять мастер-мастер и / или циклическую репликацию.
В любом случае, это определенно работает для аварийной ситуации, но я бы не назвал это «простой настройкой», «упрощенным переключением при отказе», «бесшовным» или чем-то в этом роде.
источник
За исключением добавления новой базы данных, вы можете попробовать Mammoth Replicator ( https://projects.commandprompt.com/public/replicator ). Он с открытым исходным кодом, прост в настройке и поддерживает аварийное переключение. Основными ограничениями являются единая база данных и невозможность реплицировать изменения DDL, оба находятся в списке TODO.
источник
Postgres-R выглядел многообещающе, но я не знаю, жив ли проект до сих пор.
источник
В настоящее время я смотрю на вольфрамовый репликатор, я все еще далек от какого-либо определенного заключения, но, вероятно, стоит посмотреть.
www.continuent.com
источник