sql >> Database teknologi >  >> RDS >> Mysql

Online migrering fra MySQL 5.6 Non-GTID til MySQL 5.7 med GTID

I dette blogindlæg skal vi se på, hvordan man udfører online migrering fra MySQL 5.6 selvstændig opsætning til et nyt replikeringssæt, der kører på MySQL 5.7, implementeret og administreret af ClusterControl.

Planen er at oprette et replikeringslink fra den nye klynge, der kører på MySQL 5.7, til masteren, der kører på MySQL 5.6 (uden for ClusterControl-bestemmelsen), som ikke bruger noget GTID. MySQL understøtter ikke blanding af GTID og ikke-GTID i én replikationskæde. Så vi er nødt til at lave nogle tricks for at skifte mellem ikke-GTID- og GTID-tilstande under migreringen.

Vores arkitektur og migrationsplan kan illustreres som nedenfor:

Opsætningen består af 4 servere med følgende repræsentation:

  • mysql56a - Gammel master - Oracle MySQL 5.6 uden GTID
  • Slaveklynge:
    • mysql57a - Ny master - Oracle MySQL 5.7 med GTID
    • mysql57b - Ny slave - Oracle MySQL 5.7 med GTID
  • cc - ClusterControl Server - Deployment/management/monitoring server for database noder.

Alle MySQL 5.7-værter kører på Debian 10 (Buster), mens MySQL 5.6 kører på Debian 9 (Stretch).

Deployering af slaveklyngen

Lad os først forberede slaveklyngen, før vi opsætter et replikeringslink fra den gamle master. Den endelige konfiguration af slaveklyngen kører på MySQL 5.7, med GTID aktiveret. Installer ClusterControl på ClusterControl-serveren (cc):

$ wget https://severalnines.com/downloads/install-cc
$ chmod 755 install-cc
$ ./install-cc

Følg instruktionerne, indtil installationen er fuldført. Konfigurer derefter adgangskodefri SSH fra ClusterControl til mysql57a og mysql57b:

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts
$ ssh-copy-id [email protected] # enter the target host root password
$ ssh-copy-id [email protected] # enter the target host root password

Log derefter ind på ClusterControl UI, udfyld den indledende formular og gå til ClusterControl -> Implementer -> MySQL-replikeringsafsnittet, og udfyld følgende:

Klik derefter på Fortsæt og vælg Oracle som leverandør og 5.7 som udbyder version. Fortsæt derefter til topologiafsnittet og konfigurer det som nedenfor:

Vent, indtil installationen er fuldført, og du skulle se den nye klynge som nedenfor:

Vores slaveklynge, der kører på MySQL 5.7 med GTID, er nu klar.

Forberedelse af den gamle mester

Den nuværende master, som vi ønsker at replikere, er en selvstændig MySQL 5.6 (binær log aktiveret, server-id konfigureret, uden GTID), og den betjener produktionsdatabaser. Så nedetid er ikke en mulighed for denne migrering. På den anden side konfigurerer ClusterControl den nye MySQL 5.7 med GTID-aktiveret, hvilket betyder, at vi skal deaktivere GTID-funktionalitet inde i slaveklyngen for at kunne replikere korrekt fra denne selvstændige master.

De følgende linjer viser vores aktuelle replikeringsrelaterede konfiguration for master /etc/mysql/mysql.conf.d/mysqld.cnf under [mysqld]-direktivet:

server_id=1
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
sync_binlog=1

Bekræft, at MySQL-serveren producerer binær log uden GTID:

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000007 |   734310 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

For ikke-GTID forventes Executed_Gtid_Set at være tomt. Bemærk, at vores nye MySQL 5.7 replikeringsklynge implementeret af ClusterControl er konfigureret med GTID aktiveret.

1) Opret en replikeringsbruger, der skal bruges af mysql57a:

mysql> CREATE USER 'slave'@'192.168.10.31' IDENTIFIED BY 'slavepassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@192.168.10.31';

2) Deaktiver ClusterControl automatisk gendannelse. Under ClusterControl UI -> vælg klyngen -> sørg for, at Auto Recovery Cluster og Node er slået FRA (røde strømikoner), som vist på skærmbilledet nedenfor:

Vi ønsker ikke, at ClusterControl skal genoprette noden under denne replikeringskonfiguration.

