In dit artikel gaan we kijken naar de migratie van traditionele replicatie naar GTID,
we bespreken hoe je dit volledig online kunt doen. Laten we eerst enkele GTID-gerelateerde configuratie-opties bespreken. De GTID-modus bepaalt of de server GTID's gebruikt of niet, dit is niet alleen van invloed op binaire aanmelding bij replicatie, omdat de binaire logboeken GTID's bevatten. De optie GTID-consistentie afdwingen zorgt ervoor dat de server alleen instructies toestaat die veilig kunnen worden uitgevoerd in GTID-modus. Verklaringen die onveilig zijn om uit te voeren, zijn zoals een tabel maken als selecteren, er zijn er nog een paar, meestal in de buurt, voor de gtid_owned waardevol kunnen ze de GTID's op transacties tijdens de vlucht controleren. Dit is erg handig wanneer ze GTID's online uitschakelen.
Laten we er een paar bespreken en om precies te zijn, het is slechts één GTID-gerelateerde statusvariabele. De ONGOING_ANONYMOUS_TRANSACTION_COUNT is de tegenhanger van GTID die eigendom is, maar in het geval van migratie zoals over de ONGOING_ANONYMOUS_TRANSACTION_COUNT, wordt het anonieme transactie genoemd omdat het geen ID heeft dat de GTID is.
Alle bewerkingen moeten worden uitgevoerd op een van de knooppunten in de replicatietopologie en uiteindelijk op alle knooppunten. Het beste is om eerst de slave en de master te doen, maar in het geval van veel bewerkingen maakt de volgorde niet echt uit, zolang ze maar worden uitgevoerd op elk exemplaar van de replicatietopologie.
In deze omgeving heb ik drie virtuele machines, twee daarvan zijn databases en een daarvan is een sysbench-machine om verkeer te genereren, dus laten we beginnen.
Meester:192.168.66.5
Slaaf: 192.168.66.7
Laten we op het sysbench-knooppunt het voorbereide commando uitvoeren om een sysbench-database te maken, u kunt het gewoon van onderaf kopiëren en plakken.
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
Op het sysbench-knooppunt wordt enige werklast uitgevoerd tegen de master die we aan het uitvoeren waren voor de duur van de taak.
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
Laten we de MySQL-client starten op alle knooppunten, alle databaseknooppunten. Laten we eens kijken naar de lijst met processen voor weergeven op de master, zodat u kunt zien dat deze hier wordt uitgevoerd.
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)
Oké, vanaf nu werken we eerst met de zalf en de meester.
Dus eerst zullen we force_gtid_consistency ='warn' op slave instellen op slave master.
Slaaf 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Master 192.168.66.5
set global enforce_gtid_consistency = 'warn';
we zijn hier klaar en we zullen de MySQL-fout controleren. Zie foutenlogboek dit zou in orde moeten zijn; u ziet geen enkele fout in het foutenlogboek. De volgende stap is om overal set global force_gtid_consistency=’on’ uit te voeren en vervolgens de pijl opnieuw aan te vinken.
Slaaf 192.168.66.7
set global enforce_gtid_consistency='on';
Master 192.168.66.5
set global enforce_gtid_consistency='on';
Dus de volgende stap is het instellen van global gtid_mode=’off_permissive’; dus nogmaals, ik zal de MySQL-client starten en instellen. En dan controleren we het foutenlogboek
Slaaf 192.168.66.7
set global gtid_mode='off_permissive';
Master 192.168.66.5
set global gtid_mode='off_permissive';
Op elke server zullen we de gtid_mode=’on_permissive’; zodat we op dit moment GTID-transacties genereren.
Slaaf 192.168.66.7
set global gtid_mode='on_permissive';
Master 192.168.66.5
set global gtid_mode='on_permissive';
Het is dus overal ingesteld. Laten we de foutenlogboeken controleren
Oké, dus nu zullen we controleren of een van de knooppunten lopende anonieme transacties heeft, want als dit het geval is, wanneer we gtid_mode='on' instellen, accepteert de server geen anonieme transacties meer en krijgen we fouten.
Slaaf 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)
Master 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)
Dus beide servers hebben niet wat betekent dat we klaar zijn om GTID's in te schakelen. Ik zal gtid_mode =on inschakelen.
Master 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Slaaf 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Nu, op de slaven, moeten we de replicatie opnieuw initialiseren om master-auto-position=1 te gebruiken
Slaaf 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Dus wat dit doet, deze "change master" hier, als de salve-thread al is geconfigureerd en als een parameter niet wordt aangeraakt door het commando change master, wordt deze gewoon op de huidige waarde gelaten.
Laten we de slave-status weergeven op de slaven en de masterstatus op de master weergeven. alles zou goed moeten werken.
mysql> show salve status\G; mysql> show master status;
Nu is de migratie voltooid:
Zoals we weten, is geen enkele upgrade succesvol als u geen terugdraaiplan heeft. Om het terug te draaien, klikt u op de onderstaande link om het volgende artikel te lezen.
Terugkeren naar traditionele replicatie van GTID