Автоматизирани надстройки на PostgreSQL клъстери в облак с почти нулев престой (част II)

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

Можете да проверите първата част от поредицата тук: Автоматизирани надстройки на PostgreSQL клъстери в облак с почти нулев престой (част I).

Инструментът е написан на Ansible. Имам предишен опит в работата с Ansible и понастоящем работя с него и във 2ndQuadrant и затова това беше удобна опция за мен. Като се има предвид това, можете да приложите минималната логика за надграждане на престой, която ще бъде обяснена по-късно в тази публикация, с любимия си инструмент за автоматизация.

Допълнително четене:Публикации в блога Ansible обича PostgreSQL , PostgreSQL Planet в Ansible Galaxy и  презентация Управление на PostgreSQL с Ansible.

Pglupgrade Playbook

В Ansible,игрови книги са основните скриптове, които са разработени за автоматизиране на процесите като осигуряване на облачни инстанции и надграждане на клъстери от бази данни. Ръководствата може да съдържат една или повече пиеси . Playbooks може също да съдържа променливи ,роли , и обработващи ако е дефинирано.

Инструментът се състои от две основни книги. Първата игра е provision.yml който автоматизира процеса за създаване на Linux машини в облак, в съответствие със спецификациите (Това е незадължителна книга, написана само за предоставяне на облачни инстанции и не е пряко свързана с надстройката ). Втората (и основна) игра е pglupgrade.yml който автоматизира процеса на надстройка на клъстери от бази данни.

Pglupgrade playbook има осем пиеси за организиране на надстройката. Във всяка от възпроизвежданията използвайте един конфигурационен файл (config.yml ), изпълняват някои задачи на хостовете или хост групите, които са дефинирани в файл с инвентаризация на хост (host.ini ).

Файл с инвентаризация

Файлът с инвентаризация позволява на Ansible да знае кои сървъри трябва да се свърже чрез SSH, каква информация за връзка изисква и по избор кои променливи са свързани с тези сървъри. По-долу можете да видите примерен файл с инвентаризация, който е бил използван за изпълнение на автоматизирани надстройки на клъстер за един от казусите, предназначени за инструмента. Ще обсъдим тези казуси в предстоящите публикации от тази серия.

[old-primary]54.171.211.188[new-primary]54.246.183.100[old-standbys]54.77.249.8154.154.49.180[new-standbys:children]old-standbys1.49.5]> 
Файл с инвентара (host.ini ) 
 

 Примерният файл с инвентаризация съдържа петхост под петгрупи домакини които включват old-primary , new-primary , old-standbys , new-standbys и pgbouncer . Сървърът може да принадлежи към повече от една група. Например old-standbys е група, съдържаща new-standbys група, което означава хостовете, които са дефинирани под old-standbys групата (54.77.249.81 и 54.154.49.180) също принадлежи към new-standbys група. С други думи, new-standbys групата е наследена от (деца на) old-standbys група. Това се постига с помощта на специалния :children суфикс.
 

 След като файлът с инвентара е готов, Ansible playbook може да работи чрез ansible-playbook команда, като посочите файла с инвентара (ако файлът с инвентара не се намира на местоположение по подразбиране, в противен случай ще използва файла за инвентаризация по подразбиране), както е показано по-долу:
 
$ ansible-playbook -i hosts.ini pglupgrade.yml
 
Изпълнение на Ansible playbook 
 
Конфигурационен файл
 

 Pglupgrade playbook използва конфигурационен файл (config.yml ), който позволява на потребителите да определят стойности за променливите за логическо надграждане.
 

 Както е показано по-долу, config.yml съхранява предимно специфични за PostgreSQL променливи, които са необходими за настройка на PostgreSQL клъстер, като postgres_old_datadir и postgres_new_datadir за съхраняване на пътя на директорията с данни на PostgreSQL за старата и новата версия на PostgreSQL; postgres_new_confdir за съхраняване на пътя на конфигурационната директория на PostgreSQL за новата версия на PostgreSQL; postgres_old_dsn и postgres_new_dsn за да съхраните низа за връзка за pglupgrade_user за да можете да се свържете с pglupgrade_database на новите и стари първични сървъри. Самият низ за връзка се състои от конфигурируемите променливи, така че потребителят (pglupgrade_user ) и базата данни (pglupgrade_database ) информацията може да се променя за различните случаи на употреба.
 