3) Nu skal vi oprette en fuld mysqldump-sikkerhedskopi, da dette bliver en større versionsopgradering. Andre ikke-blokerende sikkerhedskopieringsværktøjer som Percona Xtrabackup eller MySQL Enterprise Backup understøtter ikke gendannelse til en anden større version. Vi skal også bevare den aktuelle binære logfil og position ved hjælp af --master-data flag:

$ mysqldump -u root -p --single-transaction --master-data=2 --all-databases > mysql56a-fullbackup.sql

Bemærk, at ovenstående kommando ikke vil blokere nogen InnoDB-tabeller på grund af --single-transaction. Så hvis du har MyISAM-tabeller, vil tabellerne blive blokeret i sikkerhedskopieringsperioden for at bevare konsistensen.

4) Kopier sikkerhedskopien fra mysql56a til mysql57a og mysql57b:

$ scp mysql56a-fullbackup.sql [email protected]:~
$ scp mysql56a-fullbackup.sql [email protected]:~

Forberedelse af slaveklyngen

I denne fase vil vi konfigurere slaveklyngen til at begynde at replikere fra den gamle master, mysql56a uden GTID.

1) Stop replikationen mellem mysql57a og mysql57b, fjern alle slave-relaterede legitimationsoplysninger konfigureret af ClusterControl og deaktiver skrivebeskyttet på mysql57b:

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;

2) Deaktiver GTID på mysql57a:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

3) Deaktiver GTID på mysql57b:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

4) Gendan mysqldump-sikkerhedskopien på mysql57a:

$ mysql -uroot -p < mysql56a-fullbackup.sql

5) Gendan mysqldump-sikkerhedskopien på mysql57b:

$ mysql -uroot -p < mysql56a-fullbackup.sql

6) Kør MySQL-opgraderingsscript på mysql57a (for at kontrollere og opdatere alle tabeller til den aktuelle version):

$ mysql_upgrade -uroot -p

7) Kør MySQL opgraderingsscript på mysql57b (for at kontrollere og opdatere alle tabeller til den aktuelle version):

$ mysql_upgrade -uroot -p

Begge servere på slaveklyngen er nu iscenesat med datasnapshotet fra den gamle master, mysql56a, og er nu klar til at replikere.

Opsætning af replikering for slaveklyngen

1) Nulstil binære logfiler ved hjælp af RESET MASTER på mysql57a, så vi ikke behøver at angive den binære fil og logpositionering senere på mysql57b. Vi fjerner også alle eksisterende GTID-referencer, der var konfigureret før:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';

2) På mysql57a skal du hente binlog-filen og positionen fra dump-filen, mysql56a-fullbackup.sql:

$ head -100 mysql56a-fullbackup.sql | grep LOG_POS
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;

3) Start replikeringsslave fra den gamle master, mysql56a til den nye master mysql57a, ved at angive de korrekte MASTER_LOG_FILE og MASTER_LOG_POS værdier hentet på det forrige trin. På mysql57a:

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.22', MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Sørg for, at du ser følgende linjer:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Du skal sandsynligvis vente, indtil mysql57a indhenter mysql56a ved at overvåge "Seconds_Behind_Master" og sørge for, at den bliver 0.

4) På dette tidspunkt replikerer mysql57a data fra mysql56a, hvilket betyder, at alle brugere oprettet af ClusterControl nu mangler fra serveren (fordi mysql57a nu følger dataene på mysql56a). ClusterControl vil have et problem med at oprette forbindelse til mysql57a, og det vises som "ned". Det betyder grundlæggende, at ClusterControl ikke er i stand til at oprette forbindelse til MySQL-serverne, fordi bevillingerne mangler. De manglende brugere er:

Alle legitimationsoplysningerne er gemt sikkert i ClusterControl og selve databaseserveren. Du skal have root-adgangen for at hente legitimationsoplysningerne tilbage fra de relevante filer.

Lad os nu genskabe de manglende brugere på den nye master, mysql57a:

a) Opret backup-bruger (adgangskode taget fra /etc/mysql/secrets-backup.cnf på mysql57a):

mysql> CREATE USER [email protected] IDENTIFIED BY '[email protected]!65%JlNB1z';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO [email protected];

