MySQL InnoDB管理和備份二進制日志
㈠ 二進制日志的重要性
如果有某個時間點的數據備份和所有從那時以後的二進制日志
就可以重放自從上次全備以來的二進制日志並"前滾"所有的變更
㈡ 二進制日志配置的最佳實踐
對於 InnoDB 如果僅是啟用二進制日志是不夠、還需要其他措施來保證安全：
推薦配置如下：
● sync_binlog = 1
表示采用同步寫磁盤的方式來寫二進制日志、這時寫操作便繞開了OS的緩沖
該默認值為0
● innodb_support_xa = 1
確保二進制日志和InnoDB 數據文件的同步
㈢ 影響二進制日志備份策略的因素
如下圖：
㈣ 二進制日志的格式
二進制日志的粒度是事件、每個事件都有固定的事件頭、含：When、What、Who等
因其格式為二進制不可看、我們可借助 mysqlbinlog 查看其內容
下面是一個例子：
[plain]
[mysql@even data]$ mysqlbinlog -vv mysql-bin.000023
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#130515 12:35:29 server id 2 end_log_pos 107 Start: binlog v 4, server v 5.5.16-log created 130515 12:35:29 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
kRCTUQ8CAAAAZwAAAGsAAAABAAQANS41LjE2LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACREJNREzgNAAgAEgAEBAQEEgAAVAAEGggAAAAICAgCAA==
'/*!*/;
# at 107
#130515 12:37:47 server id 2 end_log_pos 255 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1368592667/*!*/;
SET @@session.pseudo_thread_id=3/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=0/*!*/;
SET @@session.auto_increment_increment=2, @@session.auto_increment_offset=2/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
alter database db_rocky character set = utf8mb4 COLLATE = utf8mb4_unicode_ci
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
這裡列了 2 個事件、來看第二個事件：
[plain]
# at 107
#130515 12:37:47 server id 2 end_log_pos 255 Query thread_id=3 exec_time=0 error_code=0
第一行表示該事件的起始位置：at 107
第二行包含如下幾項：
● 事件的日期和時間：130515 12:37:47
● 服務器 ID、這對於防止復制之間無限循環和其他問題是非常有必要的
● 下一個事件的開始位置：end_log_pos 255
注意了、該值通常是不正確的
因為、主庫會復制事件到一個緩沖區、但這樣做時
MySQL 並不知道下個日志事件的位置
● 事件類型、這裡是 Query
● 執行改事件的線程 ID、這點對審計蠻重要的
● 語句的時間戳和寫入二進制日志的時間差：exec_time
該值在復制落後的備庫上會有很大偏差
● 事件產生的錯誤代碼
㈤ 清除老的二進制日志的方法
不要用 rm 刪除日志、否則、將會導致 mysql-bin.index 狀態文件與磁盤上的不一致
應該用類似下面的 cron 命令：
[plain]
0 0 * * * /usr/bin/myql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"
