Управление на високата наличност на PostgreSQL – Част I:Автоматично отказване на PostgreSQL

Управлението на висока достъпност (HA) във вашия PostgreSQL хостинг е много важна тема, за да гарантирате, че клъстерите за внедряване на база данни поддържат изключително време на работа и силна оперативна производителност, така че данните ви винаги да са достъпни за вашето приложение. В по-ранна публикация в блога ви запознахме с конфигурирането на висока наличност за PostgreSQL с помощта на поточно репликация, а сега ще ви покажем как най-добре да управлявате високата наличност от страна на клиента.

Има множество налични инструменти за управление на високата наличност (HA) на вашите клъстери за внедряване на PostgreSQL с помощта на стрийминг репликация. Тези решения предлагат възможности за автоматично преодоляване на срив, следят наличността и състоянието на системата, репликация, управление на потребители и други полезни административни задачи за случаи на използване на бази данни Postgres. Някои от известните решения с отворен код включват:

1. Автоматично отказване на PostgreSQL от ClusterLabs

2. Мениджър на репликация за PostgreSQL клъстери от repmgr (2ndQuadrant)

3. Patroni от Zalando

Всеки инструмент предоставя свой собствен начин за управление на клъстерите с висока наличност на PostgreSQL. В нашата серия от три части от публикации за HA за PostgreSQL ще споделим общ преглед, предпоставките и резултатите от работата и тестовете за всеки от тези три инструмента. Тук, в част 1, ще се потопим дълбоко в PAF решението от ClusterLabs.

• Управление на висока наличност в PostgreSQL – Част II:Мениджър на репликация
• Управление на висока наличност в PostgreSQL – Част III:Patroni

Как да управлявате високата наличност за вашата PostgreSQL база данни?

PostgreSQL Automatic Failover (PAF) е решение за управление с висока наличност за PostgreSQL от ClusterLabs. Той използва синхронна репликация на Postgres, за да гарантира, че няма загубени данни по време на операцията за преодоляване на срив. Той използва популярния стандартен за индустрията пейсмейкър и стек Corosync. С приложенията Pacemaker и Corosync заедно ще можете да откривате грешки в базата данни на PostgreSQL в системата и да действате съответно.

Пейсмейкърът е услуга, способна да управлява много ресурси и прави това с помощта на техните агенти за ресурси. След това ресурсните агенти носят отговорността да боравят с конкретен ресурс, как трябва да се държат и да информират Pacemaker за резултатите си.

Вашата реализация на ресурсен агент трябва да отговаря на спецификацията на Open Cluster Framework (OCF). Тази спецификация определя поведението на ресурсните агенти и прилагането на методи като спиране, стартиране, повишаване, понижаване и взаимодействие с Pacemaker.

PAF е OCF ресурсен агент за Postgres, написан на Perl. След като вашият клъстер на базата данни е изграден с помощта на вътрешна стрийминг репликация, PAF е в състояние да изложи на Pacemaker текущото състояние на екземпляра на PostgreSQL на всеки един от възлите на базите данни:главен, подчинен, спрян, наваксващ, балансьор на натоварване и т.н.

Как работи Postgres Automatic Failover

PAF комуникира с Pacemaker относно състоянието на клъстера и наблюдава функционирането на базата данни PostgreSQL. В случай на повреда, той информира Pacemaker и ако няма шанс текущият главен код да бъде възстановен, той ще задейства избор между един от текущите сървъри на база данни в готовност. Със стабилния пейсмейкър на място, Postgres Automatic Failover ще извършва действия за управление като стартиране, спиране, наблюдение и превключване на отказ на всички възли на Postgres бази данни.

Управление на високата наличност в PostgreSQL – Част I:Автоматично отказване от ClusterLabsClick To Tweet

Автоматично отказване на PostgreSQL за конфигуриране с висока достъпност (HA)

• PAF поддържа PostgreSQL версия 9.3 и по-нова.
• PAF не носи отговорност за PostgreSQL master/standby създаване или настройката му - трябва да създадете и настроите стрийминг репликация, преди да използвате PAF.
• PAF не редактира никакви изисквания за конфигурация или настройка на PostgreSQL. Въпреки това, той изисква от потребителите на база данни да следват няколко предпоставки като:
  • Slave трябва да бъде конфигуриран като горещ режим на готовност. Горещи резервни подчинени възли  могат да бъдат заявени като бази данни само за четене.
  • Трябва да бъде предоставен файл с шаблон за възстановяване (по подразбиране:/recovery.conf.pcmk) с параметри по-долу:
    • режим_готовност =включено
    • recovery_target_timeline =„най-ново“
    • primary_conninfo трябва да има дефиниран параметър application_name и зададен на име на локален възел, както в Pacemaker.
