I denne artikel skal vi tage et kig på migrering fra traditionel replikering til GTID,
vi vil diskutere, hvordan man gør det helt online. Lad os først diskutere nogle GTID-relaterede konfigurationsmuligheder. GTID-tilstand bestemmer, om serveren bruger GTID'er eller ej, dette påvirker ikke kun binært replikeringslogin, fordi de binære logfiler vil have GTID'er i sig. Indstillingen håndhæv GTID-konsistens sikrer, at serveren kun tillader sætninger, der er sikre at udføre i GTID-tilstand. Udsagn, der er usikre at eksekvere, er som at oprette en tabel som udvalg, der er et par flere for det meste, til gtid_owned værdifulde kan de overvåge GTID'erne på transaktioner under flyvningen. Dette er meget nyttigt, når de slår GTID'er fra online.
Lad os diskutere nogle, og for at være præcis er det kun én GTID-relateret statusvariabel. ONGOING_ANONYMOUS_TRANSACTION_ COUNT er modstykket til GTID, der ejes, men i tilfælde af migrering som om ONGOING_ANONYMOUS_TRANSACTION_COUNT, kaldes det anonym transaktion, fordi den ikke har en identifikator, som er GTID.
Alle operationer skal udføres på en af noderne i replikationstopologi og til sidst på alle noderne. Den bedste praksis er at udføre slaven først og masteren, men i tilfælde af mange operationer betyder rækkefølgen ikke rigtig noget, så længe de udføres på hver forekomst af replikeringstopologien.
I dette miljø har jeg tre virtuelle maskiner, to af dem er databaser, og en af dem er sysbench-maskine til at generere trafik, så lad os starte.
Mester:192.168.66.5
Slave: 192.168.66.7
Lad os køre den forberedte kommando på sysbench-noden for at oprette en sysbench-database, du kan bare kopiere og indsætte den nedefra.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password= password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare
På sysbench-knuden kører en vis arbejdsbyrde mod masteren, som vi kørte under opgavens varighed.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --rate=10 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run
Lad os starte MySQL-klienten på alle noderne, alle databasenoderne. Lad os tjekke showproceslisten på masteren, så du kan se, at dette kører her.
mysql> show processlist; +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 2350 | Waiting on empty queue | NULL | | 8 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 15 | syncstndby | 192.168.66.7:47894 | NULL | Binlog Dump | 156 | Master has sent all binlog to slave; waiting for more updates | NULL | | 17 | sbtest_user | 192.168.66.6:38130 | sbtest | Sleep | 0 | | NULL | | 18 | sbtest_user | 192.168.66.6:38132 | sbtest | Sleep | 1 | | NULL | | 19 | sbtest_user | 192.168.66.6:38134 | sbtest | Sleep | 0 | | NULL | | 20 | sbtest_user | 192.168.66.6:38136 | sbtest | Sleep | 0 | | NULL | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ 7 rows in set (0.00 sec)
Okay fra nu af vil vi arbejde med salven først og mesteren.
Så først indstiller vi enforce_gtid_consistency ='advare' på slave til slavemester.
Slave 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Skibsfører 192.168.66.5
set global enforce_gtid_consistency = 'warn';
vi er færdige her, og vi vil kontrollere MySQL-fejlen, se fejllog, dette burde være fint; du vil ikke se nogen fejl i fejlloggen. De næste trin er at køre set global enforce_gtid_consistency='on' overalt og derefter kontrollere pilen igen.
Slave 192.168.66.7
set global enforce_gtid_consistency='on';
Skibsfører 192.168.66.5
set global enforce_gtid_consistency='on';
Så det næste trin er at indstille global gtid_mode='off_permissive'; så igen vil jeg starte MySQL-klienten og indstille den. Og så tjekker vi fejlloggen
Slave 192.168.66.7
set global gtid_mode='off_permissive';
Master 192.168.66.5
set global gtid_mode='off_permissive';
På hver server vil vi indstille gtid_mode='on_permissive'; så det så vi genererer GTID-transaktioner på dette tidspunkt.
Slave 192.168.66.7
set global gtid_mode='on_permissive';
Master 192.168.66.5
set global gtid_mode='on_permissive';
Så det er sat overalt. Lad os tjekke fejllogfilerne
Okay, så nu vil vi tjekke, om nogen af noderne har igangværende anonyme transaktioner, for hvis det har, når vi indstiller gtid_mode='on', accepterer serveren ikke længere anonyme transaktioner, og vi vil få fejl.
Slave 192.168.66.7
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.22 sec)
Skibsfører 192.168.66.5
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.04 sec)
Så begge servere har ikke, hvilket betyder, at vi er klar til at slå GTID'er til. Jeg vil aktivere gtid_mode =on.
Skibsfører 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Slave 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Hvad angår slaverne, skal vi geninitialisere replikationen for at bruge master-auto-position=1
Slave 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Så hvad det gør, denne "skift master" her, hvis salvetråden allerede var konfigureret, så hvis en parameter ikke berøres af kommandoen change master, vil den bare blive efterladt på den aktuelle værdi.
Lad os tjekke vis slavestatus på slaverne og vis masterstatus på masteren. alt jeg burde køre fint.
mysql> show salve status\G; mysql> show master status;
Nu er migreringen udført:
Som vi ved, er ingen opgradering vellykket, hvis du ikke har en tilbagerulningsplan, for at rulle tilbage skal du klikke på linket nedenfor for at læse den næste artikel.
Rul tilbage til traditionel replikering fra GTID