Inkrementální zálohování MySQL – bodové zálohování a obnova databází InnoDB a MyIsam

Provádění přírůstkových záloh je důležitým požadavkem pro velké produkční databáze. Bez bezpečného přírůstkového zálohování si nemůžete říct, že máte spolehlivou produkční databázi. Protože k obnovení databáze v nouzových případech musíte mít dostatek dat. Po nějakém hledání na internetu jsem nenašel žádný nástroj, který by dokázal udělat kompletní inkrementální zálohu pro MyISAM a InnodB ve smíšeném prostředí, kde aplikace používají oba databázové stroje současně (možná nejsem expert na vyhledávání na Googlu a internetu). Rozhodl jsem se tedy napsat tento, ale abych neztrácel čas a těžil z jiných open-source řešení, raději jsem tuto funkci přidal do skriptu -automysqlbackup-, což je nejlepší skript pro úplné zálohování v jednoduchosti a širokém použití.

Mechanismus

K provádění přírůstkové zálohy používáme funkci Post- and Pre Automysqlbackup. Před spuštěním úplného zálohování provede mysql-backup-pre dotaz k uzamčení celé databáze během procesu zálohování, protože musíme zmrazit binlog, abychom předešli jakékoli změně během zálohování. Název a pozice binárního protokolu se během zálohování nemusí změnit. Pozice binárního protokolu je velmi zásadní v procesu následného přírůstkového zálohování a bude použita jako výchozí bod pro zahájení dalšího přírůstkového zálohování. Po dokončení úplné zálohy mysql-backup-post odstraní zámek databáze.

Dotaz na zámek:VYPLACHUJTE TABULKY SE ZÁMEKEM ČTENÍ; VYBERTE SLEEP(86400)

Najít dotazy na zámek:mysql -u[uživatelské jméno] -p[pass] -e "zobrazit seznam procesů" | grep "SELECT SLEEP(86400)" | awk '{print $1}'

Požadavky

• práva root pro instalaci balíčku a aktualizaci mysql.conf
• balíček mysql-community-client
• instalace automysqlbackup a mysql-incremental

Instalace

Nainstalujte si balíček mysql-community-client pro své distro.

Poznámka:Po instalaci MySQL musíte mít příkaz 'mysqlshow'.

Nainstalujte automysqlbackup:

stáhněte si balíček z https://sourceforge.net/projects/automysqlbackup/

tar -xzf [PathYouSavedTarFile] -C /tmp/

cd /tmp/

./install.sh

Během instalace automysqlbackup budete dotázáni na cestu k automysqlbackup.conf a jeho binárnímu souboru, výchozí hodnoty můžete ponechat beze změny.

rm /etc/automysqlbackup/myserver.conf

Nainstalujte mysql-incremental:Stáhněte si balíček z 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

Aktualizujte soubor automysqlbackup.conf:

Najděte níže parametry, odkomentujte je a změňte je:

 CONFIG_mysql_dump_username='Uživatelské jméno Mysql. Musí mít oprávnění k získání zámku' CONFIG_mysql_dump_password='Heslo' CONFIG_backup_dir='Adresář zálohy, do kterého chcete uložit plnou a přírůstkovou zálohu' CONFIG_db_names=('databaseName1' 'databaseName2' ) CONFIG_medb_2database' ) CONFIG_medb_2database's=databáze_databáze_měsíc_data_data's) 2 CONFIG_prebackup="/etc/automysqlbackup/mysql-backup-pre" CONFIG_postbackup="/etc/automysqlbackup/mysql-backup-post"

Aktualizovat soubor my.cnf:

Upravte konfigurační soubor MySQL:

nano /etc/mysql/my.cnf

1- Formát BinLog

Vzhledem k určitému omezení formátu STATEMENT je mým doporučením nastavit formát založený na řádcích. Další informace naleznete v části „Odstraňování problémů“ v tomto návodu. Typ formátu binárního protokolu můžete zkontrolovat spuštěním "select @@binlog_format;" dotaz. Chcete-li upravit formát přihlášení , musíte do souboru mysql.conf nebo my.cnf přidat binlog_format =ROW.

2- binlog_do_db

Musíte zadat databáze, u kterých chcete mít související změny v binárním protokolu. Upozorňujeme, že pokud neurčíte žádnou databázi, jakákoliv změna v jakékoli databázi bude zaznamenána do binárního protokolu. V tomto případě, pokud zvolíte formát STATEMENT, možná budete mít potíže při obnově z přírůstkové zálohy a souborů binlog. K této možnosti můžete přidat databáze:

