mysql binary mode_mysql二进制文件操作语法(mysql binary log operate statements)
在 mysql 配置文件中配置 log-bin，重啟 mysql
my.cnf (on Linux/unix) or my.ini (on Windows) 例子:
[client]
...
[mysqld]
...
log-bin=mysql-bin (log_bin=/var/mydb/bin-log，指定 log 的路徑，以及名稱前綴)
---
一旦重啟，Mysql 會自動創建新的二進制文件。您也不妨看看下面的變量：
server-id = 1
expire_logs_days = 4 (自動刪除 log 的天數，缺省值為 0，即不自動刪除)
sync_binlog = 1
查看 binary logs
登陸 MySQL 之后執行如下語句：
SHOW BINARY LOGS
等價
SHOW MASTER LOGS
返回值：
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 98 |
+------------------+-----------+
1 row in set (0.00 sec)
PURGE { BINARY | MASTER } LOGS
{ TO 'log_name' | BEFORE datetime_expr }
例子：
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
datetime_expr 參數格式為 YYYY-MM-DD hh:mm:ss。
上述語法，當從庫正在同步時，也可以安全運行。你不必要關閉從庫。如果你正在刪除一個從庫正在同步的 log，上述語句將不會做任何操作。MySQL 5.7.2 以及之后版本將會報錯。然而，如果你刪除了一個從庫沒有同步的 log，那么從庫將無法與主庫保持數據一致。
手動安全刪除日志的步驟：
在每一個從庫的 MySQL 上運行 SHOW SLAVE STATUS，檢驗從庫沒有從主庫讀取日志
使用命令 SHOW BINARY LOGS，查看主庫上的 binary log 文件
找出在從庫中時間最早的 log 文件，這是我們要刪除的目標文件。如果所有從庫都對同一個 log 與主庫保持同步，那么那個日志就是我們要刪除的目標文件
刪除之前，備份 log。(這一步是可選的，但是建議你這么做)
刪除目標文件之前的 log
可以通過設置 expire_logs_days 參數，自動刪除 log。
在調用上述刪除語句之前，log 已經被刪除，比如 linux 中使用 rm 命令，那么該語句將會報錯。
binary log 格式
binary log 會記錄所有與數據修改相關的操作，查詢不會被記錄哦。
比如我有如下的一些操作：
1. drop table student_information;
2. drop table student;
3. CREATE TABLE `student` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` char(20) NOT NULL,
`age` tinyint(2) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
4. insert student values(1,'zhangsan',20);
5. insert student values(1,'zhangsan',20);
6. insert student values(3,'wangwu',22);
通過命令將 binary log 轉為 SQL 腳本：
mysqlbinlog mysql-bin.000001 > my.sql
binary log 存儲內容為：
SET TIMESTAMP=1473842609/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1/*!*/;
SET @@session.sql_mode=1344274432/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
drop table student_information
/*!*/;
# at 193
#160914 16:43:35 server id 1 end_log_pos 276 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842615/*!*/;
drop table student
/*!*/;
# at 276
#160914 16:43:57 server id 1 end_log_pos 578 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842637/*!*/;
CREATE TABLE `student` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` char(20) NOT NULL,
`age` tinyint(2) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8
/*!*/;
# at 578
#160914 16:44:11 server id 1 end_log_pos 648 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842651/*!*/;
BEGIN
/*!*/;
# at 648
#160914 16:44:11 server id 1 end_log_pos 751 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842651/*!*/;
insert student values(1,'zhangsan',20)
/*!*/;
# at 751
#160914 16:44:11 server id 1 end_log_pos 778 Xid = 29
COMMIT/*!*/;
# at 778
#160914 16:44:19 server id 1 end_log_pos 848 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842659/*!*/;
BEGIN
/*!*/;
# at 848
#160914 16:44:19 server id 1 end_log_pos 947 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842659/*!*/;
insert student values(2,'lisi',21)
/*!*/;
# at 947
#160914 16:44:19 server id 1 end_log_pos 974 Xid = 30
COMMIT/*!*/;
# at 974
#160914 16:44:25 server id 1 end_log_pos 1044 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842665/*!*/;
BEGIN
/*!*/;
# at 1044
#160914 16:44:25 server id 1 end_log_pos 1145 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473842665/*!*/;
insert student values(3,'wangwu',22)
/*!*/;
# at 1145
#160914 16:44:25 server id 1 end_log_pos 1172 Xid = 31
COMMIT/*!*/;
# at 1172
#160914 17:31:33 server id 1 end_log_pos 1242 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473845493/*!*/;
BEGIN
/*!*/;
# at 1242
#160914 17:31:33 server id 1 end_log_pos 1348 Querythread_id=1exec_time=0error_code=0
SET TIMESTAMP=1473845493/*!*/;
update student set age = 100 where id = 1
/*!*/;
# at 1348
#160914 17:31:33 server id 1 end_log_pos 1375 Xid = 33
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
從語法上可以看出，如果是 update 操作恢復的概率相對要麻煩很多，需要對比操作。 SET TIMESTAMP 是操作的時間戳，這個相當有用，這樣就允許我們通過時間來確定重做的范圍。delete 以及 update 都被放置在事務里邊了，但是只有當整個 binary log 執行完成才算成功，任何一條語法的異常都會導致事務回滾，重做失敗。
直接重做 binary log 中的操作：
mysqlbinlog mysql-bin.000001 | mysql -u root -p
執行過程中發生異常就被被終止，所以在重做之前需要自己處理該文件，使得重做的動作是自己想要的。比如從上述 binary log 中有 drop table student_information 操作，而此時的數據庫中已經不存在該表，所以重做該步驟就會拋出異常信息。ERROR 1051 (42S02) at line 16: Unknown table 'student_information'
逐行查看 binary log 中內容：
mysqlbinlog mysql-bin.000001 | more
轉換 binary log 為 SQL 腳本：
mysqlbinlog mysql-bin.000001 > my.sql
重做 SQL 腳本：
mysql -u root -p < my.sql
如果你有多個 binary log 文件需要被執行，安全的方式是：將所有的 binary log 一次性執行。不安全方法的示例：
mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!
使用兩個不同連接處理 binary log 可能導致問題，有可能會發生如下情況：第一個 binary log 包含語法 CREATE TEMPOARY TEBLE 而第二個 binary log 使用到該臨時表。當第一個 binary log 執行完成將會刪除臨時表，那么第二個 binary log 需要使用到該臨時表的語句將報錯。
在一個連接中完成 binary logs 的處理，例子如下：
mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p
另外一種方法，將 binary logs 合并為一個 SQL 腳本：
mysqlbinlog binlog.000001 > /tmp/statements.sql
mysqlbinlog binlog.000002 >> /tmp/statements.sql
mysql -u root -p -e "source /tmp/statements.sql"
在讀取包含GTID的二進制日志時寫入轉儲文件(請參見第18.1.3節“使用全局事務標識符復制”)，在mysqlbinlog中使用--skip-gtids選項，如下所示：
mysqlbinlog --skip-gtids binlog.000001 > /tmp/dump.sql
mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
mysql -u root -p -e "source /tmp/dump.sql"
歡迎轉載，但請注明本文鏈接，謝謝你。
2016.9.14 19:08
總結
以上是生活随笔為你收集整理的mysql binary mode_mysql二进制文件操作语法(mysql binary log operate statements)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mysql同步binlog_利用MySQ
- 下一篇： centos6.8 安装mysql_Ce