Backup di un database MySQL tramite snapshot ZFS

Ho trovato numerosi siti che parlano esattamente di questo, ma mi mancano alcuni dettagli importanti. I passaggi generali sono

• Correre FLUSH TABLES WITH READ LOCK
• Scatta l'istantanea ZFS
• Correre UNLOCK TABLES

Varie fonti riportano che InnoDB, che sto usando, in realtà non onora un FLUSH. Il manuale dell'utente di MySQL indica che esiste una FLUSH TABLES...FOR EXPORTvariante per l'utilizzo con InnoDB, ma che richiede di specificare ciascuna tabella singolarmente, anziché eseguire il backup dell'intero database. Preferirei evitare di specificare ogni tabella singolarmente perché esiste una buona possibilità che l'elenco delle tabelle diventi non sincronizzato con le tabelle che esistono effettivamente.

L'altro problema che ho è che ho pianificato di fare qualcosa del genere mysql -h"$HOST" -u"$USERNAME" -p"$PASSWORD" --execute="FLUSH TABLES WITH READ LOCK". Tuttavia, questo rilascia il blocco immediatamente dopo la chiusura della sessione. Questo ha senso, ma è anche piuttosto fastidioso poiché devo tenere il blocco di lettura quando scatto la mia istantanea.

L'altra mia idea è quella di fare un backup a caldo usando uno strumento come Percona XtraBackup e scattare istantanee del backup, ma preferirei non pagare il costo per scrivere tutti i miei dati in una seconda posizione solo per fare un'istantanea.

Se usi InnoDB solo per tutte le tabelle e imposti innodb_flush_log_at_trx_commitsu:

• 1 (il contenuto del buffer di registro InnoDB viene scritto nel file di registro ad ogni commit della transazione e il file di registro viene scaricato sul disco) o,
• 2 (il contenuto del buffer di registro InnoDB viene scritto nel file di registro dopo ogni commit della transazione e il file di registro viene scaricato sul disco circa una volta al secondo),

quindi non hai bisogno di FLUSH TABLES prima di fare un'istantanea, esegui direttamente l'istantanea ZFS. InnoDB può recuperare i dati dai registri di commit delle transazioni senza perdita di dati.

Rif: https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

È necessario un blocco completo del database per eseguire il backup di uno (più) database in modo coerente.

Il manuale https://dev.mysql.com/doc/refman/5.5/en/backup-methods.html afferma che FLUSH TABLES WITH READ LOCK è specifico per le istantanee ZFS.

Esecuzione di backup mediante un'istantanea del file system

Se si utilizza un file system Veritas, è possibile eseguire un backup in questo modo:

1. Da un programma client, eseguire FLUSH TABLES WITH READ LOCK.
2. Da un'altra shell, eseguire mount vxfssnapshot.
3. Dal primo client, eseguire UNLOCK TABLES.
4. Copia i file dall'istantanea.
5. Smonta l'istantanea.

Funzionalità di istantanee simili potrebbero essere disponibili in altri file system, come LVM o ZFS.

E 'sorta di ridicolo che hanno lasciato fuori il fatto che è necessario FLUSH TABLES table_a, table_b, table_c FOR EXPORTper InnoDB da queste istruzioni. È anche stupido dover specificare ogni tabella in questo modo. Ma, come afferma EEAA, è possibile generare un elenco di tabelle quando si avvia il backup abbastanza facilmente.

Per quanto riguarda il mantenimento del blocco, è necessario mantenere attiva la connessione db durante l'esecuzione dell'istantanea

Generalmente userei qualcosa come Perl o un altro linguaggio di programmazione che può connettersi, bloccare il db e mantenendo la connessione db prendere l'istantanea, quindi sbloccare e disconnettermi. Non è complesso Scommetto che ci sono strumenti là fuori che lo fanno già, ma scriverne uno è facile.

Dico facile, non complesso, ecc. Alcune volte. Suppongo che tu abbia una programmazione di base o buone capacità di scripting.

Ho strappato e adattato una sceneggiatura concettualmente semplice in Bash che ho trovato in un altro post di Server Fault di Tobia . Dovrebbe arrivare a circa il 90% del percorso lì.

mysql_locked=/var/run/mysql_locked

# flush & lock MySQL, touch mysql_locked, and wait until it is removed
mysql -hhost -uuser -ppassword -NB <<-EOF &
    flush tables with read lock;
    delimiter ;;
    system touch $mysql_locked
    system while test -e $mysql_locked; do sleep 1; done
    exit
EOF

# wait for the preceding command to touch mysql_locked
while ! test -e $mysql_locked; do sleep 1; done

# take a snapshot of the filesystem, while MySQL is being held locked
zfs snapshot zpool/$dataset@$(date +"%Y-%m-%d_%H:%M")

# unlock MySQL
rm -f $mysql_locked

Qui, il mysqlcomando che usi viene eseguito in background e tocca un file. Attende in background che il file scompaia prima di uscire e quindi sbloccare le tabelle. Nel frattempo lo script principale attende fino a quando il file esiste, quindi crea lo snapshot ed elimina il file.

Il file a cui punta $mysql_lockeddeve essere accessibile ad entrambi i computer, cosa che dovresti essere in grado di fare abbastanza facilmente poiché entrambi possono accedere a un set di dati comune (anche se potrebbero usare percorsi diversi, e dovresti tenerne conto).

Per myisam hai bisogno di FLUSH TABLES WITH READ LOCK perché non è journaling.

Non hai davvero bisogno di nulla per innodb, IMO, perché è il journaling. Sarà comunque coerente, ripristina automaticamente il diario se succede qualcosa nell'istante atomico in cui scatti.

Se si desidera la coerenza a livello di applicazione, l'applicazione deve utilizzare le transazioni. Se la tua applicazione utilizza transazioni e innodb, qualsiasi snapshot sarà coerente e richiedi automaticamente il passaggio al livello dell'applicazione.

Questa è la mia soluzione su come creare uno snapshot ZFS mantenendo il blocco:

mysql << EOF
    FLUSH TABLES WITH READ LOCK;
    system zfs snapshot data/db@snapname
    UNLOCK TABLES;
EOF