binlog_do_db =DATABASENAME1binlog_do_db =DATABASENAME2

3- expire_logs_days

Chcete-li mít binární soubory protokolu delší dobu, můžete tento parametr zvýšit na vyšší hodnotu. Moje doporučení je 60 dní. Musíte jej tedy přidat nebo změnit na „expire_logs_days =60“.

4- log-bin

Adresář, do kterého budou uloženy binární protokoly. Ve starých verzích MySQL nemusí být mysql-incremenetal schopen najít správnou cestu. Pokud se vám tedy po provedení mysql-incremental zobrazí chyba, musíte aktualizovat skript mysql-incremental a nastavit cestu k binárnímu protokolu.

5- log_slave_updates

Pokud nastavujete přírůstkové zálohování mysql na podřízeném serveru, musíte tuto možnost povolit. Normálně podřízená jednotka nezaznamenává aktualizace do svého vlastního binárního protokolu, protože byly přijaty z hlavního serveru. Tato volba říká podřízenému zařízení, aby protokoloval aktualizace provedené jeho vlákny SQL do vlastního binárního protokolu. http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_log-slave-updates

Spustit automysqlbackup

Spusťte automysqlbackup ručně, abyste měli alespoň jednu úplnou zálohu ze zadaných databází.

automysqlbackup

Po úspěšném provedení příkazu zkontrolujte v souboru /[BackupDirInAutomysqlbackup]/status/backup_info nově přidané informace o denní záloze. Podrobnosti o chybě naleznete ve /var/log/Backup_Post_Pre_log . Záložní soubor bude uložen v adresáři /[BackupDirInAutomysqlbackup]/daily/[DatabaseName]/.

Spustit mysql-incremental

Spusťte mysql-incremental ručně nyní, abyste měli alespoň jednu hodinovou zálohu.

mysql-incremental

V případě chyby se podrobnosti zaprotokolují do souboru „/var/log/Backup_Incremental_Log“ . Soubory přírůstkové zálohy budou uloženy v adresáři /[BackupDirInAutomysqlbackup]/IncrementalBackup/.

Upravit kořenový crontab

Mysql-incremental můžete naplánovat na více než jednu hodinu. Celkovou dobu plné zálohy můžete najít v backup_status a na základě této hodnoty pak nastavíte přesný čas plánování. Přírůstková záloha mysql má samozřejmě mechanismus, který před spuštěním najde jakoukoli běžící plnou zálohu, takže se nemusíte obávat konfliktu mezi přírůstkovou a plnou zálohou.

crontab -e

5 00 * * * root /usr/local/bin/automysqlbackup25 * * * * root /etc/automysqlbackup/mysql-incremental

Obnovit databázi

Chcete-li obnovit až do určitého času (obnovení v určitém okamžiku), musíte nejprve obnovit jednu úplnou denní zálohu a poté obnovit postupně související soubory přírůstkové zálohy. Chcete-li objasnit více, zde jsou kroky k obnovení databáze testDB. V ukázkovém scénáři máme v úmyslu obnovit naše data do 2015-5-01 do 2:00. nastavili jsme /backup jako hlavní záložní adresář a testDB jako naši cílovou databázi:

1- mysql -u root -p Název databáze  
Důležité poznámky a odstraňování problémů
 

 MySQL podporuje různé formáty binárního protokolu. Některé verze Mysql používají 'statement-based' jako formát binlogu, že tento typ binlogu má určitá omezení, kterým musíme věnovat velkou pozornost, když ho zamýšlíme použít v postupu přírůstkového zálohování. Když je mysql nastaven na formát příkazové báze, není schopen správně filtrovat na základě databází. Pokud nastavíte 'USE nebo \u' pro změnu databáze a poté aktualizujete jinou databázi, která není zahrnuta v binlog-do-db, bude do souboru binlog zaznamenáno prohlášení, že to není žádoucí stav! a odhalí určitý problém při obnově na základě konkrétní databáze a také pokud přejdete na jinou databázi, která není zahrnuta v binlog-do-db, a aktualizujete databázi, která je zahrnuta v binlog-do-db, příkaz nebude přihlášen soubor binlog. naším účelem při přidávání databází do binlog-do-db je filtrovat na základě databáze, ale nefunguje to podle očekávání. Pokud se USE nebo \u nespustí před spuštěním dotazů, mysqlbinlog nemůže extrahovat 'aktualizační dotazy' týkající se jedné databáze. Více tento problém vysvětlíme pomocí níže uvedených scénářů:
 
