In questo articolo, daremo un'occhiata alla migrazione dalla replica tradizionale a GTID,
discuteremo come farlo completamente online. Innanzitutto, discutiamo alcune opzioni di configurazione relative a GTID. La modalità GTID determina che i GTID di utilizzo del server o meno, ciò non riguarda solo l'accesso binario di replica, perché i registri binari conterranno GTID. L'opzione di coerenza GTID garantisce che il server consenta solo l'esecuzione sicura di istruzioni in modalità GTID. Le istruzioni che non sono sicure da eseguire sono come create table as select, ce ne sono alcune altre per lo più in giro, per il valore di gtid_owned possono monitorare i GTID sulle transazioni in volo. Questo è molto utile quando stanno disattivando i GTID online.
Discutiamone alcuni e per essere esatti è solo una variabile di stato relativa a GTID. L'ONGOING_ANONYMOUS_TRANSACTION_COUNT è la controparte del GTID posseduto ma in caso di migrazione come per il ONGOING_ANONYMOUS_TRANSACTION_COUNT, si chiama transazione anonima perché non ha un identificatore che è il GTID.
Tutte le operazioni devono essere eseguite su uno dei nodi nella topologia di replica ed eventualmente su tutti i nodi. La migliore pratica consiste nell'eseguire prima lo slave e il master, ma in caso di molte operazioni l'ordine non ha molta importanza purché vengano eseguite su ciascuna istanza della topologia di replica.
In questo ambiente, ho tre macchine virtuali, due delle quali sono database e una di queste è una macchina sysbench per generare traffico, quindi iniziamo.
Maestro:192.168.66.5
Schiavo: 192.168.66.7
Sul nodo sysbench eseguiamo il comando preparato per creare un database sysbench, puoi semplicemente copiarlo e incollarlo dal basso.
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
Sul nodo sysbench viene eseguito un carico di lavoro sul master che stavamo eseguendo per la durata dell'attività.
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
Avviamo il client MySQL su tutti i nodi, tutti i nodi del database. Controlliamo l'elenco dei processi di visualizzazione sul master in modo da poter vedere che è stato eseguito qui.
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)
Va bene d'ora in poi lavoreremo prima con il salve e il master.
Quindi prima imposteremo force_gtid_consistency ='warn' on slave, to slave master.
Schiavo 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Maestro 192.168.66.5
set global enforce_gtid_consistency = 'warn';
abbiamo finito qui e controlleremo l'errore MySQL, vedere il registro degli errori, dovrebbe andare bene; non vedrai alcun errore nel registro degli errori. Il passaggio successivo consiste nell'eseguire set global require_gtid_consistency='on' ovunque e quindi controllare di nuovo la freccia.
Schiavo 192.168.66.7
set global enforce_gtid_consistency='on';
Maestro 192.168.66.5
set global enforce_gtid_consistency='on';
Quindi, il passaggio successivo è impostare gtid_mode='off_permissive' globale; quindi di nuovo avvierò il client MySQL e lo imposterò. E poi controlliamo il registro degli errori
Schiavo 192.168.66.7
set global gtid_mode='off_permissive';
Maestro 192.168.66.5
set global gtid_mode='off_permissive';
Su ogni server imposteremo gtid_mode='on_permissive'; in modo che a questo punto generiamo transazioni GTID.
Schiavo 192.168.66.7
set global gtid_mode='on_permissive';
Maestro 192.168.66.5
set global gtid_mode='on_permissive';
Quindi, è ambientato ovunque. Controlliamo i log degli errori
Va bene, quindi ora verificheremo se qualcuno dei nodi ha transazioni anonime in corso perché se è così quando impostiamo gtid_mode='on', il server non accetta più transazioni anonime e otterremo errori.
Schiavo 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)
Maestro 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)
Quindi entrambi i server non hanno, il che significa che siamo pronti per attivare i GTID. Abiliterò gtid_mode =on.
Maestro 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Schiavo 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Ora sugli slave, dobbiamo reinizializzare la replica per utilizzare master-auto-position=1
Schiavo 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Quindi, cosa fa questo "cambia master" qui, se il thread di salve era già configurato, se qualche parametro non viene toccato dal comando di modifica master, verrà semplicemente lasciato al valore corrente.
Controlliamo mostra lo stato slave sugli slave e mostra lo stato master sul master. tutto dovrebbe funzionare bene.
mysql> show salve status\G; mysql> show master status;
Ora la migrazione è completata:
Poiché sappiamo che nessun aggiornamento va a buon fine se non si dispone di un piano di rollback, per eseguire il rollback fare clic sul collegamento sottostante per leggere il prossimo articolo.
Torna alla replica tradizionale da GTID
