MySQL增量備份與恢復實例

小量的數據庫能夠天天進行完整備份,由於這也用不了多少時間,但當數據庫很大時,就不太可能天天進行一次完整備份了,這時候就可使用增量備份。增量備份的原理就是使用了mysql的binlog日誌。
本次操做的MySQL版本爲5.5.40 for Linux (x86_64)mysql

增量備份要確保打開了二進制日誌,參考mysql的日誌系統sql

mysql> show variables like '%log_bin%';

首先對pak數據庫作一個完整備份:數據庫

$ mysqldump -h localhost -upak -ppwd -P3306 --master-data=2 --single-transaction --opt pak > pak_bak_full.sql

這時候就會獲得一個全備文件pak_bak_full.sql。mysqldump操做會致使滾動一次log,假設新的binlog文件是mysql-bin.000002。服務器

模擬插入數據和誤操做編碼

a. 在pak庫的某個表插入一些數據,而後執行flush logs命令。這時將會產生一個新的二進制日誌文件mysql-bin.000003,mysql-bin.000002則保存了全備事後的全部更改,既增長記錄的操做也保存在了mysql-bin.00002中。日誌

b. 再在pak庫中的t_user表中增長兩條記錄,而後誤刪除t_user表。t_user中增長記錄的操做和刪除表的操做都記錄在mysql-bin.000003中。code

開始恢復server

恢復過程不要記錄日誌:rem

mysql > set global sql_log_bin=0;

首先導入全備數據get

$ mysql -h localhost -upak -ppwd < pak_bak_full.sql
或
mysql> source /path/backup/pak_bak_full.sql

咱們也能夠看到全備時的binlog位置:

head -50 backup-file.sql |grep 'CHANGE MASTER'
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=4321;

查看當前所在二進制日誌中的位置:

mysql> show master status;

根據上面兩個position能大概肯定須要完整恢復哪幾個binlog文件。

恢復mysql-bin.000002
在待恢復的position或時間點之前、全備之後的binlog須要所有恢復,多個文件以空格隔開

$ mysqlbinlog /var/lib/mysql/mysql-bin.000002 | mysql -uroot -p

此時查詢能夠獲得前兩條數據。

恢復部分mysql-bin.000003
這個日誌中包括了新增記錄和誤刪表兩個部分,咱們須要恢復到新增記錄以後、誤刪操做之前的位置。

若是知道誤操做的命令如DROP TABLE,則能夠經過下面的方法在binlog文件中找到誤操做以前的那個position:
(以下面的信息顯示,誤操做DROP TABLE以前的pos是775,在datetime 141204 15:08:04或pos 882時完成DROP TABLE操做)

$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 |grep -C 5 'DROP TABLE'
#141204 15:07:05 server id 1  end_log_pos 775   Xid = 376
COMMIT/*!*/;
# at 775
#141204 15:08:04 server id 1  end_log_pos 882   Query   thread_id=10    exec_time=0 error_code=0
SET TIMESTAMP=1417676884/*!*/;
DROP TABLE `t_user` /* generated by server */
/*!*/;
# at 882

恢復命令:

$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-position=775 | mysql -h localhost -uroot -p

若是position難以肯定,但知道須要恢復到的確切(服務器)時間,也可使用datetime:

$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-datetime="2014-12-04 15:08:00" | mysql -uroot -p

若是不是誤操做致使的,而是遷移數據庫,那麼不須要position或datetime,使用全部binlog文件增量恢復便可。

肯定恢復成功後記得打開日誌記錄:

mysql > set global sql_log_bin=1;

報錯
1. unknown variable 'default-character-set=utf8'
在使用mysqlbinlog查看二進制日誌的時候,提示下面的錯誤:

/usr/local/mysql/bin/mysqlbinlog: unknown variable 'default-character-set=utf8'

緣由是在我爲了統一mysql客戶端到服務端的的字符編碼,在/etc/my.cnf文件的[client][mysqld]等節加入了default-character-set = utf8mysqlbinlog會從my.cnf中的[client]讀取配置,但奈何mysqlbinlog並不認識這個選項(聽說是個bug)致使的。

應對這個bug的方法有兩個:
第一,天然是註釋到[client]中的這個字符集配置;
第二,改用loose-default-character-set = utf8。在選項前加了loose-,表示當程序不認識此選項時會略過此選項,並給出一個警告。


原文連接地址:http://seanlook.com/2014/12/05/mysql_incremental_backup_example/

相關文章
相關標籤/搜索