L'esecuzione di backup incrementali è un requisito importante per i database di produzione di grandi dimensioni. Senza un backup incrementale sicuro, non puoi dire a te stesso di avere un database di produzione affidabile. Perché è necessario disporre di dati sufficienti per recuperare il database in casi di emergenza. Dopo alcune ricerche su Internet, non sono riuscito a trovare alcuno strumento in grado di eseguire un backup incrementale completo per MyISAM e InnodB in un ambiente misto in cui le applicazioni utilizzano entrambi i motori di database contemporaneamente (forse non sono un ricercatore esperto su Google e Internet). Quindi ho deciso di scrivere questo, ma per evitare perdite di tempo e beneficiare di altre soluzioni open source, ho preferito aggiungere questa funzionalità a -automysqlbackup- script che è il miglior script per il backup completo in semplicità e utilizzo diffuso.
Meccanismo
Usiamo la funzionalità Post e Pre di automysqlbackup per eseguire un backup incrementale. Prima di avviare un backup completo, mysql-backup-pre esegue una query per bloccare l'intero database durante il processo di backup perché dobbiamo bloccare il binlog per evitare qualsiasi modifica durante l'esecuzione del backup. Il nome e la posizione del binlog potrebbero non cambiare durante il backup. La posizione del log binario è molto cruciale nel successivo processo di backup incrementale e verrà utilizzata come punto di partenza per iniziare il successivo backup incrementale. Al termine del backup completo, mysql-backup-post rimuove il blocco del database.
Query di blocco:LAVARE TABELLE CON BLOCCO LETTURA; SELEZIONA SONNO(86400)
Trova query di blocco:mysql -u[nome utente] -p[pass] -e "mostra elenco processi" | grep "SELEZIONA SONNO(86400)" | awk '{stampa $1}'
Requisiti
- privilegi di root per installare il pacchetto e aggiornare mysql.conf
- pacchetto mysql-community-client
- installazione automysqlbackup e mysql-incremental
Installazione
Installa il pacchetto mysql-community-client per la tua distribuzione.
Nota:dopo l'installazione di MySQL devi avere il comando 'mysqlshow'.
Installa automysqlbackup:
download the package from https://sourceforge.net/projects/automysqlbackup/
tar -xzf [PathYouSavedTarFile] -C /tmp/
cd /tmp/
./install.sh
Durante l'installazione di automysqlbackup, ti verrà chiesto del percorso di automysqlbackup.conf e del suo binario, puoi lasciare le impostazioni predefinite senza alcuna modifica.
rm /etc/automysqlbackup/myserver.conf
Installa mysql-incremental:scarica il pacchetto da https://sourceforge.net/projects/mysqlincrementalbackup/
cd /tmp
wget http://downloads.sourceforge.net/project/mysqlincrementalbackup/mysql-incremental.tar.gz
tar xfz mysql-incremental.tar.gz
cp mysql-incremental /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-incremental
cp mysql-backup-post /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-post
cp mysql-backup-pre /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-pre
Aggiorna automysqlbackup.conf:
Trova di seguito i parametri, decommenta e modificali:
CONFIG_mysql_dump_username='Mysql user name. It must has privileges to get Lock'
CONFIG_mysql_dump_password='Password'
CONFIG_backup_dir='The backup directory you want to store full and incremental backup'
CONFIG_db_names=('databaseName1' 'databaseName2' )
CONFIG_db_month_names=('databaseName1' 'databaseName2' )
CONFIG_mysql_dump_master_data=2
CONFIG_prebackup="/etc/automysqlbackup/mysql-backup-pre"
CONFIG_postbackup="/etc/automysqlbackup/mysql-backup-post"
Aggiorna mio.cnf:
Modifica il file di configurazione MySQL:
nano /etc/mysql/my.cnf
1- Formato BinLog
A causa di alcune limitazioni al formato STATEMENT, la mia raccomandazione è di impostare il formato basato su ROW. Per ulteriori informazioni, vedere la sezione "risoluzione dei problemi" in questo howto. Puoi controllare il tipo di formato del log binario eseguendo "select @@binlog_format;" interrogazione. Per modificare il formato logbin, devi aggiungere binlog_format =ROW a mysql.conf o my.cnf.
2- binlog_do_db
È necessario specificare i database per i quali si intende avere le relative modifiche nel log binario. Si noti che se non si specifica alcun database, qualsiasi modifica su qualsiasi database verrà registrata nel registro binario. In questo caso, se hai scelto il formato STATEMENT, potresti avere qualche problema durante il ripristino dal backup incrementale e dai file binlog. Puoi aggiungere database a questa opzione:
binlog_do_db = DATABASENAME1 binlog_do_db = DATABASENAME2
3- scade_logs_days
Per avere file di log binari più a lungo, puoi aumentare questo parametro a un valore più alto. La mia raccomandazione è di 60 giorni. Quindi devi aggiungerlo o modificarlo in "expire_logs_days =60".
4- log-bin
La directory in cui verranno archiviati i registri binari. Nelle vecchie versioni di MySQL, mysql-incremenetal potrebbe non essere in grado di trovare il percorso corretto. Quindi, se ricevi un errore dopo aver eseguito mysql-incremental, devi aggiornare lo script mysql-incremental e impostare il percorso del log binario.
5-log_slave_updates
Se stai configurando il backup incrementale mysql su un server slave, devi abilitare questa opzione. Normalmente, uno slave non registra gli aggiornamenti nel proprio log binario poiché sono stati ricevuti da un server master. Questa opzione dice allo slave di registrare gli aggiornamenti eseguiti dai suoi thread SQL nel proprio log binario. http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_log-slave-updates
Esegui automysqlbackup
Esegui manualmente automysqlbackup per avere almeno un backup completo dai database specificati.
automysqlbackup
Dopo aver eseguito correttamente il comando, controlla il file /[BackupDirInAutomysqlbackup]/status/backup_info per le informazioni appena aggiunte sul backup giornaliero. Per i dettagli sull'errore, controlla /var/log/Backup_Post_Pre_log . Il file di backup verrà archiviato nella directory /[BackupDirInAutomysqlbackup]/daily/[DatabaseName]/ .
Esegui mysql-incremental
Esegui ora manualmente mysql-incremental per avere almeno un backup orario.
mysql-incremental
In caso di errore, i dettagli vengono registrati nel file "/var/log/Backup_Incremental_Log" . I file di backup incrementali verranno archiviati nella directory /[BackupDirInAutomysqlbackup]/IncrementalBackup/ .
Modifica il crontab radice
Puoi programmare mysql-incremental per più di un'ora. Puoi trovare il tempo totale del backup completo da backup_status e quindi, in base a quel valore, impostare un tempo di pianificazione accurato. Ovviamente il backup incrementale mysql ha un meccanismo per trovare qualsiasi backup completo in esecuzione prima dell'inizio, quindi non c'è alcuna preoccupazione per il conflitto tra backup incrementale e completo.
crontab -e
5 00 * * * root /usr/local/bin/automysqlbackup 25 * * * * root /etc/automysqlbackup/mysql-incremental
Ripristina database
Per eseguire il ripristino fino a un periodo di tempo specifico (ripristino point in time), è necessario prima ripristinare un backup giornaliero completo e quindi ripristinare i file di backup incrementali correlati in sequenza. Per chiarire di più, ecco i passaggi per recuperare il database testDB. Nello scenario di esempio intendiamo recuperare i nostri dati fino al 01-5-2015 alle 2 del mattino. abbiamo impostato /backup come directory di backup principale e testDB come database di destinazione:
1- mysql -u root -p DatabaseName < /backup/daily/testDB/daily_DatabaseName_2015-05-16_00h05m_Saturday.sql.gz 2- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_00h25m.1 3- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_01h25m.2 4- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_02h25m.3
Note importanti e risoluzione dei problemi
MySQL supporta diversi formati per il log binario. Alcune versioni di Mysql utilizzano "basato su istruzioni" come formato binlog che questo tipo di binlog ha alcune limitazioni a cui dobbiamo prestare molta attenzione quando intendiamo usarlo nella procedura di backup incrementale. Quando mysql è impostato sul formato base delle istruzioni, non è in grado di filtrare correttamente in base ai database. Se si imposta 'USE o \u' per modificare il database e quindi si aggiorna un altro database che non è incluso in binlog-do-db, l'istruzione verrà registrata nel file binlog che non è lo stato desiderabile! ed esporrà alcuni problemi durante il ripristino in base a un database specifico e anche se si passa a un altro database che non è incluso in binlog-do-db e si aggiorna un database che è incluso in binlog-do-db, l'istruzione non verrà registrata su file binlog. il nostro scopo dall'aggiunta di database a binlog-do-db è quello di filtrare in base al database, ma non funziona come previsto. Se USE o \u non vengono eseguiti prima di eseguire le query, mysqlbinlog non può estrarre "query di aggiornamento" relative a un database. Spiegheremo meglio questo problema con gli scenari seguenti:
databases:
- binlog
- person (table)
- binlog2
- person (table)
binlog-do-db=binlog2 (it is supposed only change of this database are logged to binlog file)
--------Scenario 1---------
\u binlog2
insert into person (data) values ('17') ---> loged in binlog *desired state*
insert into binlog.person (data) values ('25'); ---> logged in binlog (target database is 'binlog' ) *undesired state*
--------Scenario 2---------
\u binlog
insert into person (data) values ('17') ---> is not logged in binlog *desired state*
insert into binlog2.person (data) values ('25'); ---> is not logged in binlog (target database is 'binlog2' ) *undesired state* because the binlog2 database
is begin changed, so we want to have this change,but it will not logged in logbin file
--------Scenario 3---------
if you just connect to database without any USE or \u statement, all of updates on any databases will be logged, but mysqlbinlog can not able to filter
based on specific database, so that is not desirable state for our purpose in incremental backup. Using USE or \u before executing update queries, is very
important. Because mysqlbinlog finds update queries based on USE statement in binlog file. Soluzione per il problema menzionato
1) Definendo gli utenti sui database in modo che ogni utente abbia accesso a un solo database da aggiornare (utente dell'applicazione) e quando si collega al database, deve essere specificato il nome del database. Ovviamente la maggior parte delle applicazioni ha un file di configurazione in cui sono impostate le credenziali e il nome del database, quindi in tal caso non avrai un accesso incrociato sui database e non ci saranno preoccupazioni sull'utilizzo di "\USE o \u ".
2) Se utilizzi il formato binlog basato su righe, tutti i problemi menzionati spariranno. in altre parole, il formato basato su righe è un metodo molto più appropriato per binlog. https://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html
File di registro
Ho provato a registrare tutto in un file di registro in modo da poter trovare informazioni sufficienti nei registri:
/var/log/Backup_Post_Pre_log
/var/log/Backup_Incremental_Log
/[SpecifiedBackupDirInAutomysqlbackup.conf]/status/backup_info
Il file "backup_info" contiene le informazioni dettagliate sul backup e quando il backup è terminato (gli orari sono in formato Unix Time). Contiene il nome del binlog e la posizione del momento in cui è iniziato il backup, il tipo di backup, il numero di backup dall'ultimo backup completo e la durata del backup.
Esempio di backup_info:
1431043501,mysql-bin.000026,120,Daily,2015-05-08,0,24 1431044701,mysql-bin.000026,120,Hourly,2015-05-08,1,1
Ecco la descrizione dei diversi valori:
1th) 1431043501 : indicates the time when the backup has been finished. You can run date --date @1431043501 command on the server the backup has been done to view it in human readable format. 2th) Mysql-bin.000026 : indicates the binary log name that backup up to this file has been done. 3th) 120 : indicates the position of binlog that backup up to this position in binary log has been done. 4th) Daily/Hourly: indicates type of backup. Daily does mean the full backup by automysqlbackup script and Hourly is done by mysql-incremental script. 5th) 2015-05-08: The date that backup has been done. This date will be used in creating directory for incremental backup and also as a base for restore hourly backups. In restoring procedure, first a full backup is restored and then sequentially other incremental backup are restored. 6th) 0 : indicates number of backups from previous full backup. 0 does mean the backup is full and others mean hourly. This number is very important in restoring procedure. 7th) 24: The backup duration in second.
Segnalazione di bug
Puoi segnalare bug o fornire suggerimenti e recensioni su https://sourceforge.net/projects/mysqlincrementalbackup .