Высокодоступный Postgres. Кластер Active/Standby. Выбор решения

Собственно, встала задача сделать высокодоступный postgres db для такой вот конфигурации:

Clipboard01

Согласно священным писаниям на сайте http://www.postgresql.org/ у меня ровно 7 вариантов решения:

  • Active-active нам не нужен, поэтому варианты Synchronous/Asynchronous Multimaster Replication отпадают;
  • Shared Disk Failover: отпадает, т.к. в этом случае мы всего лишь переносим единую точку отказа на наше дисковое (ну или NAS-файло) хранилище;

Clipboard02

  • File System Replication c помощью DRBD: отпадает, т.к. DRBD реплицирует на блочном уровне и не в курсе, что он реплицирует. Т.е. может нареплиировать так, что после падения active-узла, standby просто не поднимется из за ошибок в структуре файлов базы.

Clipboard03

 

  • Statement-Based Replication с помощью pgpool с использованием watchdog: получается слишком сложная конфигурация, плюс такая репликация работает только пока оба узла живы. Если slave отключается на какое-то время, а в это время с мастером идет работа, «догнать» произведенные изменения на slave позже, после его включения, не получится.

Clipboard05

  • Trigger-Based Master-Standby Replication с помощью Slony: возможно. Отвратило от этого варианта то, что А) после появления встроенной в Postgres потоковой репликации (см. п. ниже) слониковой репликацией для целей простого создания высокодоступных конфигураций практически не пользуются; Б) в решении появляется дополнительная сущность — ПО Slony с его триггерами, настройками и глюками; В) для получения полного решения (а нам ведь не только реплицировать данные нужно, но и точку доступа к ним, т.е. IP адрес передвигать между узлами в случае failover) нам все равно понадобится применять какое-то дополнительное приспособление типа того же pgpool или какое-то кластерное ПО. В общем — и это отпадает.

Clipboard06

  • Transaction Log Shipping — встроенная в Postgres потоковая репликация: кажется, подходит. Кроме того, такой вариант, как показал обзор интернетов, является наиболее часто используемым при построении высокодоступных конфигураций Postgres со времен появления этой самой репликации (выхода версии 9).

Далее, вспоминаем: «нам ведь не только реплицировать данные нужно, но и точку доступа к ним, т.е. IP адрес передвигать между узлами в случае failover». «Двигать адрес» можно двумя путями:

  • С использованием pgpool и его функциональности watchdog, ну или или какого-то подобного ему sql или даже tcp-прокси. Вариант лично мне не подошел, ибо А) в конфигурации появляется еще одна сущность — pgpool, со своими настройками и глюками Б) pgpool работает как прокси, пропуская через себя SQL запросы (даже пытается их парсить!) — для моей конфигурации это было однозначно плохо. Отказать.

watchdog_master_slave (1)

 

  • с использованием стандартного кластерного ПО Linux (имею в виду corosync + pacemaker). Решение замечательно подходит к задаче, ПО находится в высокой степени зрелости и (что важно!) поддерживается, развивается и применяется. Опять же, обзор интернетов показал что «я не один такой», поэтому я приободрился и приготовился к свершениям.

Clipboard07

Собственно о том, что получилось в результате (с приложением скриптов) — во второй части саги.

Реклама

2 thoughts on “Высокодоступный Postgres. Кластер Active/Standby. Выбор решения

  1. Уведомление: Высокодоступный Postgres. Кластер Active/Standby со stream-репликацией между узлами. Реализация | Системная архитектура и все-все-все

  2. Уведомление: PostgreSQL — репликация, ссылки | Pilat66 blog

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s