sql >> Database >  >> RDS >> Mysql

Online migratie van MySQL 5.6 Non-GTID naar MySQL 5.7 met GTID

In deze blogpost gaan we onderzoeken hoe u online migratie kunt uitvoeren van een zelfstandige MySQL 5.6-installatie naar een nieuwe replicatieset die draait op MySQL 5.7, geïmplementeerd en beheerd door ClusterControl.

Het plan is om een ​​replicatiekoppeling op te zetten van het nieuwe cluster dat draait op MySQL 5.7 naar de master die draait op MySQL 5.6 (buiten de ClusterControl-voorziening), die geen GTID gebruikt. MySQL ondersteunt het mengen van GTID en niet-GTID in één replicatieketen niet. We moeten dus wat trucjes doen om tijdens de migratie te schakelen tussen niet-GTID- en GTID-modi.

Ons architectuur- en migratieplan kan als volgt worden geïllustreerd:

De installatie bestaat uit 4 servers, met de volgende weergave:

  • mysql56a - Oude meester - Oracle MySQL 5.6 zonder GTID
  • Slavencluster:
    • mysql57a - Nieuwe master - Oracle MySQL 5.7 met GTID
    • mysql57b - Nieuwe slaaf - Oracle MySQL 5.7 met GTID
  • cc - ClusterControl Server - Deployment/beheer/bewakingsserver voor de databaseknooppunten.

Alle MySQL 5.7-hosts draaien op Debian 10 (Buster), terwijl de MySQL 5.6 op Debian 9 (Stretch) draait.

Het slavencluster implementeren

Laten we eerst het slavecluster voorbereiden voordat we een replicatielink van de oude master opzetten. De uiteindelijke configuratie van het slavecluster wordt uitgevoerd op MySQL 5.7, met GTID ingeschakeld. Installeer ClusterControl op de ClusterControl-server (cc):

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

Volg de instructies totdat de installatie is voltooid. Stel vervolgens wachtwoordloze SSH in vanuit ClusterControl naar mysql57a en 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 vervolgens in op de gebruikersinterface van ClusterControl, vul het eerste formulier in en ga naar het gedeelte ClusterControl -> Deploy -> MySQL-replicatie en vul het volgende in:

Klik vervolgens op Doorgaan en kies Oracle als leverancier en 5.7 als provider versie. Ga dan verder naar het topologiegedeelte en configureer het zoals hieronder:

Wacht tot de implementatie is voltooid en u het nieuwe cluster zou moeten zien zoals hieronder:

Ons slavecluster dat draait op MySQL 5.7 met GTID is nu klaar.

De oude meester voorbereiden

De huidige master die we willen repliceren is een standalone MySQL 5.6 (binair logboek ingeschakeld, server-id geconfigureerd, zonder GTID) en bedient productiedatabases. Downtime is dus geen optie voor deze migratie. Aan de andere kant configureert ClusterControl de nieuwe MySQL 5.7 met GTID-enabled, wat betekent dat we de GTID-functionaliteit in het slavecluster moeten uitschakelen om correct te kunnen repliceren vanaf deze zelfstandige master.

De volgende regels tonen onze huidige replicatie-gerelateerde configuratie voor de master /etc/mysql/mysql.conf.d/mysqld.cnf onder [mysqld]-richtlijn:

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

Controleer of de MySQL-server binaire logs produceert, zonder 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)

Voor niet-GTID wordt verwacht dat de Executed_Gtid_Set leeg is. Houd er rekening mee dat ons nieuwe MySQL 5.7-replicatiecluster dat door ClusterControl wordt geïmplementeerd, is geconfigureerd met GTID ingeschakeld.

1) Maak een replicatiegebruiker aan voor gebruik door mysql57a:

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

2) Schakel automatisch ClusterControl-herstel uit. Onder ClusterControl UI -> kies het cluster -> zorg ervoor dat de Auto Recovery Cluster en Node zijn uitgeschakeld (rode stroompictogrammen), zoals weergegeven in de onderstaande schermafbeelding:

We willen niet dat ClusterControl het knooppunt herstelt tijdens deze replicatieconfiguratie.

