Come si esegue di solito il backup del database?


8

Sto usando mysql

Con quale frequenza si esegue il backup del database?

Come si esegue normalmente il backup del database?

Esporta tutti i dati in formato sql o cvs e conservali in una cartella ??

Risposte:


11

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

  1. Interrompere la replica con SLAVE STOP;sullo slave
  2. Fare un mysqldump --optsul server slave.
  3. Avviare nuovamente la replica con SLAVE START;sullo slave

Se 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:

  • Non essere tentato di eseguire un backup basato su file dei file di dati mysql. È più seccante di quanto valga e i dump MySQL sono più flessibili.
  • Attenzione alle tabelle di blocco di mysqldump durante il dumping.
  • Fai attenzione alle incoerenze nei dump a meno che non blocchi tutti i tavoli durante il dump
  • Utilizzare mysqldump --opt, poiché di solito è il modo più veloce per importare l'SQL risultante
  • Scarica il più spesso possibile. Scarichiamo quotidianamente perché abbiamo 40 GB + di dati.
  • Testa i tuoi dump su un server di riserva di tanto in tanto per assicurarti che funzionino.

2
Seconds_Behind_Master da SHOW SLAVE STATUS è disponibile in 4.1.9 e versioni successive.
Dan Carley,

+1 su replica e dump regolari. Ho trovato relativamente indolore iniziare a lavorare la prima volta (senza molta esperienza mysql precedente). Non sono pienamente d'accordo sui backup dei file, se hai lo spazio per fare entrambi allora, il backup basato su file sarà più facile da ricostruire un nuovo server se il tuo server database aspira, i singoli dump sql per ciascun database saranno più utile se è necessario ripristinare i dati persi.
theotherreceive il

3

Uso uno script che utilizza mysqldumpper 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

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


1

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.



1

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.


0

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.



0

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!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.