mysql binlog二進制日志詳解
2024-07-24 13:02:49
供稿：網友
基本概念
定義：
二進制日志包含了所有更新了數據或者已經潛在更新了數據（例如，沒有匹配任何行的一個DELETE）的所有語句。
作用：
1。二進制日志的主要目的是在恢復使能夠最大可能地更新數據庫，因為二進制日志包含備份后進行的所有更新。
2。二進制日志還用于在主復制服務器上記錄所有將發送給從服務器的語句。
不良影響：
運行服務器時若啟用二進制日志則性能大約慢1%。
如何啟動：
通過 –log-bin=file選項可以啟用
(更改my.ini文件)
日志位置
>>如果沒有指定文件名,則Mysql使用hostname-bin文件.
>>如果指定了相對路徑,則假定該路徑相對于數據目錄
>>Mysql在文件名后添加了數字索引.所以該文件最后的形式為filename.number
如果你在日志名中提供了擴展名(例如，–log-bin=file_name.extension)，則擴展名被悄悄除掉并忽略。
更換策略：
使用索引來循環文件,在以下條件將循環至下一個索引
1。服務器重啟
2。服務器被更新
3。日志到達了最大日志長度 max_binlog_size
4。日志被刷新 mysql> flush logs;
工具介紹：
shell>>mysqlbinlog [option] binlogFile> newfile
如： D:/mysql/log>mysqlbinlog binlog.000001 > 1.txt
一個例子：
log-bin=”D:/mysql/log/binlog” 那么，在該文件夾下就會有文件D:/mysql/log/binlog.000001等
常見問題
1.如何清除binlog
>>>使用下面的兩個命令
PURGE {MASTER | BINARY} LOGS TO ‘log_name' //log_name不會被清除
PURGE {MASTER | BINARY} LOGS BEFORE ‘date' //date不會被清除
實例如下：
mysql> purge master logs to ‘binlog.000004′;
Query OK, 0 rows affected (0.01 sec)
mysql> purge master logs before '2009-09-22 00:00:00′;
Query OK, 0 rows affected (0.05 sec)
>>>或使用命令
RESET MASTER
刪除之前所有的binlog，并重新生成新的binlog
后綴從000001開始
注：如果您有一個活性的從屬服務器，該服務器當前正在讀取您正在試圖刪除的日志之一，
則本語句不會起作用，而是會失敗，并伴隨一個錯誤。
不過，如果從屬服務器是休止的，并且您碰巧清理了其想要讀取的日志之一，則從屬服務器啟動后不能復制。
當從屬服務器正在復制時，本語句可以安全運行。您不需要停止它們。
2.記錄到二進制日志知的內容配置
binlog-do-db=sales 只記錄sales庫
binlog-ignore-db=sales 除sales庫不記錄，其他都記錄
但是如果在操作數據庫之前，不使用use $dbname 那么所有的SQL都不會記錄
如果使用了use $dbname,那么判斷規則取決于這里的$dbname，而不是SQL中操作的庫
3.二進制日志不準確的處理
默認情況下，并不是每次寫入時都將二進制日志與硬盤同步。因此如果操作系統或機器(不僅僅是MySQL服務器)崩潰，有可能二進制日志中最后的語句丟失。
要想防止這種情況，你可以使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使二進制日志在每N次二進制日志寫入后與硬盤同步。
即使sync_binlog設置為1,出現崩潰時，也有可能表內容和二進制日志內容之間存在不一致性。
如果崩潰恢復時MySQL服務器發現二進制日志變短了(即至少缺少一個成功提交的InnoDB事務)，
如果sync_binlog =1并且硬盤/文件系統的確能根據需要進行同步(有些不需要)則不會發生，則輸出錯誤消息 (“二進制日志<名>比期望的要小”)。
在這種情況下，二進制日志不準確，復制應從主服務器的數據快照開始。
