Risposte:
Se si desidera eseguire correttamente i backup di MySQL, senza tempi di inattività, è necessario replicare il database su un server di riserva. Non deve essere estremamente potente, deve solo far fronte al carico di scrittura del database principale. Non dovresti usare questo server in produzione. Se la replica non continua mai, è necessario un server più potente. È possibile verificare confrontando il file di registro e la posizione dall'output di
> SHOW MASTER STATUS\G
sul master e
> SHOW SLAVE STATUS\G
sullo schiavo. Penso che MySQL5 mostrerà il ritardo da SHOW SLAVE STATUS
.
Quando sei felice che il tuo schiavo stia al passo, puoi fare i tuoi backup facendo
SLAVE STOP;
sullo slavemysqldump --opt
sul server slave.SLAVE START;
sullo slaveSe lo fai, avrai un backup coerente dei tuoi database. Questo metodo impedisce la sincronizzazione di database diversi o, peggio, tabelle diverse nello stesso database e impedisce tempi di inattività bloccando le tabelle per le scritture mentre si esegue il backup.
Un bel vantaggio di questa configurazione è che hai una copia del tuo database che puoi usare per eseguire query lunghe e costose che non influiranno sul tuo servizio live.
Coppia di consigli casuali:
mysqldump --opt
, poiché di solito è il modo più veloce per importare l'SQL risultanteUso uno script che utilizza mysqldump
per estrarre i dati / lo schema in un file per ciascun database. Il backup dei dati viene eseguito dal normale backup di netbackup su nastro. Puoi ovviamente aggiungere ulteriori campane e fischietti ma questo fa un semplice dump di base.
#!/bin/sh
# Find out what databases are in mysql and back them up
# Delete old backups
STARTTIME=` date +%Y%m%d-%H%M `
#BACKUP_DIR="/usr/local/db_backups"
BACKUP_DIR="/var/local/db_backups"
LOGFILE="/var/log/db_backups.log"
USER="root"
PASSWD="<password>"
KEEP="7"
(
echo
echo " ---MySQL backups start ${STARTTIME} ---"
#delete any backup written more than ${KEEP} days ago
echo "Removing files over ${KEEP} days old from ${BACKUP_DIR}:"
/usr/bin/find ${BACKUP_DIR} -mindepth 1 -mtime +${KEEP} -print -delete
echo
echo "Performing today's dumps"
#find each database running in this instance of mysl
for DB in ` echo "show databases;"|mysql -u${USER} -p${PASSWD} mysql |awk " NR>1 {print $1} " `
do
#generate a backup file name based on the data base name
BACKUP_FILE="${BACKUP_DIR}/${DB}-${STARTTIME}.sql"
echo "Processing database ${DB} into file ${BACKUP_FILE}"
# dump the database data/schema into the backup file
mysqldump -u${USER} -p${PASSWD} --add-drop-table ${DB} > ${BACKUP_FILE}
gzip ${BACKUP_FILE}
done
ENDTIME=` date +%Y%m%d-%H%M `
echo
echo " ---MySQL backups complete ${ENDTIME} ---"
echo
) >> ${LOGFILE} 2>&1
Di solito viene eseguito il backup dei database una volta al giorno se devono essere arrestati, quindi i backup vengono trasferiti in un'area di archiviazione per il consolidamento, quindi passano al nastro.
I backup del database vengono eseguiti con gli strumenti nativi forniti con il motore di database per la maggior parte del tempo.
I backup non devono essere conservati sui server con i dati in caso di guasto hardware.
Si consiglia vivamente di avere repliche aggiornate dei server di database quando possibile, meglio avere un macanismo di failover per i database di produzione.
Per il software puoi ad esempio dare un'occhiata a bacula o zmanda
La nostra configurazione standard è un cluster HA con due database uno replicante all'altro che è di sola lettura.
Effettuiamo un backup completo una volta al giorno e quindi seguiamo una politica per cliente di eliminare i vecchi backup, in genere manteniamo 4 ultimi backup giornalieri (per sopravvivere al fine settimana;), 4 ultime domeniche e 4 ultime prime domeniche in un mese. Dopo una o due discariche all'anno, l'archivio verrà conservato per sempre.
Conserviamo anche i log di replica per il tempo che possiamo permetterci di risparmiare spazio su disco. Sono anche abbastanza utili come strumento di debug in quanto registrano esattamente chi ha cambiato cosa e quando.
Teoricamente tutto ciò che serve è un backup completo e tutti i log di replica per poter eseguire un ripristino temporizzato, ma backup completi più frequenti accelereranno il ripristino.
Un trucco accurato con il backup consiste nell'utilizzare le tabelle innodb e il parametro --single-transazione per il dump mysql, in questo modo il backup non bloccherà il database mentre è in esecuzione.
Sto usando Xtrabackup di Percona . è una soluzione di backup non bloccabile per InnoDB / XtraDB
L'intero scopo del backup è poter ripristinare.
Non vorrei sostenere un dump CSV come soluzione di backup; tutto ciò che ti darà sono i dati grezzi. C'è molto altro oltre a questo, in particolare con un database. Descrizioni delle tabelle, viste, processi memorizzati, il nome. Se non li possiedi, non sarai in grado di recuperarli con successo. C'è anche l'applicazione RDBMS e la configurazione da considerare. Potresti avere un gran numero di patch, che dovrai anche mettere nel tuo ambiente di recupero per portarlo allo stesso livello. È possibile che tu stia eseguendo una configurazione speciale dettata dai requisiti delle tue applicazioni. Potrebbe anche essere necessario un set specifico di impostazioni del sistema operativo necessarie affinché il database funzioni in modo ottimale. Tutti questi dovranno anche essere ripristinati e, a meno che non si disponga di una soluzione di backup in grado di eseguirli, si verificano ulteriori ritardi nei tempi di recupero,
Per i backup di database (e backup in generale) preferirei sempre utilizzare un software di backup "reale" in grado di gestirli tutti.
Più di recente, ho gestito i server MySQL in EC2. Abbiamo impostato le istantanee EBS su un processo cron di 15 minuti, sono state conservate 3-5 istantanee.
Quando eseguivamo server MySQL "tradizionali", eseguivamo quotidianamente il backup tramite MySQl-ZRM. I backup sono essenzialmente mysqldumps, che vengono inviati su nastro, SAN, ecc., A seconda delle esigenze del cliente.
Entrambi i metodi possono essere eseguiti senza arrestare il database.
Per MySQL uso automysqlbackup ( http://sourceforge.net/projects/automysqlbackup/ ), poiché il mio software di backup (Backup Exec) non supporta le istantanee sui sistemi Linux.
Funziona bene, ma ho intenzione di monitorare questo thread per suggerimenti :)
Eseguiamo backup due volte al giorno ed eseguiamo anche backup dei log ogni 10-15 minuti.
Il vantaggio di questo metodo è che è possibile ripristinare da uno dei backup due volte al giorno e quindi applicare i file di registro fino agli ultimi 15 minuti al massimo. In questo modo si sta riducendo al minimo la quantità di dati che si possono perdere.
Tuttavia, quanto spesso fai il backup dei tuoi dati. Quanti dati ti senti a tuo agio nel perdere? Se puoi permetterti di perdere un valore di un giorno di dati, esegui il backup una volta al giorno. I dati non cambiano mai? Quindi hai solo bisogno di una copia!