PostgreSQL Висока наличност с архитектури Master-Slave и Master-Master

По-долу е даден откъс от нашия бял документ „Управление и автоматизация на PostgreSQL с ClusterControl“, който може да бъде изтеглен безплатно.

Забележка за ревизията: Имайте предвид, че термините, използвани в този блог Master-Slave, са синоними на термините Master-Standby, използвани от PostgreSQL. Използваме Master-Slave, за да запазим паралелизма с други технологии.

За HA конфигурация можем да имаме няколко архитектури, но основните ще бъдат архитектури master-slave и master-master. Сървърите на базата данни могат да работят заедно, за да позволят на втори сървър да поеме бързо, ако основният сървър се повреди (висока наличност ) или да позволите на няколко компютъра да обслужват едни и същи данни (балансиране на натоварването).

PostgreSQL Master-Slave архитектури

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

Репликацията между главния и подчинените може да бъде направена чрез SQL оператори (логически режим на готовност) или чрез модификации на вътрешната структура на данните (физически режим на готовност). PostgreSQL използва поток от записи на дневник с предварителна запис (WAL), за да поддържа синхронизирани бази данни в готовност. Ако основният сървър се повреди, режимът на готовност съдържа почти всички данни на главния сървър и може бързо да бъде превърнат в нов главен сървър на база данни. Това може да бъде синхронно или асинхронно и може да се направи само за целия сървър на база данни.

Настройването на поточно репликация е задача, която изисква щателно следване на някои стъпки. За тези стъпки и още малко информация по тази тема, моля, вижте:Станете PostgreSQL DBA – Как да настроите поточно репликация за висока достъпност.

От версия 10, PostgreSQL включва опцията за настройка на логическа репликация.

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

Можете да намерите повече информация относно логическата репликация:Блог:Преглед на логическата репликация в PostgreSQL.

За ефективно осигуряване на висока наличност не е достатъчно да имате архитектура главен-подчинен. Също така трябва да активираме някаква автоматична форма на отказ, така че ако нещо се провали, можем да имаме възможно най-малко забавяне при възобновяване на нормалната функционалност. PostgreSQL не включва механизъм за автоматично преминаване при отказ за идентифициране на грешки в основната база данни и уведомяване на salve да поеме собствеността, така че това ще изисква малко работа от страна на DBA. Трябва да работите върху скрипт, който включва командата pg_ctl promote, която ще повиши подчинения като нов главен. Има и някои инструменти на трети страни за тази автоматизация. Съществуват много такива инструменти и са добре интегрирани със средствата на операционната система, необходими за успешно преодоляване на отказ, като например миграция на IP адрес.

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

PostgreSQL Master-Master Architectures

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

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

Трябва да сте много внимателни при избора на решение за внедряване на master-master, тъй като има много различни продукти. Много от тях все още са „зелени“, с малко сериозни потребители или успешни случаи. Някои други проекти, от друга страна, са изоставени, тъй като няма активни поддържащи.

За повече информация относно наличните инструменти, моля, вижте:Блог:Топ PG Clustering HA решения за PostgreSQL.

Балансиране на натоварването и пул на връзки

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

Има някои продукти, които се използват и за двете цели, като добре познатия pgpool, и някои други, които ще се фокусират само върху една от тези функции, като pgbouncer (обединяване на връзки) и HAProxy (използва се за балансиране на натоварването).