3) Nu moeten we een volledige mysqldump-back-up maken, aangezien dit een belangrijke versie-upgrade wordt. Andere niet-blokkerende back-uptools zoals Percona Xtrabackup of MySQL Enterprise Backup bieden geen ondersteuning voor herstel naar een andere hoofdversie. We moeten ook het huidige binaire logbestand en de huidige positie behouden met --master-data flag:

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

Merk op dat de bovenstaande opdracht geen InnoDB-tabellen blokkeert vanwege --single-transactie. Dus als u MyISAM-tabellen heeft, worden de tabellen tijdens de back-upperiode geblokkeerd om de consistentie te behouden.

4) Kopieer de back-up van mysql56a naar mysql57a en mysql57b:

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

Het slavencluster voorbereiden

In deze fase zullen we het slavecluster configureren om te beginnen met repliceren vanaf de oude master, mysql56a zonder GTID.

1) Stop de replicatie tussen mysql57a en mysql57b, verwijder alle slave-gerelateerde referenties geconfigureerd door ClusterControl en schakel alleen-lezen uit op mysql57b:

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

2) Schakel GTID uit op 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) Schakel GTID uit op 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) Herstel de mysqldump-back-up op mysql57a:

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

5) Herstel de mysqldump-back-up op mysql57b:

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

6) Voer het MySQL-upgradescript uit op mysql57a (om alle tabellen te controleren en bij te werken naar de huidige versie):

$ mysql_upgrade -uroot -p

7) Voer het MySQL-upgradescript uit op mysql57b (om alle tabellen te controleren en bij te werken naar de huidige versie):

$ mysql_upgrade -uroot -p

Beide servers op het slave-cluster zijn nu gestaged met de data-snapshot van de oude master, mysql56a, en zijn nu klaar om te repliceren.

Replicatie instellen voor het slavecluster

1) Reset binaire logbestanden met RESET MASTER op mysql57a, zodat we het binaire bestand en de logpositie later op mysql57b niet hoeven te specificeren. We verwijderen ook alle bestaande GTID-referenties die eerder waren geconfigureerd:

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

2) Haal op mysql57a het binlog-bestand en de positie op uit het dumpbestand, 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 de replicatieslave van de oude master, mysql56a naar de nieuwe master mysql57a, door de juiste MASTER_LOG_FILE- en MASTER_LOG_POS-waarden op te geven die in de vorige stap zijn opgehaald. Op 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

Zorg ervoor dat je de volgende regels ziet:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

U moet waarschijnlijk wachten tot mysql57a mysql56a inhaalt door de "Seconds_Behind_Master" te controleren en ervoor te zorgen dat deze 0 wordt.

4) Op dit moment repliceert mysql57a gegevens van mysql56a, wat betekent dat alle gebruikers die door ClusterControl zijn gemaakt nu op de server ontbreken (omdat mysql57a nu de gegevens op mysql56a volgt). ClusterControl zal een probleem hebben om verbinding te maken met mysql57a en het zal verschijnen als "down". Het betekent in feite dat ClusterControl geen verbinding kan maken met de MySQL-servers omdat de subsidies ontbreken. De ontbrekende gebruikers zijn:

Alle inloggegevens worden veilig opgeslagen in de ClusterControl en de databaseserver zelf. U moet root-toegang hebben om de inloggegevens terug te halen uit de relevante bestanden.

Laten we nu de ontbrekende gebruikers opnieuw maken op de nieuwe master, mysql57a:

a) Maak een back-upgebruiker (wachtwoord overgenomen uit /etc/mysql/secrets-backup.cnf op 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) Maak replicatiegebruikers aan voor alle DB-hosts (wachtwoord overgenomen van de variabele repl_password in /etc/cmon.d/cmon_X.cnf op de ClusterControl-server, waarbij X de cluster-ID van de slavecluster is):

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) Maak twee cmon-databasegebruikers (één voor IP-adres en één voor hostnaam) voor ClusterControl-gebruik (wachtwoord overgenomen van de mysql_password-variabele in /etc/cmon.d/cmon_X.cnf op ClusterControl-server, waarbij X de cluster-ID van de slave is cluster):

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) Op dit punt zou mysql57a groen moeten verschijnen in ClusterControl. Nu kunnen we een replicatielink instellen van mysql57a naar mysql57b. Op 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