databáze:- binlog - osoba (tabulka) - binlog2 - osoba (tabulka) binlog-do-db=binlog2 (předpokládá se, že do souboru binlog se zapisují pouze změny této databáze)--------Scénář 1---------\u binlog2insert into person (data) values ​​('17') ---> loged in binlog *deired state*insert into binlog.person (data) values ​​('25'); ---> přihlášen binlog (cílová databáze je 'binlog') *nežádoucí stav*--------Scénář 2---------\u binloginsert into person (data) values ​​('17 ') ---> není přihlášen v binlogu *požadovaný stav*vložte do binlog2.person (data) hodnoty ('25'); ---> není přihlášen v binlogu (cílová databáze je 'binlog2' ) *nežádoucí stav*, protože databáze binlog2 se začíná měnit, takže tuto změnu chceme provést, ale nebude přihlášen do logbin souboru ------ --Scénář 3---------pokud se jen připojíte k databázi bez jakéhokoli příkazu USE nebo \u, budou protokolovány všechny aktualizace všech databází, ale mysqlbinlog nemůže filtrovat na základě konkrétní databáze, takže to není žádoucí stav pro náš účel v přírůstkovém zálohování. Použití USE nebo \u před provedením aktualizačních dotazů je velmi důležité. Protože mysqlbinlog najde aktualizační dotazy na základě příkazu USE v souboru binlog.
 
Vyřešit zmíněný problém
 

 1) Definováním uživatelů na databázích tak, že každý uživatel má přístup pouze k jedné databázi k aktualizaci (uživatel aplikace) a při připojení k databázi musí být uveden název databáze. Většina aplikací má samozřejmě konfigurační soubor, ve kterém jsou nastaveny přihlašovací údaje a název databáze, takže v takovém případě nebudete mít křížový přístup k databázím a nebudete mít obavy z použití "\USE nebo \u ".
." 

 2) Pokud používáte formát binlogu založeného na řádcích, všechny zmíněné problémy budou pryč. jinými slovy, řádkový formát je mnohem vhodnější metodou pro binlog. https://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html
 
Soubory protokolu
 

 Snažil jsem se vše zapsat do souboru protokolu, abyste v protokolech našli dostatek informací:
 

 /var/log/Backup_Post_Pre_log
/var/log/Backup_Incremental_Log
/[SpecifiedBackupDirInAutomysqlbackup.conf]/status/backup_info
 

 Soubor "backup_info" obsahuje podrobné informace o záloze a kdy byla záloha dokončena (Časy jsou ve formátu Unix Time). Obsahuje název binlogu a pozici časového bodu, kdy zálohování začalo, typ zálohy, počet záloh od poslední úplné zálohy a dobu trvání zálohy.
 

 Ukázka backup_info:
 
1431043501,mysql-bin.000026,120,Daily,2015-05-08,0,241431044701,mysql-bin.000026,120,Hodinově,2015-05-08,1,1 

 Zde je popis různých hodnot:
 
 1.) 1431043501 :označuje čas, kdy byla záloha dokončena. Na serveru, na kterém byla provedena záloha, můžete spustit příkaz date --date @1431043501 a zobrazit jej ve formátu čitelném pro člověka. 2.) Mysql-bin.000026 :označuje název binárního protokolu, jehož záloha do tohoto souboru byla provedena. 3.) 120 :označuje pozici binlogu, kdy byla provedena záloha do této pozice v binárním protokolu. 4.) Denně/Hodinově:označuje typ zálohy. Denní znamená úplné zálohování pomocí skriptu automysqlbackup a hodinové se provádí pomocí přírůstkového skriptu mysql. 5.) 2015-05-08:Datum, kdy byla záloha provedena. Toto datum bude použito při vytváření adresáře pro přírůstkové zálohování a také jako základ pro obnovení hodinových záloh. V proceduře obnovy se nejprve obnoví plná záloha a poté se postupně obnoví další přírůstková záloha. 6.) 0 :označuje počet záloh z předchozí plné zálohy. 0 znamená, že záloha je plná a ostatní znamenají každou hodinu. Toto číslo je velmi důležité v procesu obnovy. 7.) 24:Doba trvání zálohy v sekundách.
 
Hlášení o chybě
 

 Můžete nahlásit chyby nebo poskytnout své návrhy a recenze na https://sourceforge.net/projects/mysqlincrementalbackup .