PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

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

В предишните ни публикации в блога обсъдихме възможностите и функционирането на PostgreSQL Automatic Failover (PAF) от Cluster Labs и Replication Manager (repmgr) от 2ndQuadrant. В последната публикация от тази серия ще прегледаме последното решение, Patroni от Zalando, и ще сравним и трите в края, за да можете да определите коя рамка за висока достъпност е най-добра за внедряването на хостинг на PostgreSQL.

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

Patroni за PostgreSQL

Patroni възниква като разклонение на Governor, проект от Compose. Това е пакет от инструменти с отворен код, написан на Python, за управление на висока наличност на PostgreSQL клъстери. Вместо да изгражда свой собствен протокол за последователност, Patroni интелигентно използва модела на последователност, предоставен от магазин за разпределена конфигурация (DCS). Той също така поддържа други DCS решения като Zookeeper, etcd, Consul и Kubernetes.

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

Този богат на функции инструмент излага своята функционалност чрез REST API, а също и чрез помощна програма на командния ред, наречена patronictl. Той поддържа интеграция с HAProxy, като използва своите приложни програмни интерфейси за проверка на състоянието за справяне с балансирането на натоварването.

Patroni също поддържа известяване за събития с помощта на обратни извиквания, които са скриптове, задействани от определени действия. Той позволява на потребителите да извършват всякакви действия за поддръжка, като предоставят функционалност за пауза/възобновяване. Функцията за поддръжка на Watchdog прави рамката още по-стабилна.

Как работи

Първоначално трябва да бъдат инсталирани двоични файлове на PostgreSQL и Patroni. След като това е направено, вие също ще трябва да настроите HA DCS конфигурация. Всички необходими конфигурации за стартиране на клъстера трябва да бъдат посочени в конфигурационния файл на yaml и Patroni ще използва този файл за инициализация. На първия възел Patroni инициализира базата данни, получава водещото заключване от DCS и гарантира, че възелът се изпълнява като главен.

Следващата стъпка е добавяне на резервни възли, за които Patroni предоставя множество опции. По подразбиране Patroni използва pg_basebackup за създаване на възел в режим на готовност и също така поддържа персонализирани методи като WAL-E, pgBackRest, Barman и други за създаване на възел в режим на готовност. Patroni прави много лесно добавянето на възел в режим на готовност и се справя с всички задачи за стартиране и настройка на вашата стрийминг репликация.

Управление на високата наличност в #PostgreSQL – Част III:Patroni срещу PAF срещу repmgr Кликнете, за да Tweet

След като настройката на клъстера ви приключи, Patroni ще наблюдава активно клъстера и ще гарантира, че е в изправно състояние. Главният възел подновява заключването на лидера на всеки ttl секунда(и) (по подразбиране:30 секунди). Когато главният възел не успее да поднови водещото заключване, Patroni задейства избор и възелът, който ще получи водещото заключване, ще бъде избран за нов главен.

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

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

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

  • Patroni се нуждае от python 2.7 и по-нова версия.
  • DCS и неговият специфичен Python модул трябва да бъдат инсталирани. За целите на теста DCS може да бъде инсталиран на същите възли, работещи с PostgreSQL. Въпреки това, в производството, DCS трябва да бъде инсталиран на отделни възли.
  • Конфигурационният файл на yaml трябва да присъства с помощта на следните настройки за конфигурация от високо ниво:

    Глобален/универсален
    Това включва конфигурация като името на хоста (име), което трябва да бъде уникално за клъстера, името на клъстера (обхват) и пътя за съхранение на конфигурацията в DCS (пространство от имена).

    Регистър
    Специфични за Patroni настройки за регистрационни файлове, включително ниво, формат, номер_файл, размер_на_файл и т.н.

    Конфигурация на Bootstrap
    Това е глобалната конфигурация за клъстер, който ще бъде записан в DCS. Тези конфигурационни параметри могат да бъдат променени с помощта на API на Patroni или директно в DCS. Конфигурацията за стартиране включва методи за създаване в режим на готовност, параметри на initdb, скрипт след инициализация и т.н. Също така съдържа конфигурация за изчакване, параметри за решаване на използването на функциите на PostgreSQL като слотове за репликация , синхронен режим и т.н. Тази секция ще бъде записана в ///config на дадено хранилище за конфигурации след инициализиране на нов клъстер.

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

    API REST
    Този раздел включва специфичната за Patroni конфигурация, свързана с REST API, като адрес за слушане, удостоверяване, SSL и др.

    Консул
    Настройки, специфични за Consul DCS.

    Etcd
    Настройки, специфични за Etcd DCS.

    Изложител
    Настройки, специфични за DCS на изложителя.

    Kubernetes
    Настройки, специфични за Kubernetes DCS.

    ZooKeeper
    Настройки, специфични за ZooKeeper DCS.

    Наблюдател
    Настройки, специфични за Watchdog.