**We hoeven MASTER_LOG_FILE en MASTER_LOG_POS niet op te geven omdat het altijd begint met een vaste beginpositie na RESET MASTER bij stap #1.

Zorg ervoor dat u de volgende regels ziet:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Bewaak de replicatiestatus en zorg ervoor dat mysql57b gelijke tred houdt met mysql57a, en mysql57a gelijke tred houdt met mysql56a. Mogelijk moet u daarna alleen-lezen inschakelen op mysql57b (en/of mysql57a) om te beschermen tegen onbedoeld schrijven. 

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

Vanuit de gebruikersinterface van ClusterControl ziet u de huidige status onder het gedeelte Overzicht:

Op dit moment repliceert de nieuwe master mysql57a, 192.168.10.31 van de oude zelfstandige host mysql56a, 192.168.10.22, terwijl de nieuwe slave mysql57b (alleen-lezen) repliceert van mysql57a, 192.168.10.31. Alle knooppunten worden gesynchroniseerd met de replicatievertraging 0.

Als alternatief kunt u commentaar geven op de volgende regels in MySQL-configuratiebestanden onder de sectie [mysqld]:

#gtid_mode=ON
#enforce_gtid_consistency=1

GTID inschakelen op het slavecluster

Merk op dat voor MySQL 5.6 en hoger, ClusterControl de niet-GTID-implementatie niet meer ondersteunt voor sommige van zijn beheerfuncties, zoals Rebuild Replication Slave en Change Replication Master. Dus tijdens de cut-off-tijd (wanneer u toepassingen naar het nieuwe cluster verwijst) vanaf de zelfstandige MySQL-server (mysql56a), wordt het aanbevolen om GTID weer in te schakelen op mysql57a en mysql57b met de volgende stappen:

1) Zorg ervoor dat u de automatische herstelfunctie van ClusterControl uitschakelt:

2) Tijdens het afsluitende onderhoudsvenster moeten we stoppen met repliceren van de oude master, mysql56a, verwijder alle slave-configuratie op mysql57a en schakel terug GTID in. Voer op mysql57a de volgende opdrachten in de juiste volgorde uit:

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';

Op dit punt is het praktisch veilig voor uw toepassing om te beginnen met schrijven naar de nieuwe master, mysql57a. De oude zelfstandige MySQL is nu uit de replicatieketen en kan worden afgesloten.

3) Herhaal dezelfde stappen voor mysql57b. Vergeet niet om de stappen in de juiste volgorde te volgen:

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) Reset vervolgens de master op de nieuwe master, mysql57a:

mysql> RESET MASTER;

3) Stel vervolgens op de nieuwe slave mysql57b de replicatielink in met GTID naar 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

Zorg ervoor dat de velden Retrieved_Gtid_Set en Executed_Gtid_Set de GTID-waarde hebben.

4) Op dit moment hebben we de replicatieconfiguratie hersteld zoals deze eerder door ClusterControl was geconfigureerd tijdens de clusterimplementatiefase. We kunnen dan alleen-lezen inschakelen op de nieuwe slaaf, mysql57b om deze te beschermen tegen onbedoeld schrijven:

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

Schakel tot slot automatisch ClusterControl-herstel voor het cluster weer in door de aan/uit-pictogrammen groen te maken. U kunt dan de oude meester, mysql56a, buiten gebruik stellen. We hebben zojuist onze online migratie van MySQL 5.6 naar MySQL 5.7 afgerond met zeer minimale downtime. De vergelijkbare stappen zouden ook moeten werken voor migratie naar MySQL 8.0.


  1. Wat is er mis met deze PL/SQL? Bindvariabele * is NIET VERKLAARD

  2. SQL Express opstarten vanuit WiX?

  3. 2 manieren om alle triggers in een PostgreSQL-database op te sommen

  4. Verkrijg de positie van een teken in een tekenreeks in SQLite met Instr()