В последните пет публикации от поредицата от блогове разгледахме внедряването на клъстериране/репликация (MySQL / Galera, MySQL Replication, MongoDB &PostgreSQL), управление и наблюдение на съществуващите ви бази данни и клъстери, наблюдение на производителността и здраве, как да направите вашата настройка високодостъпно чрез HAProxy и MaxScale и в последната публикация, как да се подготвите за бедствия, като планирате архивиране.
След ClusterControl 1.2.11 направихме големи подобрения в мениджъра за конфигурация на базата данни. Новата версия позволява промяна на параметрите на множество хостове на база данни едновременно и, ако е възможно, промяна на техните стойности по време на изпълнение.
Представихме новото управление на конфигурацията на MySQL в публикация в блога Съвети и трикове, но тази публикация в блога ще бъде по-задълбочена и ще обхване управлението на конфигурацията в ClusterControl за MySQL, PostgreSQL и MongoDB.
Управление на конфигурацията на ClusterControl
Интерфейсът за управление на конфигурацията може да бъде намерен под Управление> Конфигурации. От тук можете да преглеждате или променяте конфигурациите на вашите възли на базата данни и други инструменти, които ClusterControl управлява. ClusterControl ще импортира най-новата конфигурация от всички възли и ще презапише предишните направени копия. Понастоящем не се съхраняват исторически данни.
Ако предпочитате да редактирате ръчно конфигурационните файлове директно на възлите, можете да импортирате отново променената конфигурация, като натиснете бутона Импортиране.
И не на последно място:можете да създавате или редактирате шаблони за конфигурация. Тези шаблони се използват винаги, когато разгръщате нови възли във вашия клъстер. Разбира се, промените, направени в шаблоните, няма да се прилагат със задна дата към вече разгърнатите възли, създадени с помощта на тези шаблони.
Управление на конфигурацията на MySQL
Както беше споменато по-горе, управлението на конфигурацията на MySQL получи пълна промяна в ClusterControl 1.2.11. Интерфейсът вече е по-интуитивен. При промяна на параметрите ClusterControl проверява дали параметърът действително съществува. Това гарантира, че конфигурацията ви няма да откаже стартирането на MySQL поради несъществуващи параметри.
От Управление -> Конфигурации ще намерите общ преглед на всички конфигурационни файлове, използвани в избрания клъстер, включително възлите за балансиране на натоварването.
Използваме дървовидна структура, за да преглеждаме лесно хостовете и съответните им конфигурационни файлове. В долната част на дървото ще намерите наличните шаблони за конфигурация за този клъстер.
Промяна на параметри
Да предположим, че трябва да променим прост параметър като максималния брой разрешени връзки (max_connections), можем просто да променим този параметър по време на изпълнение.
Първо изберете хостовете, към които да приложите тази промяна.
След това изберете секцията, която искате да промените. В повечето случаи ще искате да промените раздела MYSQLD. Ако искате да промените набора от символи по подразбиране за MySQL, ще трябва да го промените както в MYSQLD, така и в клиентските секции.
Ако е необходимо, можете също да създадете нова секция, като просто въведете името на новата секция. Това ще създаде нов раздел в my.cnf.
След като променим параметър и зададем новата му стойност чрез натискане на „Продължи“, ClusterControl ще провери дали параметърът съществува за тази версия на MySQL. Това е с цел предотвратяване на несъществуващи параметри да блокират инициализацията на MySQL при следващото рестартиране.
Когато натиснем „продължи“ за промяната на max_connections, ще получим потвърждение, че тя е приложена към конфигурацията и зададена по време на изпълнение с помощта на SET GLOBAL. Не се изисква рестартиране, тъй като max_connections е параметър, който можем да променим по време на изпълнение.
Сега да предположим, че искаме да променим размера на буферния пул, това ще изисква рестартиране на MySQL, преди да влезе в сила:
И както се очаква, стойността е променена в конфигурационния файл, но е необходимо рестартиране. Можете да направите това, като влезете ръчно в хоста и рестартирате процеса на MySQL. Друг начин да направите това от ClusterControl е да използвате таблото за управление на възлите.
Рестартиране на възли в клъстер Galera
Можете да извършите рестартиране на възел, като изберете „Рестартиране на възел“ и натиснете бутона „Напред“.
Когато изберете „Първоначално стартиране“ на възел на Galera, ClusterControl ще изпразни директорията с данни на MySQL и ще принуди пълно копие по този начин. Това очевидно не е необходимо за промяна на конфигурацията. Уверете се, че сте оставили квадратчето за отметка „първоначално“ без отметка в диалоговия прозорец за потвърждение. Това ще спре и ще стартира MySQL на хоста, но в зависимост от вашето работно натоварване и размера на буферния пул, това може да отнеме известно време, тъй като MySQL ще започне да промива мръсните страници от буферния пул на InnoDB на диск. Това са страниците, които са променени в паметта, но не и на диска.
Рестартиране на възли в топологиите на MySQL Master-Slave
За топологиите на MySQL master-slave не можете просто да рестартирате възел по възел. Освен ако времето за престой на главния е приемливо, първо ще трябва да приложите промените в конфигурацията към подчинените и след това да повишите подчинен да стане нов главен.
Можете да преминете през подчинените един по един и да изпълните „Restart Node“ върху тях.
След като приложите промените към всички подчинени, повишете подчинен да стане нов главен:
След като подчинението стане новият главен, можете да изключите и рестартирате стария главен възел, за да приложите промяната.
Импортиране на конфигурации
След като сме приложили промяната директно върху базата данни, както и в конфигурационния файл, ще отнеме до следващото импортиране на конфигурация, за да видим промяната, отразена в конфигурацията, съхранена в ClusterControl. Ако сте по-малко търпеливи, можете да планирате незабавно импортиране на конфигурация, като натиснете бутона „Импортиране“.
Управление на конфигурацията на PostgreSQL
За PostgreSQL управлението на конфигурацията работи малко по-различно от управлението на конфигурацията на MySQL. Като цяло тук имате същата функционалност:промяна на конфигурацията, импортиране на конфигурации за всички възли и дефиниране/промяна на шаблони.
Разликата тук е, че можете незабавно да промените целия конфигурационен файл и да запишете тази конфигурация обратно в възела на базата данни.
Ако направените промени изискват рестартиране, ще се появи бутон „Рестартиране“, който ви позволява да рестартирате възела, за да приложите промените.
Управление на конфигурацията на MongoDB
Управлението на конфигурацията на MongoDB работи подобно на управлението на конфигурацията на MySQL:можете да променяте конфигурацията, да импортирате конфигурации за всички възли, да променяте параметрите и да променяте шаблони.
Промяната на конфигурацията е доста проста, като се използва диалогов прозорец за промяна на параметри (както е описано в раздела „Промяна на параметри“:
След като бъде променено, можете да видите действието след модификация, предложено от ClusterControl в диалоговия прозорец „Config Change Log“:
След това можете да продължите да рестартирате съответните възли на MongoDB, един по един, за да заредите промените.
Последни мисли
В тази публикация в блога научихме как да управляваме, променяме и шаблонизираме вашите конфигурации в ClusterControl. Промяната на шаблоните може да ви спести много време, когато сте разположили само един възел във вашата топология. Тъй като шаблонът ще се използва за нови възли, това ще ви спести от промяна на всички конфигурации след това. Въпреки това за възли, базирани на MySQL и MongoDB, промяната на конфигурацията на всички възли е станала тривиална поради новия интерфейс за управление на конфигурацията.
Като напомняне, наскоро разгледахме в същата серия разгръщане на клъстериране/репликация (MySQL / Galera, MySQL Replication, MongoDB &PostgreSQL), управление и наблюдение на съществуващите ви бази данни и клъстери, мониторинг на производителността и здраве, как да направите вашата настройка високо достъпно чрез HAProxy и MaxScale и в последната публикация, как да се подготвите за бедствия, като планирате архивиране.
