За разлика от стандартния MySQL сървър и MySQL Cluster, начинът за стартиране на MySQL/MariaDB Galera Cluster е малко по-различен. Galera изисква да стартирате възел в клъстер като референтна точка, преди останалите възли да могат да се присъединят и да образуват клъстера. Този процес е известен като cluster bootstrap. Зареждането е начална стъпка за въвеждане на възел на базата данни като основен компонент, преди другите да го видят като референтна точка за синхронизиране на данни.
Как работи?
Когато Galera стартира с командата bootstrap на възел, този конкретен възел ще достигне първично състояние (проверете стойността на wsrep_cluster_status). Останалите възли просто ще изискват нормална команда за стартиране и те автоматично ще търсят съществуващ първичен компонент (PC) в клъстера и ще се присъединят, за да образуват клъстер. Синхронизирането на данни след това се осъществява чрез инкрементален трансфер на състояние (IST) или прехвърляне на състояние на моментна снимка (SST) между съединителя и донора.
Така че по принцип трябва да стартирате клъстера само ако искате да стартирате нов клъстер или когато никой друг възел в клъстера не е в ПЪРВНО състояние. Трябва да се внимава при избора на действие, което да предприемете, в противен случай може да се окажете с разделени клъстери или загуба на данни.
Следните примерни сценарии илюстрират кога да стартирате клъстер с три възли въз основа на състояние на възел (wsrep_local_state_comment) и състояние на клъстер (wsrep_cluster_status):
Щат на Галера | Bootstrap Flow |
---|---|
| |
| |
| |
| |
| |
|
Как да стартирам Galera Cluster?
3-те доставчици на Galera използват различни команди за стартиране (въз основа на най-новата версия на софтуера). На първия възел изпълнете:
-
MySQL Galera Cluster (Codership):
$ service mysql bootstrap # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line
-
Percona XtraDB Cluster (Percona):
$ service mysql bootstrap-pxc # sysvinit $ systemctl start [email protected] # systemd
-
MariaDB Galera Cluster (MariaDB):
$ service mysql bootstrap # sysvinit $ service mysql start --wsrep-new-cluster # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line
Горната команда е само обвивка и това, което всъщност прави, е да стартира MySQL екземпляр на този възел с gcomm:// като променлива wsrep_cluster_address. Можете също така ръчно да дефинирате променливите в my.cnf и да изпълните стандартната команда за стартиране/рестартиране. Въпреки това, не забравяйте да промените отново wsrep_cluster_address, за да съдържа адресите на всички възли след старта.
Когато първият възел е активен, изпълнете следната команда на следващите възли:
$ service mysql start
$ systemctl start mysql
Новият възел се свързва с членовете на клъстера, както е дефинирано от параметъра wsrep_cluster_address. Сега автоматично ще извлече картата на клъстера и ще се свърже с останалите възли и ще образува клъстер.
Предупреждение:Никога не стартирайте стартиране, когато искате да свържете отново възел към съществуващ клъстер, и НИКОГА не стартирайте bootstrap на повече от един възел.
Флаг за безопасно зареждане
Galera, започваща с версия 3.19, идва с нов флаг, наречен “safe_to_bootstrap” в grastate.dat. Този флаг улеснява вземането на решение и предотвратява опасни избори, като следи реда, в който възлите се изключват. Възелът, който е бил изключен последен, ще бъде маркиран като „Safe-to-Bootstrap“. Всички останали възли ще бъдат маркирани като опасни за стартиране.
Разглеждайки съдържанието на grastate.dat (по подразбиране е под MySQL datadir) и трябва да забележите флага на последния ред:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: 2575
safe_to_bootstrap: 0
Когато стартира новия клъстер, Galera ще откаже да стартира първия възел, който е маркиран като небезопасен за стартиране. Ще видите следното съобщение в регистрационните файлове:
„Може да не е безопасно да стартирате клъстера от този възел. Това не беше последният, който напусна клъстера и може да не съдържа всички актуализации.
За да принудите стартирането на клъстера с този възел, редактирайте файла grastate.dat ръчно и задайте safe_to_bootstrap на 1.”
В случай на нечисто изключване или тежък срив, всички възли ще имат „safe_to_bootstrap:0“, така че трябва да се консултираме с InnoDB машината за съхранение, за да определим кой възел е извършил последната транзакция в клъстера. Това може да се постигне чрез стартиране на mysqld с променливата “--wsrep-recover” на всеки от възлите, което произвежда изход като този:
$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...
Номерът след низа UUID в реда „Възстановена позиция“ е този, който трябва да се търси. Изберете възела, който има най-голям номер и редактирайте неговия grastate.dat, за да зададете „safe_to_bootstrap:1“, както е показано в примера по-долу:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: -1
safe_to_bootstrap: 1
След това можете да изпълните стандартната команда за стартиране на избрания възел.
Ами ако възлите са се разминали?
При определени обстоятелства възлите може да са се отклонили един от друг. Състоянието на всички възли може да се превърне в Non-Primary поради разделяне на мрежата между възли, срив на клъстера или ако Galera удари изключение при определяне на първичния компонент. След това ще трябва да изберете възел и да го повишите като първичен компонент.
За да определите кой възел трябва да бъде стартиран, сравнете стойността wsrep_last_committed на всички DB възли:
node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10032 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+
node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10348 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+
node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 997 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+
От горните изходи, node2 има най-актуалните данни. В този случай всички възли на Galera вече са стартирани, така че не е необходимо да стартирате отново клъстера. Просто трябва да популяризираме node2 да бъде първичен компонент:
node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";
След това останалите възли ще се свържат отново с първичния компонент (възел 2) и повторно синхронизират данните си въз основа на този възел.
Ако използвате ClusterControl (изпробвайте го безплатно), можете да определите wsrep_last_committed и wsrep_cluster_status директно от ClusterControl> Общ преглед страница:Или от ClusterControl> Performance> DB Status страница: