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

Внедрявате PostgreSQL в облака и искате ли да разберете опциите си за постигане на висока наличност? В предишната ни публикация в блога, Управление на високата наличност в PostgreSQL – част I, обсъдихме възможностите и функционирането на PostgreSQL Automatic Failover (PAF) от ClusterLabs. В част II ви представяме алтернативен инструмент с отворен код, Replication Manager от 2ndQuadrant, който ще бъде последван отблизо от част III, където се потапяме в нашата трета алтернатива, Patroni от Zalando.

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

Мениджър на репликация (repmgr)

repmgr е пакет от инструменти с отворен код, разработен от 2ndQuadrant за управление на репликация и отказ на вашите PostgreSQL клъстери. Той предоставя инструментите за настройка, конфигуриране, управление и наблюдение на репликацията на PostgreSQL, а също така ви позволява да извършвате ръчно превключване и задачи за превключване при отказ с помощта на помощната програма repmgr. Този безплатен инструмент поддържа и подобрява вградената стрийминг репликация на PostgreSQL.

Мениджърът на репликация предоставя два основни инструмента за управление на репликацията и преодоляването на отказ на PostgreSQL.

repmgr

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

repmgrd

Това е демонът, който:

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

Как работи

repmrg не само управлява репликацията на PostgreSQL клъстери, но също така има възможности за настройка на резервните сървъри за репликация. След първоначалната инсталация трябва да направим промени в конфигурационния файл repmgr (repmgr.conf) с необходимите подробности на всеки сървър. Когато сървърът е конфигуриран, той трябва да бъде регистриран с repmgr с помощта на командата repmgr primary/standby register. Първо, основният възел е настроен и регистриран. След това се създават и конфигурират резервни сървъри с помощта на командата repmgr standby clone, която клонира възела в режим на готовност на PostgreSQL от друг PostgreSQL сървър.

Мениджърът на репликация използва функцията за разширения на PostgreSQL и създава своя собствена схема в базата данни на клъстера, за да съхранява информацията, свързана с клъстера. Инсталирането на разширението и създаването на схемата се случва по време на регистрацията на основния сървър с помощта на repmgr. След като настройката приключи, ръчните административни операции като популяризиране, следване, превключване и т.н. могат да се извършват с помощта на помощната програма repmgr. За работа с превключване се изисква SSH без парола да бъде настроен между възлите.

Автоматичното преминаване при отказ може да се настрои с помощта на repmgrd. repmgrd изисква споделена библиотека „repmgr“ да бъде заредена в момента на стартиране на PostgreSQL сървъра. Името на библиотеката трябва да бъде споменато в shared_preload_libraries конфигурационен параметър във файла postgresql.conf. Освен това, за да работи repmgrd, failover=automatic параметърът трябва да бъде зададен във файла repmgr.conf. След като всички тези параметри са зададени, демонът repmgrd започва активно да наблюдава клъстера. Ако има някаква повреда в първичния възел, той ще се опита да се свърже отново няколко пъти. Когато всички опити за свързване към първичния се провалят, най-подходящият режим на готовност се избира чрез избор като нов първичен от repmgrd.

repmgr също поддържа известия за събития. Той има набор от предварително дефинирани събития и съхранява всяко възникване на тези събития в таблицата repmgr.events. repmgr позволява да се предават известия за събития към дефинирана от потребителя програма или скрипт, който може да предприеме допълнителни действия, като изпращане на имейл или задействане на предупреждение. Това става чрез задаване на event_notification_command параметър в repmgr.conf.

Как се справя със сценария за разделен мозък?

repmgr се справя със сценарии на разделен мозък, използвайки местоположението параметър, където всеки възел трябва да посочи параметъра за местоположение въз основа на центъра за данни, в който е поставен. В случай на разделяне на мрежата, repmgr ще осигури популяризирането на възела, който е на същото място като основния. Ако не намери възел в това местоположение, няма да популяризира нито един възел на нито едно място.

Той също обработва мрежовата изолация в случай на четен брой сървъри в клъстер. Това се прави с помощта на допълнителен възел, наречен сървър-свидетел. Свидетелският сървър е възел, който се разглежда само за преброяване на мнозинството на гласовете. Няма да има инсталация на PostgreSQL на този сървър и следователно няма да играе роля в репликацията.

Има ли някакви изисквания за настройка?

repmgr ще изисква специална база данни и потребител с привилегии на суперпотребител. Има обаче и опция да предоставите суперпотребител, ако не желаете да дадете на суперпотребителя достъп до repmgr потребител.
Ако искате repmgr да копира конфигурационни файлове, които се намират извън директорията с данни на PostgreSQL, и/или да тествате функционалността за превключване, ще ви трябват и SSH връзки без пароли между двата сървъра и rsync трябва да бъде инсталиран.
Ако възнамерявате да използвате базирани на услуги команди, различни от pg_ctl (който се използва от repmgr по подразбиране), за стартиране, спиране, презареждане и рестартиране, можете да ги посочите в repmgr конфигурационен файл (repmgr.conf).