• PAF разкрива множество параметри, свързани с управлението на ресурс на Postgres. Това може да бъде конфигурирано така, че да отговаря на нечии изисквания. По-долу са параметрите:
  • bindir: местоположение на двоичните файлове на PostgreSQL (по подразбиране:/usr/bin)
  • pgdata: местоположение на PGDATA на вашия екземпляр (по подразбиране:/var/lib/pgsql/data)
  • datadir: път до директорията, зададена в data_directory от вашия postgresql.conf файл
  • pgost: директорията на сокета или IP адреса, който да се използва за свързване с локалния екземпляр (по подразбиране:/tmp)
  • pgport: порта за свързване с локалния екземпляр (по подразбиране:5432)
  • шаблон_за_възстановяване: локалния шаблон, който ще бъде копиран като файл PGDATA/recovery.conf. Този шаблонен файл трябва да съществува на всички възли (по подразбиране:$PGDATA/recovery.conf.pcmk)
  • start_opts: Допълнителни аргументи, дадени на процеса Postgres при стартиране. Вижте “postgres –help” за налични опции. Полезно, когато файлът postgresql.conf не е в директорията с данни (PGDATA), напр.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
  • system_user: системния собственик на процеса на вашия екземпляр (по подразбиране:postgres)
  • maxlag: максималното забавяне, позволено в режим на готовност, преди да зададем отрицателен основен резултат върху него

Професионалисти за автоматично прекратяване при отказ на Postgres

• PAF предоставя на потребителя безплатна практическа конфигурация и настройка на PostgreSQL.
• PAF може да се справи с повреда на възел и да задейства избори, когато главният се свали.
• Поведението на кворума може да бъде наложено в PAF.
• Той ще осигури цялостно решение за управление на бази данни с висока достъпност (HA) за ресурса, включително стартиране, спиране и наблюдение и обработка на сценарии за изолация на мрежата.
• Това е разпределено решение, което позволява управлението на всеки възел от друг възел.

Недостатъци за автоматично прекратяване при отказ на Postgres

• PAF не открива дали възел в режим на готовност е неправилно конфигуриран с неизвестен или несъществуващ възел в конфигурация за възстановяване. Възелът ще бъде показан като подчинен, дори ако режимът на готовност работи без свързване към главния/каскадния възел в режим на готовност.
• Изисква допълнителен порт (по подразбиране 5405) да бъде отворен за комуникация на компонентите Pacemaker и Corosync чрез UDP.
• Не поддържа конфигурация, базирана на NAT.
• Няма поддръжка на pg_rewind.

Висока наличност за тестови сценарии на PostgreSQL

Проведохме няколко теста, за да определим възможностите на PostgreSQL управлението с висока наличност (ha) с помощта на PAF в някои случаи на употреба. Всички тези тестове бяха стартирани, докато приложението работеше и вмъкваше данни в базата данни PostgreSQL. Приложението е написано с помощта на PostgreSQL Java JDBC драйвер, използващ възможността за преодоляване на връзката.

Сървърни тестове в режим на готовност

Тестове за главен/основен сървър

Тестове за мрежова изолация

Разни тестове

PAF решението ли е за PostgreSQL High Availability?

Автоматичното отказване на Postgres предоставя няколко предимства при работа с PostgreSQL висока наличност (HA) в много случаи на употреба. PAF използва превключване при отказ на IP адрес вместо рестартиране на режим на готовност, за да се свърже с новия главен по време на събитие при отказ. Това се оказва изгодно в сценарии, при които потребителят не иска да рестартира резервните възли. PAF също се нуждае от много малко ръчна намеса и управлява цялостното здраве на всички ресурси на базата данни на Postgres. Единственият случай, в който ръчната намеса е изискване, е в случай на разминаване на данните във времевата линия, когато потребителят може да избере да използва pg_rewind.

В част 1 обсъдихме възможностите и работата на PostgreSQL Automatic Failover (PAF) от ClusterLabs, а в част 2 ще обсъдим същите аспекти с висока наличност, използвайки Мениджъра на репликация за PostgreSQL клъстери (repmgr) от 2ndQuadrant. Не забравяйте да проверите отново за част 3, където също ще покрием Patroni от Zalando и сравним и трите решения с отворен код, за да ви помогнем да определите най-подходящото за вашето приложение.

В блога на част 1 обсъдихме възможностите, най-добрите практики и работата на PAF от ClusterLabs, а в публикация в блога част 2 ще обсъдете същата тема за аспектите с висока наличност с помощта на Мениджъра на репликация за Postgresql клъстери (repmgr) от 2ndQuadrant. Не забравяйте да проверите отново за публикацията ни в блога на част 3, където също ще разгледаме Patroni от Zalando и ще сравним трите решения с отворен код, за да ви помогнем да определите най-добрите практики и идеалното за вашите бизнес приложения.