ansible_user:adminpglupgrade_user:pglupgradepglupgrade_pass:pglupgrade123pglupgrade_database:postgresreplica_user:postgresreplica_pass:""pgbouncer_user:pgbouncerpostgres_old_version:9.5postgres_new_version:9.6subscription_name:upgradereplication_set:upgradeinitial_standbys:1postgres_old_dsn:"dbname={{pglupgrade_database}} host={{groups['old- първичен'][0]}} потребител {{pglupgrade_user}}"postgres_new_dsn:"dbname={{pglupgrade_database}} host={{groups['new-primary'][0]}} user={{pglupgrade_user}}" postgres_old_datadir:"/var/lib/postgresql/{{postgres_old_version}}/main" postgres_new_datadir:"/var/lib/postgresql/{{postgres_new_version}}/main"postgres_new_confdir:"/etc/postgres/postgres{1} главен"
 
Конфигурационен файл (config.yml ) 
 

 Като ключова стъпка за всяка надстройка може да се посочи информацията за версията на PostgreSQL за текущата версия (postgres_old_version ) и версията, която ще бъде надстроена до (postgres_new_version ). За разлика от физическата репликация, където репликацията е копие на системата на ниво байт/блок, логическата репликация позволява селективна репликация където репликацията може да копира логическите данни, включва определени бази данни и таблиците в тези бази данни. Поради тази причина config.yml позволява да се конфигурира коя база данни да се репликира чрез pglupgrade_database променлива. Освен това потребителят на логическа репликация трябва да има привилегии за репликация, поради което pglupgrade_user променливата трябва да бъде посочена в конфигурационния файл. Има и други променливи, които са свързани с работещите вътрешни елементи на pglogical, като например subscription_name и replication_set които се използват в pglogical роля.
 
Дизайн с висока достъпност на инструмента Pglupgrade
 

 Инструментът Pglupgrade е предназначен да даде гъвкавост по отношение на свойствата за висока достъпност (HA) на потребителя за различните системни изисквания. initial_standbys променлива (вижте config.yml ) е ключът за определяне на HA свойства на клъстера, докато се извършва операцията по надграждане.
 

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

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

 Когато initial_standbys променливата е настроена на 0, няма да бъдат създадени първоначални сървъри в режим на готовност в новия клъстер преди да започне репликацията.
 
Ако initial_standbys конфигурацията звучи объркващо, не се притеснявайте. Това ще бъде обяснено по-добре в следващата публикация в блога, когато обсъждаме два различни казуса. 
 

 И накрая, конфигурационният файл позволява посочване на стари и нови групи сървъри. Това може да бъде осигурено по два начина. Първо, ако има съществуващ клъстер, IP адресите на сървърите (могат да бъдат или голи или виртуални сървъри ) трябва да се въведе в hosts.ini файл, като вземете предвид желаните свойства на HA по време на операцията за надграждане.
 

 Вторият начин е да стартирате provision.yml учебник (така предоставих екземпляри в облака, но можете да използвате свои собствени скриптове за осигуряване или ръчно предоставяне на екземпляри ) за предоставяне на празни Linux сървъри в облак (екземпляри на AWS EC2) и получаване на IP адресите на сървърите в hosts.ini файл. Така или иначе, config.yml ще получи информация за хост чрез hosts.ini файл.
 
Работен процес на процеса на надстройка
 

 След обяснение на конфигурационния файл (config.yml ), който се използва от pglupgrade playbook, можем да обясним работния процес на процеса на надстройка.
 

 
 
