Высокая доступность для postgresql

Я новичок в базе данных PostgreSQL. Недавно нашему разработчику потребовалось сделать некоторые обновления в наших системах.

Из-за этого мы планируем реализовать какой-то метод, чтобы реализовать отработку отказа базы данных.

Основываясь на моем чтении из PostGreSQL вики здесь , мы пытаемся реализовать либо теплый режим ожидания или горячего резерва. Итак, мои вопросы:

1. Каковы основные различия между ними?
2. Какой лучше?
3. Есть ли какой-нибудь другой метод, который мы могли бы рассмотреть для обеспечения высокой доступности в наших базах данных Postgres?

1a. Теплый резерв - это «живое», инкрементное резервное копирование, снабженное полными блоками изменений (сегменты wal) по 16 Мб каждый, которые отправляются на резервный узел после заполнения. Вы не можете запросить узел горячего резервирования. Изменения в 16 мегабайт (по умолчанию) могут означать много транзакций, в случае отказа мастера они будут потеряны.

1б. Hot Standby . (также «живое» инкрементное резервное копирование). Небольшие изменения отправляются на ведомое устройство (записи wal, которые являются крошечными частями сегмента wal). Вы можете запросить (только для чтения) узел горячего резервирования. Окно для потерянных транзакций в случае отказа мастера очень маленькое. Существуют синхронные и асинхронные узлы горячего резервирования, синхронный узел заставит мастера ждать, пока он подтвердит применение изменений, а затем мастер подтвердит транзакцию. В асинхронной репликации мастер отправляет записи wal и не ожидает подтверждения , Первый требует очень надежной и быстрой связи между ведущим и ведомым устройствами, также добавляет служебные данные к ведущему, но гарантирует отсутствие потери данных.

Относительно инкрементных резервных копий: 1. Вы берете базовую копию всей вашей установки базы данных. 2. Отправьте его рабу. 3. Настройте его, чтобы наверстывать упущенное.

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

Одним из дополнений к этой настройке является pg-pool. Он действует как прокси между приложением и серверами, участвующими в конфигурации репликации, подобной описанной выше, имеет функции балансировки нагрузки и возможности параллельных запросов. Он также может обеспечить автоматическое переключение при сбое. http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

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

Вы можете перемещать эти данные WAL для репликации либо по 16 МБ файла за раз, используя средство archive_command, либо используя Streaming Replication (SR). Если вы используете SR, вам действительно следует настроить архивирование, и сервер будет переключаться между ними по мере необходимости.

Вы можете иметь сервер горячего резервирования, который не может отвечать на запросы. Или вы можете иметь сервер горячего резервирования, который может отвечать только для чтения. Это не связано с тем, как данные попадают в режим ожидания.

Каждый из этих двух вариантов сочетается с каждым другим, и вы можете иметь все четыре комбинации. Вы можете иметь горячее резервирование, отвечая на запросы, когда подается файл с сегментами WAL. У вас может быть сервер потоковой репликации, на котором не включен горячий резерв, поэтому он не будет отвечать на запросы. Просто сейчас наиболее распространенным является потоковая репликация и горячее резервирование. Это полный набор функций. Опять же, не игнорируйте старый механизм archive_command только потому, что сейчас его можно избежать. Это все еще может спасти вас от потоковых сбоев, которые в противном случае трудно восстановить.