Основните конфигурационни параметри, необходими в конфигурационния файл repmgr, са както следва:

node_id (int) – Уникално цяло число, по-голямо от нула, което идентифицира възела.node_name (низ) – Препоръчва се произволен (но уникален) низ, използващ името на хоста на сървъра или друг идентификатор, недвусмислено свързан със сървъра, за да се избегне объркване.

conninfo (низ) – Информация за свързване към базата данни като conninfo низ. Всички сървъри в клъстера трябва да могат да се свързват с локалния възел, използвайки този низ.

директория_данни (низ) – Директорията с данни на възела. Това е необходимо от repmgr за извършване на операции, когато екземплярът на PostgreSQL не се изпълнява и няма друг начин за определяне на директорията с данни.

repmgr Pros

Repmgr предоставя помощни програми, които помагат за настройка на първични и резервни възли и конфигуриране на репликация.
Не използва никакви допълнителни портове за комуникация. Ако искате да извършите превключване, само тогава ще изисква конфигуриране на SSH без парола.
Предоставя известия чрез извикване на потребителските скриптове за регистрираните събития.
Извършва автоматично преминаване при отказ в случай на неизправност на основния сървър.

repmgr против

repmgr не открива дали режимът на готовност е неправилно конфигуриран с неизвестен или несъществуващ възел в конфигурацията за възстановяване. Възелът ще бъде показан като режим на готовност, дори ако работи, без да се свързва с основния/каскаден възел в режим на готовност.
Не може да извлече състоянието на друг възел от възел, където услугата PostgreSQL не работи. Следователно той не предоставя разпределено решение за управление.
Не се справя с възстановяването на здравето на отделните възли.

Управление на висока наличност в #PostgreSQL – Част II:Инструмент с отворен код repmgr Щракнете, за да туитирате

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

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

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

Sl. Не	Тестов сценарий	Наблюдение
1	Прекратете процеса на PostgreSQL	Сървърът в режим на готовност беше маркиран като неуспешен. Нямаше прекъсване в приложението на писателя. Изисква се ръчна намеса, за да стартира отново процеса на PostgreSQL.
2	Спрете процеса на PostgreSQL	Сървърът в режим на готовност беше маркиран като неуспешен. Нямаше прекъсване в приложението на писателя. Изисква се ръчна намеса, за да стартира отново процеса на PostgreSQL.
3	Рестартирайте сървъра	Сървърът в режим на готовност беше маркиран като неуспешен. След като сървърът се появи след рестартиране, PostgreSQL беше стартиран ръчно и сървърът беше маркиран като работещ. Нямаше прекъсване в приложението на писателя.
4	Спрете процеса на repmgrd	Сървърът в режим на готовност няма да бъде част от автоматизираната ситуация при отказ. Установено е, че услугата PostgreSQL работи. Нямаше прекъсване в приложението на писателя.

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

Sl. Нето	Тестов сценарий	Наблюдение
1	Прекратете процеса на PostgreSQL	repmgrd стартира проверката на състоянието на връзката към основния сървър на всички сървъри в режим на готовност за фиксиран интервал. Когато всички повторни опити бяха неуспешни, изборът се задейства на всички сървъри в режим на готовност. В резултат на изборите стендбай, който е получил последния LSN, беше повишен. Сървърите в режим на готовност, които са загубили изборите, ще изчакат известието от нов главен възел и ще го последват, след като получат известието. Имаше престой в приложението за писане. Изисква се ръчна намеса, за да се стартира отново процесът на PostgreSQL.
2	Stop the PostgreSQL process and bring it back immediately after health check expiry	repmgrd started the health check for the primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back. Cluster was left in an indeterminate state and manual intervention was required.
3	Reboot the server	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was ran to add the server back to the cluster. There was downtime in the writer application.
4	Stop the repmgr process	The primary server will not be a part of the automated failover situation. PostgreSQL service was found to be running. There was no disruption in the writer application.

Network Isolation Tests

Sl. No	Test Scenario	Observation
1	Network isolate the primary server from other servers (all have same value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted, but the PostgreSQL process was still running on the old master node. There were two nodes running as master. Manual intervention was required after the network isolation was corrected.
2	Network isolate the primary server from other servers (the standby servers has same value for location but primary had a different value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. But, there was no new master elected since the standby servers had a location different from that of the primary. repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.

Inference

repmgr provides several commands to setup and monitor PostgreSQL replication. It is feature-rich and also eases the job of the database administrator (DBA). However, it’s not a full fledged high availability management tool since it will not manage the resources. Manual intervention is required to ensure the resource is in proper state.

So, in this post, we’ve discussed the capabilities and workings of Replication Manager by 2ndQuadrant. In our next post, we’ll discuss the same high availability aspects using Patroni by Zalando. For users looking to automate their high availability in the cloud, check out our PostgreSQL on Azure and PostgreSQL on AWS fully managed solutions.