GTID o Identificatore di transazione globale è stato introdotto in MySQL 5.6.5. Un GTID è un ID univoco globale fornito a tutte le transazioni eseguite su un server di hosting MySQL abilitato per GTID. I GTID sono una combinazione dell'UUID del server in cui è stata eseguita una determinata transazione e il numero di sequenza di quella transazione su quel particolare server. Ciò rende il GTID unico a livello globale.

Replica MySQL

La replica basata su GTID è molto più flessibile rispetto alla replica basata su binlog precedente. In una configurazione basata su GTID, lo slave non ha bisogno di un file binlog principale e di una posizione per avviare la replica. Ulteriori informazioni sulla replica basata su GTID. In questo post del blog discuteremo di alcuni problemi comuni di replica di MySQL causati dalla distribuzione di un set di repliche basato su GTID.

Transazioni errate sono transazioni applicate a uno o più slave che non devono essere replicate su altri nodi. Potrebbero essere correzioni intermittenti applicate allo slave o scritture accidentali nello slave da parte di un'applicazione.

Il problema con queste transazioni errate sorge quando lo slave che contiene una transazione errante viene promosso a master. Nel caso della replica basata su GTID, ciò causerebbe un problema. Il nuovo master ora si rende conto che gli slave non hanno eseguito la transazione errata. Può succedere una di queste due cose:

(1) La transazione errata è ancora presente nel binlog del master e la invierà agli slave, questo può danneggiare i dati o causare un errore.
(2) La transazione non è presente nel binlog, e quindi non può essere inviato allo slave, causando un errore di replica.

Prevenzione

Le transazioni errate possono essere attivamente prevenute seguendo questi passaggi. Se è necessario applicare una correzione a uno slave, un modo per mitigare le transazioni errate è disattivare temporaneamente la registrazione binaria sullo slave. L'esecuzione di sql_bin_log =0 prima di eseguire la query errante dovrebbe fare il trucco. In seguito puoi abilitare binlog eseguendo sql_bin_log =1. Per impedire che qualsiasi applicazione scriva sugli slave, la sola lettura dovrebbe essere abilitata su un server quando è configurato come slave.

Rilevamento

Rilevare una transazione errata in un set di repliche MySQL basato su GTID è facile. MySQL memorizza tutti i GTID eseguiti nella sua tabella Schema delle prestazioni/schema delle informazioni in base alla versione di MySQL in uso. Prendere i GTID eseguiti dallo slave corrente e sottrarli dai GTID eseguiti sul master corrente dovrebbe darti tutte le transazioni errate su quel particolare slave. Utilità come mysqlfailover o mysqlrpladmin possono anche aiutare a rilevare le transazioni errate.

Soluzione

Una volta rilevata una transazione errata, esistono due modi per correggere gli errori di replica causati da un failover. Un modo consiste nell'eliminare il GTID della transazione errata dalla cronologia dell'esecuzione del GTID slave. In questo modo, quando lo slave viene promosso a master, la transazione errante non verrebbe replicata su tutti i nodi. Un altro modo per gestire la transazione errata è dire a tutti gli altri slave di saltare la transazione errante. Ciò includerebbe l'inserimento di una transazione vuota con lo stesso GTID della transazione errante a tutti gli altri nodi nel set di repliche. Ciò farà pensare a tutti gli altri nodi di aver già applicato questa transazione e quindi la salterà. MySQL ha un'utilità chiamata Mysqlslavetrx dedicata a questo scopo. Questa utilità può essere utilizzata per inserire transazioni vuote con il GTID specificato. L'aggiunta di transazioni vuote può avere anche altri usi , come discusso qui.