С MySQL 8.0 Oracle възприе нов подход към разработката. Вместо да прокарват функции с основните версии, почти всяка второстепенна версия на MySQL 8.0 идва с нови функции или подобрения. Една от тези нови функции е това, върху което бихме искали да се съсредоточим в тази публикация в блога.
Исторически MySQL не идваше с добри инструменти за обезпечаване. Разбира се, имахте mysqldump, но това е просто инструмент за логично архивиране, който не е подходящ за по-големи среди. Корпоративните потребители на MySQL могат да се възползват от MySQL Enterprise Backup, докато потребителите в общността могат да използват xtrabackup. Нито едно от тях обаче не дойде с чисти разгръщания на MySQL Community. Беше доста досадно, тъй като осигуряването е задача, която вършите доста често. Може да се наложи да изградите нов подчинен, да възстановите неуспешен – всичко това ще изисква някакъв вид трансфер на данни между отделни възли.
MySQL 8.0.17 въведе нов начин за предоставяне на MySQL данни - плъгин за клониране. Имаше предвид MySQL Group Replication, за да въведе начин за автоматично осигуряване и възстановяване на неуспешни възли, но неговата полезност не се ограничава до тази област. Можем да го използваме и за възстановяване на подчинен възел или за осигуряване на нов сървър. В тази публикация в блога бихме искали да ви покажем как да настроите MySQL Clone плъгин и как да изградите отново роб за репликация.
Първо, плъгинът трябва да бъде активиран, тъй като е деактивиран по подразбиране. След като направите това, той ще остане активиран чрез рестартиране. В идеалния случай ще го направите на всички възли в топологията на репликация.
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
Query OK, 0 rows affected (0.00 sec)Плъгинът за клониране изисква потребител на MySQL с подходящи привилегии. На донор трябва да има привилегия „BACKUP_ADMIN“, докато на присъединителя трябва да има привилегия „CLONE_ADMIN“. Ако приемем, че искате да използвате широко приставката за клониране, можете просто да създадете потребител с двете привилегии. Направете го на главния, така че потребителят ще бъде създаден и на всички подчинени. В крайна сметка никога не знаете кой възел ще бъде главен в бъдеще, затова е по-удобно всичко да е подготвено предварително.
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'clonepass';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT BACKUP_ADMIN, CLONE_ADMIN ON *.* to [email protected]'%';
Query OK, 0 rows affected (0.00 sec)Плъгинът MySQL Clone има някои предпоставки, така че трябва да се извършат проверки за здравина. Трябва да се уверите, че и donor, и joiner ще имат еднакви стойности в следните конфигурационни променливи:
mysql> SHOW VARIABLES LIKE 'innodb_page_size';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.01 sec)
mysql> SHOW VARIABLES LIKE 'innodb_data_file_path';
+-----------------------+-------------------------+
| Variable_name | Value |
+-----------------------+-------------------------+
| innodb_data_file_path | ibdata1:100M:autoextend |
+-----------------------+-------------------------+
1 row in set (0.01 sec)
mysql> SHOW VARIABLES LIKE 'max_allowed_packet';
+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| max_allowed_packet | 536870912 |
+--------------------+-----------+
1 row in set (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE '%character%';
+--------------------------+--------------------------------+
| Variable_name | Value |
+--------------------------+--------------------------------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | utf8mb4 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+
8 rows in set (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE '%collation%';
+-------------------------------+--------------------+
| Variable_name | Value |
+-------------------------------+--------------------+
| collation_connection | utf8mb4_0900_ai_ci |
| collation_database | utf8mb4_0900_ai_ci |
| collation_server | utf8mb4_0900_ai_ci |
| default_collation_for_utf8mb4 | utf8mb4_0900_ai_ci |
+-------------------------------+--------------------+
4 rows in set (0.00 sec)След това, на главния, трябва да проверим отново дали пространствата за отмяна на таблици имат уникални имена:
mysql> SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES
-> WHERE FILE_TYPE LIKE 'UNDO LOG';
+-----------------+------------+
| TABLESPACE_NAME | FILE_NAME |
+-----------------+------------+
| innodb_undo_001 | ./undo_001 |
| innodb_undo_002 | ./undo_002 |
+-----------------+------------+
2 rows in set (0.12 sec)Нивото на подробност по подразбиране не показва твърде много данни относно процеса на клониране, затова бихме препоръчали да го увеличите, за да имате по-добра представа за случващото се:
mysql> SET GLOBAL log_error_verbosity=3;
Query OK, 0 rows affected (0.00 sec)За да можем да стартираме процеса на нашия съединител, трябва да конфигурираме валиден донор:
mysql> SET GLOBAL clone_valid_donor_list ='10.0.0.101:3306';
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE 'clone_valid_donor_list';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| clone_valid_donor_list | 10.0.0.101:3306 |
+------------------------+-----------------+
1 row in set (0.00 sec)След като е на място, можем да го използваме, за да копираме данните от:
mysql> CLONE INSTANCE FROM 'clone_user'@'10.0.0.101':3306 IDENTIFIED BY 'clonepass';
Query OK, 0 rows affected (18.30 sec)Това е, напредъкът може да бъде проследен в дневника за грешки на MySQL на стола. След като всичко е готово, всичко, което трябва да направите, е да настроите репликацията:
mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.101', MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected (0.05 sec)
mysql> START SLAVE USER='rpl_user' PASSWORD='afXGK2Wk8l';
Query OK, 0 rows affected, 1 warning (0.01 sec)Моля, имайте предвид, че плъгинът Clone идва с набор от ограничения. Като за начало, той прехвърля само InnoDB таблици, така че ако случайно използвате други машини за съхранение, ще трябва или да ги конвертирате в InnoDB, или да използвате друг метод за осигуряване. Освен това пречи на езика за дефиниране на данни – ALTER ще блокират и ще бъдат блокирани от операции за клониране.
По подразбиране клонирането не е криптирано, така че може да се използва само в защитена среда. Ако е необходимо, можете да настроите SSL криптиране за процеса на клониране, като се уверите, че донорът е конфигурирал SSL и след това дефинирате следните променливи на съединителя:
clone_ssl_ca=/path/to/ca.pem
clone_ssl_cert=/path/to/client-cert.pem
clone_ssl_key=/path/to/client-key.pemСлед това трябва да добавите „ИЗИСКВА SSL;“ в края на командата CLONE и процесът ще бъде изпълнен със SSL криптиране. Моля, имайте предвид, че това е единственият метод за клониране на бази данни с активирано криптиране на данни в покой.
Както споменахме в началото, клонирането най-вероятно е проектирано с MySQL Group Replication/InnoDB Cluster в ума, но доколкото ограниченията не засягат конкретен случай на употреба, то може да се използва като роден начин за предоставяне на всеки MySQL екземпляр. Ще видим колко широко приемане ще има - възможностите са многобройни. Това, което вече е страхотно, е, че вече имаме друг хардуерно-агностичен метод, който можем да използваме за осигуряване на сървъри в допълнение към Xtrabackup. Конкуренцията винаги е добра и с нетърпение очакваме да видим какво ни носи бъдещето.
