Backup giornaliero di un database MySQL da 22 GB

In questo momento sono in grado di fare il backup usando mysqldump. Ma devo smontare il web server E ci vogliono circa 5 minuti per fare il backup. Se non rimuovo il server Web, ci vuole un'eternità e non finisce mai + il sito Web diventa inaccessibile durante il backup.

Esiste un modo più rapido / migliore per eseguire il backup dei miei 22 GB e del database in crescita?

Tutte le tabelle sono MyISAM.

Sì.

Configura la replica su una seconda macchina. Quando è necessario eseguire un backup, è possibile bloccare il computer secondario, eseguire mysqlhotcopy o mysqldump e quindi sbloccarlo. Ti raggiungerà con il tuo master e non dovrai mai metterlo offline.

Potresti anche farlo sulla stessa macchina, se non ti dispiace raddoppiare l'I / O di scrittura, ma idealmente dovresti eseguirne il backup in tempo reale su un secondo server fisico e eseguire i backup delle tue istantanee tutte le volte che ti servono senza disturbare il server di produzione.

È anche teoricamente possibile ripristinare un database utilizzando uno stato noto e binlog. Non l'ho mai fatto, quindi ti preghiamo di investigare prima, ma potresti eseguire il backup di uno stato noto del tuo database, quindi eseguire il backup di tutti i nuovi binlog e riprodurli se mai hai bisogno di ripristinare. Poiché i binlog sono scritti in modo lineare, risincronizzare i nuovi binlog su un computer remoto sarebbe molto veloce.

Modifica: in effetti, sembra che l'utilizzo dei binlog per il backup sia documentato.

Questa domanda è fortemente correlata

Mi scusi se presumo che il sistema operativo sia Linux. Se non stai usando LVM, dovresti esserlo. Se lo sei, ecco un modo molto semplice per eseguire i backup tramite snapshot.

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

Ciò ti consentirà di effettuare backup notturni senza dover aggiungere un server slave. Sono molto favorevole ad avere un server slave per High Availability, ma non voglio che tu pensi che sei bloccato fino a quando non puoi creare quello slave.

FLUSH TABLES WITH READ LOCK non è qualcosa che vuoi fare su base regolare (o anche semi-regolare) su un sistema di produzione. Dovrebbe essere solo l'ultima risorsa.

Configurare almeno due slave di replica (ciò richiederà ovviamente un TAVOLO DI FLUSH CON READ LOCK). Una volta impostati, è possibile rimuovere un backup mentre l'altro rimane sincronizzato come master di riserva.

Inoltre, se uno dei tuoi schiavi fallisce, puoi usare un'istantanea da quello per ricostruire un secondo (o terzo) schiavo. Se tutti i tuoi schiavi falliscono, sei di nuovo a FLUSH TABLES WITH READ LOCK.

Ricorda di avere sempre un processo che controlla regolarmente che i dati siano sincronizzati - usa qualcosa come mk-table-checksum per fare questo (questo non è banale da configurare, consulta la documentazione di Maatkit per i dettagli).

Poiché 22 GB sono relativamente piccoli, non avrai problemi a farlo. Farlo con un database di grandi dimensioni potrebbe essere più problematico.

La soluzione qui è duplice, come descritto sopra:

1. Imposta la replica del tuo server su uno slave che puoi portare offline. Il modo migliore per farlo è prendere un dump del database usando mysqldump e il parametro --master-data.
2. Configurare backup notturni sullo slave. Puoi sia mysqldump utente con --master-data --flush-logs e --single-transazione flags, oppure puoi fermare il server mysql, copiare i file di dati su disco e riavviarlo (la replica verrà presa dove è stato interrotto).
3. Eseguire uno script sullo slave ogni (ad es. 5, 10, 20 minuti) per verificare e assicurarsi che mysql si stia ancora replicando. Ho scritto un semplice script Python per farlo, che puoi usare.

Nota che se stai usando InnoDB per le tue tabelle, puoi usare il flag --single-transazione per evitare di dover fare qualsiasi blocco delle tabelle e ottenere comunque un dump coerente del database, anche sul master, e quindi fare i tuoi backup senza smantellare il server. La soluzione di cui sopra, tuttavia, è migliore.

Inoltre, se si utilizza LVM su Linux, è possibile eseguire un'istantanea LVM della partizione, quindi eseguirne il backup. Le istantanee LVM sono atomiche, quindi se si esegue lo "svuotamento delle tabelle con blocco di lettura" e quindi si acquisisce e si sblocca, si otterrà un'istantanea coerente.

Se sei preoccupato che la contesa I / O richieda troppo tempo per il dump, puoi aggiungere una terza macchina ed eseguire mysqldump su quella rete per evitare il crash dei tuoi dischi.

A seconda del proprio ambiente, le istantanee sono in genere un modo eccellente di procedere. Soprattutto se è necessario eseguire il backup del master per qualche motivo. Eseguiamo coppie master e slave e utilizziamo backup di istantanee su entrambi.

1. FLUSH TABLES WITH READ LOCK;
2. Effettua uno snapshot sul database e registra i filesystem.
3. UNLOCK TABLES;
4. Copia i tuoi file di dati dall'istantanea a tuo piacimento.

Con le tabelle InnoDB, ti consigliamo di eseguire SET AUTOCOMMIT=0;prima di eseguire il blocco di lettura.

Dai un'occhiata a " Best practice per il backup di un database MySQL di produzione? ". È un post simile su StackTranslate.it.

Potresti fare un backup graduale. Eseguire il backup di 1/24 dei record ogni ora. L'unico problema con questo approccio è che se si blocca durante le prime ore del giorno, perderai qualsiasi cosa da quel momento al momento dell'incidente. Ad ogni modo, sono meno di 24 ore di record persi (non so quanto sia importante per te).