Pglupgrade Workflow 
 

 Както се вижда от диаграмата по-горе, има шест групи сървъри, които се генерират в началото въз основа на конфигурацията (и двете hosts.ini и config.yml ). new-primary и old-primary групите винаги ще имат един сървър, pgbouncer групата може да има един или повече сървъри и всички групи в режим на готовност могат да имат нула или повече сървъри в тях. По отношение на прилагането, целият процес е разделен на осем стъпки. Всяка стъпка съответства на игра в pglupgrade playbook, която изпълнява необходимите задачи на назначените хост групи. Процесът на надграждане е обяснен чрез следните игри:
 
 
Изграждане на хостове въз основа на конфигурация: Подготвителна игра, която изгражда вътрешни групи сървъри въз основа на конфигурацията. Резултатът от тази игра (в комбинация с hosts.ini съдържание) са шестте групи сървъри (илюстрирани с различни цветове в диаграмата на работния процес), които ще се използват от следващите седем пиеси.
 
Настройте нов клъстер с първоначален(и) режим(и): Създава празен PostgreSQL клъстер с новите първични и първоначални режими на готовност (ако има дефинирани). Той гарантира, че няма останали от инсталациите на PostgreSQL от предишната употреба.
 
Променете стария първичен, за да поддържа логическа репликация: Инсталира pglogical разширение. След това задава издателя, като добавя всички таблици и последователности към репликацията.
 
Репликиране на новия основен: Настройва абоната на новия главен обект, който действа като тригер за стартиране на логическа репликация. Тази игра завършва репликирането на съществуващите данни и започва да наваксва какво се е променило от началото на репликацията.
 
Превключете pgbouncer (и приложения) към нов основен: Когато забавянето на репликацията се сближи до нула, поставя pgbouncer на пауза, за да превключи приложението постепенно. След това насочва конфигурацията на pgbouncer към новия първичен и изчаква, докато разликата в репликацията стане нула. Накрая pgbouncer се възобновява и всички чакащи транзакции се разпространяват към новия първичен и започват да обработват там. Първоначалният режим на готовност вече се използва и отговаря на заявки за четене.
 
Почистете настройката за репликация между старото основно и новото основно: Прекратява връзката между стария и новия първичен сървър. Тъй като всички приложения са преместени на новия основен сървър и надстройката е извършена, логическата репликация вече не е необходима. Репликацията между основния и резервния сървър продължава с физическа репликация.
 
Спрете стария клъстер: Услугата Postgres е спряна в стари хостове, за да се гарантира, че никое приложение вече не може да се свърже с нея.
 
Преконфигурирайте останалата част от режимите на готовност за новия първичен: Възстановява други режими на готовност, ако има други хостове, различни от първоначалните режими на готовност. Във втория казус няма останали резервни сървъри за възстановяване. Тази стъпка дава възможност за възстановяване на стария първичен сървър като нов режим на готовност, ако е посочен в групата new-standbys на hosts.ini. Повторната употреба на съществуващите сървъри (дори и на стария първичен) се постига чрез използване на двуетапния дизайн на конфигурация в режим на готовност на инструмента pglupgrade. Потребителят може да посочи кои сървъри трябва да станат резервни на новия клъстер преди надстройката и кои да станат резервни след надстройката.
 
 
Заключение
 

 В тази публикация обсъдихме подробностите за внедряването и дизайна с висока достъпност на инструмента pglupgrade. Правейки това, ние също споменахме няколко ключови концепции за разработката на Ansible (т.е. playbook, инвентар и конфигурационни файлове), използвайки инструмента като пример. Илюстрирахме работния процес на процеса на надграждане и обобщихме как работи всяка стъпка със съответната игра. Ще продължим да обясняваме pglupgrade, като показваме казуси в предстоящи публикации от тази поредица.
 

 Благодаря за четенето!