PostgreSQL Connection Pooling:Част 3 – Pgpool-II

В предишните ни публикации от тази серия обсъдихме случая за обединяване на връзки и представихме PgBouncer. В тази публикация ще обсъдим най-популярната му алтернатива – Pgpool-II.

Pgpool-II е швейцарското армейско ножче на междинния софтуер на PostgreSQL. Той поддържа висока наличност, осигурява автоматизирано балансиране на натоварването и има интелигентността да балансира натоварването между главни и подчинени, така че натоварванията за запис винаги са насочени към главните, докато товарите за четене са насочени към подчинените. Pgpool-II също осигурява логическа репликация. Въпреки че използването и значението му са намаляли с подобряването на вградените опции за репликация от страна на сървъра на PostgreSQL, това все още остава ценна опция за по-старите версии на PostgreSQL. Освен всичко това, той също така осигурява обединяване на връзки!

С един поглед

Настройване на Pgpool-II Следвайте тези стъпки, за да настроите Pgpool-II, да активирате услугите на пула за връзки, от които се нуждаете, и да се свържете с вашия PostgreSQL сървър. Прочетете сега Как работи Вижте архитектурата на Pgpool-II, която поддържа всички нейни функции, и научете как работи пулърът за връзки. Прочетете сега Какво не прави Pgpool-II? Прегледайте ограниченията на Pgpool-II, за да видите дали това е правилният пул за връзка за вашето приложение. Прочетете сега

Настройване на Pgpool-II

Бинарните файлове на Pgpool-II се разпространяват чрез хранилищата на Pgpool-II – можете да прочетете повече за инсталирането в този помощен документ. След като се инсталира, трябва да конфигурираме Pgpool-II, за да активираме услугите, които искаме, и да се свържем със сървъра на PostgreSQL. Можете да прочетете повече за това тук.

За да настроите минимално обединяване, трябва да предоставите следното:

• Потребителското име и криптираната с md5 парола на потребителя(ите), които ще се свържат с Pgpool-II – това трябва да бъде дефинирано в отделен файл, който може лесно да се генерира с помощта на pg_md5.
• Интерфейси/IP-адреси и номер на порт, които да слушате за входящи връзки – това трябва да бъде дефинирано в конфигурационния файл.
• Името на хоста на задния(ите) сървър(и) [Повече от един сървър са посочени само ако желаем да използваме репликация и/или балансиране на натоварването].
• Услугите, които искате да активирате. По подразбиране обединяването на връзки е включено, а другите услуги са изключени в конфигурационния файл, инсталиран с двоичните файлове.

И това е – готови сме! Въпреки че конфигурациите, налични с Pgpool-II, може да са по-обезсърчаващи на пръв поглед, хората зад Pgpool-II наистина ни улесниха!

Как работи

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

Родителският процес на Pgpool-II разклонява 32 дъщерни процеса по подразбиране – те са налични за свързване. Архитектурата е подобна на PostgreSQL сървъра:един процес =една връзка. Той също така разклонява „pcp процес“, който се използва за административни задачи и извън обхвата на тази публикация. 32-те деца вече са готови да приемат връзки. Подобно на PgBouncer, те също емулират PostgreSQL сървър – клиентите могат да се свързват с абсолютно същия низ за връзка, както биха направили с нормален PostgreSQL сървър.

Ядрото насочва входящите връзки към един от дъщерните процеси, които са се регистрирали като слушатели. Нито основният процес на Pgpool-II, нито крайните потребители имат контрол върху това кой дъщерен процес отговаря на входяща заявка. Всяко неактивно дете може да вземе заявката. Ако не бъдат намерени неактивни деца, заявката за свързване ще бъде поставена на опашка от страната на ядрото – това може да доведе до увисване на приложения като pgbench, изчакващи клиентски връзки.

След като неактивно Pgpool-II дете получи заявка за връзка, то:

1. Проверява потребителското име във файла с парола. Ако не бъде намерен, той отхвърля връзката.
2. Ако бъде намерено потребителското име, то проверява предоставената парола спрямо хеша md5, съхранен в този файл.
3. След като удостоверяването е успешно, той проверява дали вече има кеширана връзка за тази комбинация база данни+потребител.
4. Ако е така, връща връзката към клиента. Ако не стане, отваря нова връзка.
5. Всички заявки и отговори преминават през Pgpool-II, докато чака клиентът да прекъсне връзката.
6. След като клиентът прекъсне връзката, Pgpool-II трябва да реши дали да кешира връзката:
   • Ако има празен слот, той го кешира.
   • Ако няма празен слот (тоест, кеширането на тази връзка би надвишило разрешения max_pool_size), той ще вземе решение въз основа на вътрешен алгоритъм.
7. Ако реши да кешира връзката, ще изпълни предварително конфигурираната заявка за нулиране, за да изчисти всички подробности за сесията и да я направи безопасна за повторна употреба от друг клиент.
8. Сега дъщерният процес е свободен да събира повече връзки.

Какво не прави Pgpool-II?

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

Както можете да видите, Pgpool и PgBouncer имат доста различни силни страни – в последната ни публикация от поредицата ще направим директно тестване , и сравнение на функции! Останете на линия!