Миграция на мрежа с нулев престой с MySQL Galera Cluster с помощта на релеен възел

Автоматичното осигуряване на възли на Galera Cluster опростява сложността на мащабиране на клъстер от база данни с гарантирана последователност на данните. SST и IST подобряват използваемостта на първоначалната синхронизация на данни без необходимост от ръчно архивиране на базата данни и копирането й на новия възел. Комбинирайки това със способността на Galera да толерира различни мрежови настройки (напр. WAN репликация), вече можем да мигрираме базата данни между различни изолирани мрежи с нулево прекъсване на услугите.

В тази публикация в блога ще разгледаме как да мигрираме нашия MySQL Galera Cluster без прекъсване. Ще преместим базата данни от Amazon Web Service (AWS) EC2 към Google Cloud Platform (GCP) Compute Engine, с помощта на релеен възел. Имайте предвид, че имахме подобна публикация в блога в миналото, но тази използва различен подход.

Следната диаграма опростява нашия план за миграция:

Подготовка на стария сайт

Тъй като и двата сайта не могат да комуникират помежду си поради група за сигурност или VPC изолация, трябва да имаме релеен възел, който да свързва тези два сайта заедно. Този възел може да се намира на всеки сайт, но трябва да може да се свързва с един или повече възли от другата страна на порт 3306 (MySQL), 4444 (SST), 4567 (gcomm) и 4568 (IST). Ето какво вече имаме и как ще мащабираме стария сайт:

Можете също да използвате съществуващ възел на Galera (например трети възел) като релеен възел, стига да има свързаност с другата страна. Недостатъкът е, че капацитетът на клъстера ще бъде намален до два, тъй като един възел ще се използва за SST и препредаване на репликационния поток на Galera между сайтовете. В зависимост от размера на набора от данни и връзката между сайтовете, това може да доведе до проблеми с надеждността на базата данни в текущия клъстер.

И така, ще използваме четвърти възел, за да намалим риска за текущия производствен клъстер при синхронизиране с другата страна. Първо създайте нов екземпляр в таблото за управление на AWS с публичен IP адрес (за да може да разговаря с външния свят) и разрешите необходимите комуникационни портове на Galera (TCP 3306, 4444, 4567-4568).

Разположете четвъртия възел (релеен възел) на стария сайт. Ако използвате ClusterControl, можете просто да използвате функцията „Добавяне на възел“, за да мащабирате клъстера (не забравяйте предварително да настроите SSH без парола от възел ClusterControl към този четвърти хост):

Уверете се, че релейният възел е в синхрон с текущия клъстер и е в състояние да комуникира с другата страна.

От новия сайт ще се свържем с релейния възел, тъй като това е единственият възел, който има връзка с външния свят.

Ново внедряване на сайт

На новия сайт ще внедрим подобна настройка с един възел ClusterControl и три възела Galera Cluster. И двата сайта трябва да използват една и съща версия на MySQL. Ето нашата архитектура на новия сайт:

С ClusterControl новото внедряване на клъстер е само на няколко щраквания разстояние и е безплатна функция в изданието на общността. Отидете на ClusterControl -> Deploy Database Cluster -> MySQL Galera и следвайте съветника за внедряване:

Щракнете върху Разгръщане и наблюдавайте напредъка под Активност -> Работни места -> Създаване на клъстер. След като сте готови, трябва да имате следното на таблото:

В този момент имате два отделни клъстера Galera – 4 възела на стария сайт и 3 възела в новия сайт.

Свързване на двата сайта

На новия сайт (GCP), изберете един възел за комуникация с релейния възел на стария сайт. Ще изберем galera-gcp1 като конектор към релейния възел (galera-aws4). Следната диаграма илюстрира нашия план за свързване:

Важните неща за конфигуриране са следните параметри:

wsrep_sst_donor :wsrep_node_name на донорния възел. На galera-gcp1 задайте донора на galera-aws4.
wsrep_sst_auth :Потребителските идентификационни данни на SST във формат потребителско име:парола трябва да следват стария сайт (AWS).
wsrep_sst_receive_address :IP адресът, който ще получи SST на съединителния възел. На galera-gcp1 задайте това на публичния IP адрес на този възел.
wsrep_cluster_address :свързващ низ Galera. На galera-gcp1 добавете публичния IP адрес на galera-aws4.
wsrep_provider_options :
- gmcast.segment:По подразбиране е 0. Задайте различно цяло число за всички възли в GCP.