Професионалисти на Patroni

  • Patroni позволява цялостна настройка на клъстера.
  • Поддържа REST API и HAproxy интеграция.
  • Поддържа известия за събития чрез скриптове за обратно извикване, задействани от определени действия.
  • Използва DCS за консенсус.

Против Patroni

  • Patroni няма да открие неправилна конфигурация на режим на готовност с неизвестен или несъществуващ възел в конфигурацията за възстановяване. Възелът ще бъде показан като подчинен, дори ако режимът на готовност работи, без да се свързва с главния/каскадния възел в режим на готовност.
  • Потребителят трябва да се справи с настройката, управлението и надграждането на софтуера на DCS.
  • Изисква множество портове да бъдат отворени за комуникация на компоненти:
    • REST API порт за Patroni
    • Минимум 2 порта за DCS

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

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

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

Sl. Не Тестов сценарий Наблюдение
1 Прекратете процеса на PostgreSQL Patroni върна процеса на PostgreSQL в състояние на работа.

  • Нямаше прекъсване на приложението за записване.
2 Спрете процеса на PostgreSQL Patroni върна процеса на PostgreSQL в състояние на работа.

  • Нямаше прекъсване на приложението за записване.
3 Рестартирайте сървъра Patroni трябва да се стартира след рестартиране, освен ако не е конфигуриран да не стартира при рестартиране. След като Patroni беше стартиран, той стартира процеса на PostgreSQL и настрои конфигурацията в режим на готовност.

  • Нямаше прекъсване на приложението за записване.
4 Спрете процеса на Patroni
  • Това не спря процеса на PostgreSQL.
  • списък на патроните не показа този сървър.
  • Нямаше прекъсване на приложението за записване.

Така че по същество трябва да наблюдавате здравето на процеса на Patroni – в противен случай това ще доведе до проблеми в бъдеще.

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

Sl. Нето Тестов сценарий Наблюдение
1 Прекратете процеса на PostgreSQL Patroni върна процеса на PostgreSQL в състояние на работа. Patroni, работещ на този възел, имаше първично заключване и така изборът не беше задействан.

  • Имаше престой в приложението за записване.
2 Спрете процеса на PostgreSQL и го върнете обратно веднага след изтичане на проверката на здравето Patroni върна процеса на PostgreSQL в състояние на работа. Patroni, работещ на този възел, имаше първично заключване и така изборът не беше задействан.

  • Имаше престой в приложението за записване.
3 Рестартирайте сървъра Случи се отказ и един от резервните сървъри беше избран за нов главен след получаване на заключването. Когато Patroni беше стартиран на стария мастер, той върна стария мастер и изпълни pg_rewind и започна да следва новия мастер.T

  • Имаше престой в приложението за записване.
4 Спрете/убийте процеса на Patroni
  • Един от сървърите в режим на готовност придоби DCS заключването и стана главен, като се промотира.
  • Старият майстор все още работеше и това доведе до сценарий с няколко главни. Приложението все още пишеше на стария господар.
  • След като Patroni беше стартиран на стария мастер, той пренави стария мастер (use_pg_rewind беше зададено на true) към новата главна времева линия и lsn и започна да следва новия главен.

Както можете да видите по-горе, много е важно да наблюдавате здравето на процеса на Patroni на капитана. Неспазването на това може да доведе до сценарий с няколко главни и потенциална загуба на данни.

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

Sl. Нето Тестов сценарий Наблюдение
1 Мрежова изолиране на главния сървър от други сървъри DCS комуникацията беше блокирана за главния възел.

  • PostgreSQL беше понижен на главния сървър.
  • Нов господар беше избран в мажоритарния дял.
  • Имаше прекъсване в приложението за запис.
2 Мрежова изолиране на сървъра в режим на готовност от други сървъри DCS комуникацията беше блокирана за възела в режим на готовност.

  • Услугата PostgreSQL работеше, но възелът не беше взет предвид за избори.
  • Нямаше прекъсване в приложението за записване.

Коя е най-добрата PostgreSQL HA Framework?

Patroni е ценен инструмент за администратори на база данни на PostgreSQL (DBA), тъй като извършва цялостна настройка и наблюдение на PostgreSQL клъстер. Гъвкавостта при избора на DCS и създаването в режим на готовност е предимство за крайния потребител, тъй като те могат да изберат метода, който им е удобен.

Приложни програмни интерфейси за REST, интеграция на HaProxy, поддръжка на Watchdog, обратни извиквания и неговото богато на функции управление правят Patroni най-доброто решение за управление на PostgreSQL HA.

Тестване на PostgreSQL HA Framework:PAF срещу repmgr срещу Patroni

По-долу е включена изчерпателна таблица с подробности за резултатите от всички тестове, които сме изпълнили и на трите рамки – PostgreSQL Automatic Failover (PAF), Мениджър на репликация (repmgr) и Patroni.

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

Тестов сценарий Автоматично отказване на PostgreSQL (PAF) Мениджър на репликация (repmgr) Патрони
Прекратете процеса на PostgreSQL Пейсмейкърът върна процеса на PostgreSQL в състояние на работа.

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

  • Нямаше прекъсване на приложението за записване.
 Patroni върна процеса на PostgreSQL обратно в работещо състояние.

  • Нямаше прекъсване на приложението за записване.
Спрете процеса на PostgreSQL Пейсмейкърът върна процеса на PostgreSQL в състояние на работа.

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

  • Нямаше прекъсване на приложението за записване.
 Patroni върна процеса на PostgreSQL обратно в работещо състояние.

  • Нямаше прекъсване на приложението за записване.
Рестартирайте сървъра Сървърът в режим на готовност първоначално беше маркиран офлайн. След като сървърът се появи след рестартиране, PostgreSQL беше стартиран от Pacemaker и сървърът беше маркиран като онлайн. Ако ограждането беше активирано, възелът нямаше да бъде добавен автоматично към клъстера.

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

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

  • Нямаше прекъсване на приложението за записване.
Спиране на процеса на рамков агент Agent:pacemaker

  • The PostgreSQL process was stopped and was marked offline.
  • There was no disruption of the writer application.
 Agent:repmgrd

  • The standby server will not be part of automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption of the writer application.
 Agent:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

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

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the 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.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. The most eligible standby server was promoted as the new master. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started 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 run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Network Isolation Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started 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.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had 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.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. connection.select_value връща само низове в postgres с pg gem

  2. Връщане на Unix Timestamp в PostgreSQL

  3. Postgres грешка при вмъкване - ГРЕШКА:невалидна последователност от байтове за кодиране UTF8:0x00

  4. Как да свържете две таблици в поле за външен ключ, използвайки django ORM?

  5. Postgres НЕ е в масива