Улесняване на управлението на производствена PostgreSQL база данни

През последните няколко години се наблюдава нарастващо приемане на PostgreSQL. PostgreSQL е невероятна релационна база данни. По отношение на функциите, той е там с най-доброто, ако не и с най-доброто. Има много неща, които харесвам в него – PL/PG SQL, интелигентни настройки по подразбиране, репликация (която всъщност работи извън кутията) и активна и жизнена общност с отворен код. Въпреки това, освен функциите, има и други важни аспекти на базата данни, които трябва да бъдат взети предвид. Ако планирате да изградите голяма 24/7 операция, възможността за лесно опериране с базата данни, след като тя е в производство, става много важен фактор. В този аспект PostgreSQL не се държи много добре. В тази публикация в блога ще опишем подробно някои от тези оперативни предизвикателства с PostgreSQL. Тук няма нищо фундаментално непоправимо, просто въпрос на приоритизиране. Надяваме се, че можем да предизвикаме достатъчно интерес в общността с отворен код, за да дадем приоритет на тези функции.

1. Няма автоматично откриване на клиентски драйвер за главен отказ

Клиентският драйвер на PostgreSQL не открива автоматично кога е имало главен отказ (и е избран нов главен). За да заобиколят това, администраторите трябва да разположат прокси слой от страна на сървъра. Популярният избор са DNS картографиране, виртуално IP картографиране, PgPool и HAProxy. Всички тези опции могат да бъдат накарани да работят добре, но са необходими значително допълнително обучение и усилия на администратора. В случая, когато в пътя на данните е въведен прокси, има и значително въздействие върху производителността. Това е стандартна вградена функция в много от новите бази данни NoSQL и PostgreSQL би бил чудесен, за да извади лист от техните книги, когато става въпрос за операции.

2. Няма вградено автоматично превключване при отказ между главен и режим на готовност

Когато главен PostgreSQL се повреди, един от резервните сървъри трябва да бъде избран за главен. Този механизъм не е вграден в PostgreSQL. Обикновено софтуерни инструменти на трети страни като Patroni, Pacemaker и др. се използват за справяне с този сценарий. Защо това не е вградено в сървъра? Тези инструменти на трети страни изглеждат измамно прости, но изискват значителни усилия, знания и тестване от страна на администратора, за да се оправи. Вграждайки това в базата данни, вие правите огромна услуга на администратора на базата данни.

3. Без основно надграждане с нулев престой

Не е възможно да надстроите вашата база данни PostgreSQL от една основна версия до друга без прекъсване. По същество трябва да изключите всичките си сървъри и да използвате pg_upgrade, за да надстроите данните си до по-нова версия. Времето на престой не е голямо, тъй като няма включено копие на данни, но все още има престой. Ако работите 24/7, това може да не е опция за вас.

С пускането на логическа репликация имаме алтернативна опция за онлайн надстройка.

1. Създайте чисто нова настройка на PostgreSQL Master-Standby с новата версия.
2. Настройте логическа репликация за репликация от по-стара версия към по-нова версия.
3. След като сте готови, променете низа си за връзка, така че да сочи от по-старата настройка към новата настройка.

Отново, това може да се накара да работи, но режийните разходи са огромни. В идеалния случай това, което е необходимо тук, е начин за надграждане на място по подвижен начин спрямо основна настройка в режим на готовност. Надстройката на MySQL ви позволява да надстроите вашите подчинени на място до новата версия и след това да задействате отказ.

4. Няма VACUUM FULL на място

Autovacuum/VACUUM е много полезен и помага за справяне с този проблем до известна степен. Трябва редовно да проверявате подуването на масите си, за да се уверите, че настройките ви за автоматично вакуумиране са подходящи и работят добре за вашата маса. Автоматично вакуумиране обаче не върви докрай – всъщност не се стига до сливане и изтриване на страниците. Ако имате голям брой актуализации, вмъкване и изтриване на работни натоварвания, страниците ви ще бъдат фрагментирани, което ще се отрази на производителността ви. Единственият начин да заобиколите това е да стартирате VACUUM FULL, което основно ще възстанови всички страници, за да елиминира фрагментацията. Този процес обаче може да се осъществи само с престой – масата ви не работи за времето, когато VACUUM FULL. За големи набори от данни това може да отнеме няколко часа и не е практична алтернатива, ако искате да изпълнявате 24/7 операция.

Забележка:Общността вече е започнала работа по механизма за съхранение zheap, който преодолява това ограничение.

Ако има други подобрения, които смятате, че биха били полезни, не се колебайте да оставите коментар.