La replica tiene un secondo server che porta gli stessi dati e applica gli stessi cambiamenti poco dopo il primo. Serve a tre cose e viene regolarmente messa in piedi per una quarta che non offre.

A che cosa serve

  • Capacità di lettura - report e ricerche vanno sulla replica, le scritture sul primario.
  • Backup senza carico - faccia il dump dalla replica e il sito in produzione non si accorge di niente.
  • Il failover - una copia tiepida pronta a essere promossa, che trasforma una ricostruzione in una commutazione.

Che cosa non è

Una replica non è un backup. DROP TABLE orders si replica in meno di un secondo e adesso a entrambe le copie manca quella tabella. I backup proteggono dagli errori; le repliche proteggono da una macchina che muore. Servono tutti e due - veda il backup come misura di sicurezza.

Il ritardo che nessuno mette in conto

La replica è asincrona per impostazione predefinita: il primario non aspetta. Una scrittura seguita subito da una lettura sulla replica può restituire il valore vecchio: un cliente salva il profilo e lo rivede immutato.

mysql -e "SHOW REPLICA STATUS\G" | grep -E 'Seconds_Behind|Replica_(IO|SQL)_Running'

La regola che lo evita: legga dalla replica soltanto dove un dato leggermente vecchio è accettabile. Tutto ciò che l'utente ha appena scritto si legge dal primario.

Come si mette in piedi, a grandi linee

  1. Attivi il log binario sul primario — log_bin, un server_id unico e gtid_mode = ON.
  2. Crei un utente di replica — con il solo REPLICATION SLAVE.
  3. Semini la replica da un dump coerente — mysqldump --single-transaction --source-data=2
  4. La punti sul primario e la avvii — poi guardi lo stato finché non recupera.

E poi la tenga d'occhio

Una replica ferma è silenziosa. Continua a rispondere alle letture con dati ormai vecchi di giorni, il che è peggio di essere caduta. Metta l'allarme sia sui flag di funzionamento sia sul ritardo.