На релейния възел (galera-aws4) извлечете wsrep_node_name:

$ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
Enter password:
+-------------------+
| @@wsrep_node_name |
+-------------------+
| 10.0.0.13         |
+-------------------+

На my.cnf на galera-gcp1 задайте wsrep_sst_donor стойност на wsrep_node_name на релейния възел и wsrep_sst_receive_address към публичния IP адрес на galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
На всички възли в GCP проверете wsrep_sst_auth стойността е идентична след стария сайт (AWS) и променете сегмента на Galera на 1 (така че Galera знае, че и двата сайта са в различни мрежи):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
На galera-gcp1 задайте wsrep_cluster_address за да включите публичния IP адрес на релейния възел:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Променете само wsrep_cluster_address на galera-gcp1. Не променяйте този параметър на galera-gcp2 и galera-gcp3.
Спрете всички възли на GCP. Ако използвате ClusterControl, отидете на падащото меню Cluster Actions -> Stop Cluster. Също така трябва да изключите автоматичното възстановяване както на клъстер, така и на ниво възел, така че ClusterControl няма да се опитва да възстанови неуспешните възли.

Сега частта за синхронизиране. Стартирайте galera-gcp1. Можете да видите от регистъра за грешки на MySQL на донорния възел, че SST се инициира между релейния възел (10.0.0.13) с помощта на публичен адрес на galera-gcp1 (35.197.136.232):

2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
        2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

Обърнете внимание, че в този момент galera-gcp1 ще бъде наводнен със следните редове:

2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

Можете спокойно да игнорирате това предупреждение, тъй като galera-gcp1 продължава да се опитва да види останалите възли извън релейния възел на AWS.

След като SST на galera-gcp1 завърши, ClusterControl на GCE няма да може да свърже възлите на базата данни поради липсващи GRANT (съществуващите GRANT са отменени след синхронизиране от AWS). Ето какво трябва да направим, след като SST завърши на galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
След като това бъде направено, ClusterControl ще докладва правилно състоянието на galera-gcp1, както е подчертано по-долу:
Последната част е да стартирате останалите galera-gcp2 и galera-gcp3, един възел в даден момент. Отидете на ClusterControl -> Nodes -> изберете възела -> Start Node. След като всички възли се синхронизират, трябва да получите 7 като размер на клъстера:

Клъстерът вече работи и на двата сайта и мащабирането е завършено.

Извеждане от експлоатация

След като миграцията приключи и всички възли са синхронизирани, можете да започнете да превключвате приложението си към новия клъстер на GCP:

В този момент MySQL данните се репликират на всички възли до извеждане от експлоатация. Производителността на репликацията ще бъде толкова добра, колкото позволява най-далечният възел в клъстера. Релейният възел е критичен, тъй като излъчва набори за запис към другата страна. От гледна точка на приложението се препоръчва да пишете само на един сайт в даден момент, което означава, че ще трябва да започнете да пренасочвате четене/записване от AWS и вместо това да ги обслужвате от GCP клъстер.

За да изведем от експлоатация старите възли на базата данни и да преминем към клъстера на GCP, трябва да извършим грациозно изключване (един възел в даден момент) на AWS. Важно е да изключите възлите елегантно, тъй като сайтът на AWS притежава по-голямата част от възлите (4/7) за този клъстер. Изключването им наведнъж ще доведе до преминаване на клъстера в GCP в неосновно състояние, принуждавайки клъстера да откаже операция. Уверете се, че последният възел за изключване от страната на AWS е релейният възел.

Не забравяйте да актуализирате съответно следните параметри на galera-gcp1:

wsrep_cluster_address - Премахнете публичния IP адрес на релейния възел.
wsrep_sst_donor - Коментирайте този ред. Нека Galera автоматично избере донора.
wsrep_sst_receive_address - Коментирайте този ред. Нека Galera автоматично избере интерфейса за получаване.

Вашият Galera Cluster вече работи на напълно нова платформа, хостове и мрежа без секунда прекъсване на вашата услуга за база данни по време на миграция. Колко готино е това?