Strategia di recupero per la replica Master-Master

Ho implementato una soluzione HA per mysql basata sulla replica master-master. C'è un meccanismo sulla parte frontale che garantisce che un solo db verrà letto / scritto in un dato momento (cioè usiamo solo la replica per HA).

Ho confermato che la replica funziona come previsto, ma mi chiedo lo scenario di errore e il ripristino. In particolare, mi preoccupo di ciò che accade quando un master fallisce in uno stato irrecuperabile e deve essere ricreato dall'altro master:

• Poiché l'altro master è attivo e molto probabilmente utilizzato, non riesco a bloccarlo e creare dump da mysqldump(i nostri database sono moderatamente grandi e mysqldumppossono facilmente richiedere ore dopo alcuni mesi di utilizzo).
• Anche supponendo che io abbia un dump, è cruciale che la posizione del binlog mostrata da SHOW MASTER STATUS corrisponda al dump che viene eseguito dopo che il database è stato bloccato.

La semplice soluzione al primo problema è utilizzare un terzo database che funge da backup, da cui posso eseguire mysqldump. Ma allora come posso assicurarmi che il master ricreato possa avviare la replica dal master in esecuzione in modo coerente?

Sono a conoscenza di due approcci di base a questo problema. Innanzitutto, se stai eseguendo InnoDB anziché Myisam, puoi eseguire il backup in una transazione (--single-transazione --lock-tables = FALSE), che combinata con --flush-logs (non richiesto ma carino) e --master-data ti darà un backup coerente con le informazioni sulla posizione della replica. I log di scarico reimposteranno i log prima della creazione del dump, il che significa che la posizione sarà sempre 106 e --master-data inserirà il nome e la posizione del file di registro nel file di dump. Ovviamente, devi eseguirlo sul master affinché --master-data funzioni.

Il secondo modo, che hai citato, è usare un terzo host per creare i backup. In questo caso, è necessario interrompere la replica, assicurarsi che il DB sia read_only (anche se in realtà, tutte le repliche devono essere lette solo poiché ciò non influisce sulle scritture dalla replica) e quindi creare il backup E registrare la posizione della replica. In questo caso non è possibile utilizzare --master-data. Invece, potresti fare qualcosa del genere:

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

Se è necessario ripristinare da questo backup, eseguire il ripristino e quindi impostare la replica in cui i due parametri master_log_file e master_log_pos provengono dal file DB.replication:

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

Nota: puoi E DOVREBBE testarlo da un'altra replica.

Nota aggiuntiva: se si dispone di un pool di repliche (ad esempio se sono state separate letture da scritture per un'app Web) è possibile che le repliche non siano sincronizzate con il nuovo master; ciò può accadere se il failover si verifica durante un periodo di I / O di scrittura pesante poiché le repliche si eseguono in streaming in modo asincrono e non esiste alcuna garanzia che lo standby sia nella stessa posizione delle altre repliche durante il failover. Tuttavia, questo non mi è ancora successo ...