b) Opret replikeringsbrugere for alle DB-værter (adgangskode taget fra repl_password-variabelen inde i /etc/cmon.d/cmon_X.cnf på ClusterControl-serveren, hvor X er klynge-id'et for slaveklyngen):

mysql> CREATE USER 'rpl_user'@'192.168.10.31' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.31';
mysql> CREATE USER 'rpl_user'@'192.168.10.32' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.32';

c) Opret to cmon-databasebrugere (en for IP-adresse og en for værtsnavn) til ClusterControl-brug (adgangskode taget fra mysql_password-variabelen inde i /etc/cmon.d/cmon_X.cnf på ClusterControl-serveren, hvor X er klynge-id'et for slaven klynge):

mysql> CREATE USER [email protected]'192.168.10.19' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.10.19' WITH GRANT OPTION;
mysql> CREATE USER [email protected]'cc.local' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'cc.local' WITH GRANT OPTION;

5) På dette tidspunkt skulle mysql57a fremstå grønt i ClusterControl. Nu kan vi konfigurere et replikeringslink fra mysql57a til mysql57b. På mysql57b:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J';
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

**Vi behøver ikke at angive MASTER_LOG_FILE og MASTER_LOG_POS, fordi det altid starter med en fast startposition efter RESET MASTER ved trin #1.

Sørg for at se følgende linjer:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Overvåg replikeringsstatus og sørg for, at mysql57b følger med mysql57a, og at mysql57a følger med mysql56a. Du skal muligvis aktivere skrivebeskyttet på mysql57b (og/eller mysql57a) derefter for at beskytte mod utilsigtet skrivning. 

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

Fra ClusterControl UI kan du se den aktuelle tilstand under Oversigtssektionen:

På dette tidspunkt replikerer den nye master mysql57a, 192.168.10.31 fra den gamle selvstændige vært mysql56a, 192.168.10.22, mens den nye slave mysql57b (skrivebeskyttet) replikerer fra mysql57a, 192.168.10.31. Alle noder synkroniseres med replikationsforsinkelsen 0.

Alternativt kan du kommentere følgende linjer inde i MySQL-konfigurationsfiler under [mysqld]-sektionen:

#gtid_mode=ON
#enforce_gtid_consistency=1

Aktivering af GTID på slaveklyngen

Bemærk, at for MySQL 5.6 og nyere, understøtter ClusterControl ikke længere implementeringen af ​​ikke-GTID på nogle af dets administrationsfunktioner som Rebuild Replication Slave og Change Replication Master. Så i løbet af afskæringstiden (når du peger programmer til den nye klynge) fra den selvstændige MySQL-server (mysql56a), anbefales det at aktivere GTID tilbage på mysql57a og mysql57b med følgende trin:

1) Sørg for at deaktivere ClusterControls automatiske gendannelsesfunktion:

2) Under afskæringsvedligeholdelsesvinduet er vi nødt til at stoppe med at replikere fra den gamle master, mysql56a, fjern al slavekonfiguration på mysql57a og aktiver tilbage GTID. På mysql57a skal du køre følgende kommandoer i den rigtige rækkefølge:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

På dette tidspunkt er det praktisk talt sikkert for din ansøgning at begynde at skrive til den nye master, mysql57a. Den gamle selvstændige MySQL er nu ude af replikationskæden og kan lukkes ned.

3) Gentag de samme trin for mysql57b. Husk at følge trinene i den rigtige rækkefølge:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

4) Nulstil derefter master på den nye master, mysql57a:

mysql> RESET MASTER;

3) Derefter på den nye slave, mysql57b opsætte replikeringslinket ved hjælp af GTID til mysql57a:

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Sørg for, at felterne Retrieved_Gtid_Set og Executed_Gtid_Set har sin GTID-værdi.

4) På dette tidspunkt har vi gendannet replikeringskonfigurationen som tidligere konfigureret af ClusterControl under klyngeimplementeringsstadiet. Vi kan derefter aktivere skrivebeskyttet på den nye slave, mysql57b for at beskytte den mod utilsigtet skrivning:

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

Genaktiver endelig ClusterControl automatisk gendannelse for klyngen ved at skifte strømikonerne til grønne. Du kan derefter dekommissionere den gamle master, mysql56a. Vi har netop afsluttet vores online-migrering fra MySQL 5.6 til MySQL 5.7 med meget minimal nedetid. De lignende trin burde også fungere for migrering til MySQL 8.0.


  1. Sådan beskytter du en JDBC-applikation mod SQL-injektion

  2. Oracle:Dage mellem to dato og Ekskluder hverdage hvordan man håndterer negative tal

  3. Kalde pl/sql funktion i java?

  4. Hvordan tilføjes indledende nul i et tal i Oracle SQL-forespørgsel?