Återskapa en MySQL 8.0 replikeringsslav med hjälp av en klonplugin

Med MySQL 8.0 antog Oracle ett nytt tillvägagångssätt för utveckling. Istället för att pusha funktioner med större versioner, kommer nästan varje mindre MySQL 8.0-version med nya funktioner eller förbättringar. En av dessa nya funktioner är vad vi skulle vilja fokusera på i det här blogginlägget.

Historiskt har MySQL inte kommit med bra verktyg för provisionering. Visst, du hade mysqldump, men det är bara ett logiskt säkerhetskopieringsverktyg, inte riktigt lämpligt för större miljöer. MySQL Enterprise-användare kan dra nytta av MySQL Enterprise Backup medan community-användare kan använda xtrabackup. Ingen av dessa kom dock med en ren MySQL Community-distribution. Det var ganska irriterande eftersom provisionering är en uppgift du gör ganska ofta. Du kan behöva bygga en ny slav, bygga om en misslyckad - allt detta kommer att kräva någon form av dataöverföring mellan separata noder.

MySQL 8.0.17 introducerade ett nytt sätt att tillhandahålla MySQL-data - klonplugin. Det var tänkt med MySQL Group Replication i åtanke att introducera ett sätt för automatisk provisionering och återuppbyggnad av misslyckade noder, men dess användbarhet är inte begränsad till det området. Vi kan lika gärna använda den för att bygga om en slavnod eller tillhandahålla en ny server. I det här blogginlägget vill vi visa dig hur du ställer in MySQL Clone-plugin och hur du bygger om en replikeringsslav.

Först och främst måste plugin-programmet vara aktiverat eftersom det är inaktiverat som standard. När du gör detta förblir det aktiverat genom omstarter. Helst gör du det på alla noder i replikeringstopologin.

mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';

Query OK, 0 rows affected (0.00 sec)

Klonplugin kräver MySQL-användare med rätt behörighet. På donator måste den ha "BACKUP_ADMIN"-behörighet medan den på joinern måste ha "CLONE_ADMIN"-behörighet. Förutsatt att du vill använda klonpluginen i stor utsträckning, kan du bara skapa användare med båda privilegierna. Gör det på mastern så skapas användaren också på alla slavar. När allt kommer omkring vet du aldrig vilken nod som kommer att bli en mästare någon gång i framtiden, därför är det bekvämare att ha allt förberett i förväg.

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-plugin har några förutsättningar och därför bör hälsokontroller utföras. Du bör se till att både givare och ansluter har samma värden i följande konfigurationsvariabler:

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)

Då, på mastern, bör vi dubbelkolla att ångra tabellutrymmen har unika namn:

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)

Standardnivån för detaljerad information visar inte för mycket data angående kloningsprocessen, därför rekommenderar vi att du ökar den för att få bättre insikt i vad som händer:

mysql> SET GLOBAL log_error_verbosity=3;

Query OK, 0 rows affected (0.00 sec)

För att kunna starta processen på vår joiner måste vi konfigurera en giltig givare:

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)

När den är på plats kan vi använda den för att kopiera data från:

mysql> CLONE INSTANCE FROM 'clone_user'@'10.0.0.101':3306 IDENTIFIED BY 'clonepass';

Query OK, 0 rows affected (18.30 sec)

Det är allt, framstegen kan spåras i MySQL-felloggen på joinern. När allt är klart är allt du behöver göra att ställa in replikeringen:

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)

Tänk på att Clone-plugin kommer med en uppsättning begränsningar. Till att börja med överför den bara InnoDB-tabeller så om du råkar använda andra lagringsmotorer måste du antingen konvertera dem till InnoDB eller använda en annan provisioneringsmetod. Det stör också Data Definition Language - ALTERs kommer att blockeras och blockeras av kloningsoperationer.

Som standard är kloning inte krypterad så den kan endast användas i en säker miljö. Om det behövs kan du ställa in SSL-kryptering för kloningsprocessen genom att se till att givaren har SSL konfigurerat och sedan definiera följande variabler på joinern:

clone_ssl_ca=/path/to/ca.pem

clone_ssl_cert=/path/to/client-cert.pem

clone_ssl_key=/path/to/client-key.pem

Då måste du lägga till "REQUIRE SSL;" i slutet av CLONE-kommandot och processen kommer att exekveras med SSL-kryptering. Kom ihåg att detta är den enda metoden för att klona databaser med data-at-rest-kryptering aktiverad.

Som vi nämnde i början, var kloning troligen designad med MySQL Group Replication/InnoDB Cluster i åtanke, men så länge som begränsningarna inte påverkar specifika användningsfall, kan den användas som ett inbyggt sätt att tillhandahålla alla MySQL-instanser. Vi får se hur bred adoption det kommer att ha - möjligheterna är många. Vad som redan är bra är att vi nu har en annan hårdvaruagnostisk metod som vi kan använda för att tillhandahålla servrar förutom Xtrabackup. Konkurrens är alltid bra och vi ser fram emot att se vad framtiden har att erbjuda.