I den här artikeln ska vi ta en titt på migrering från traditionell replikering till GTID,
vi kommer att diskutera hur man gör det helt online. Låt oss först diskutera några GTID-relaterade konfigurationsalternativ. GTID-läget bestämmer att servern använder GTID eller inte, detta påverkar inte bara binär inloggning för replikering eftersom de binära loggarna kommer att ha GTID i sig. Alternativet framtvinga GTID-konsistens säkerställer att servern endast tillåter uttalanden som är säkra att köra i GTID-läge. Uttalanden som är osäkra att exekvera är som att skapa tabeller som välj, det finns några fler för det mesta, till gtid_owned värdefulla kan de övervaka GTID på transaktioner under flygning. Detta är mycket användbart när de stänger av GTID online.
Låt oss diskutera några och för att vara exakt är det bara en GTID-relaterad statusvariabel. ONGOING_ANONYMOUS_TRANSACTION_ COUNT är motsvarigheten till GTID som ägs, men i händelse av migrering som om ONGOING_ANONYMOUS_TRANSACTION_COUNT, kallas det anonym transaktion eftersom den inte har en identifierare som är GTID.
Alla operationer måste göras på en av noderna i replikeringstopologi och så småningom på alla noder. Den bästa praxisen är att göra slaven först och mastern, men vid många operationer spelar ordningen egentligen ingen roll så länge de utförs på varje instans av replikeringstopologin.
I den här miljön har jag tre virtuella maskiner, två av dem är databaser och en av dem är sysbench-maskin för att generera trafik så låt oss börja.
Mästare:192.168.66.5
Slav: 192.168.66.7
Låt oss köra det förberedda kommandot på sysbench-noden för att skapa en sysbench-databas, du kan bara kopiera och klistra in den underifrån.
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-noden körs en viss arbetsbelastning mot mastern som vi körde under hela uppgiften.
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
Låt oss starta MySQL-klienten på alla noder, alla databasnoder. Låt oss kolla showprocesslistan på mastern så att du kan se att detta körs här.
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)
Okej från och med nu kommer vi att arbeta med salvan först och mastern.
Så först ställer vi in enforce_gtid_consistency ='varna' på slav, till slavmästare.
Slav 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Mästare 192.168.66.5
set global enforce_gtid_consistency = 'warn';
vi är klara här och vi kommer att kontrollera MySQL-felet se fellogg detta borde vara bra; du kommer inte att se något fel i felloggen. Nästa steg är att köra set global enforce_gtid_consistency=’on’ överallt och sedan kontrollera pilen igen.
Slav 192.168.66.7
set global enforce_gtid_consistency='on';
Mästare 192.168.66.5
set global enforce_gtid_consistency='on';
Så, nästa steg är att ställa in global gtid_mode='off_permissive'; så igen kommer jag att starta MySQL-klienten och ställa in den. Och sedan kontrollerar vi felloggen
Slav 192.168.66.7
set global gtid_mode='off_permissive';
Master 192.168.66.5
set global gtid_mode='off_permissive';
På varje server kommer vi att ställa in gtid_mode='on_permissive'; så det är så att vi genererar GTID-transaktioner vid det här laget.
Slav 192.168.66.7
set global gtid_mode='on_permissive';
Master 192.168.66.5
set global gtid_mode='on_permissive';
Så den är inställd överallt. Låt oss kontrollera felloggarna
Okej, så nu kommer vi att kontrollera om någon av noderna har pågående anonyma transaktioner för om det har gjort det när vi ställer in gtid_mode=’on’, accepterar inte servern längre anonyma transaktioner och vi kommer att få fel.
Slav 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)
Mästare 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å båda servrarna har inte vilket betyder att vi är redo att slå på GTID. Jag kommer att aktivera gtid_mode =on.
Mästare 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Slav 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Nu när det gäller slavarna måste vi återinitiera replikeringen för att använda master-auto-position=1
Slav 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Så, vad det här gör, denna "ändra master" här, om salvtråden redan var konfigurerad så om någon parameter inte berörs av kommandot change master, kommer den bara att lämnas vid det aktuella värdet.
Låt oss kontrollera visa slavstatus på slavarna och visa masterstatus på mastern. allt jag borde fungera bra.
mysql> show salve status\G; mysql> show master status;
Nu är migreringen klar:
Som vi vet är ingen uppgradering framgångsrik om du inte har en återställningsplan, för att återställa vänligen klicka på länken nedan för att läsa nästa artikel.
Återställ till traditionell replikering från GTID