mysql binlog二進制日記詳解。本站提示廣大學習愛好者：（mysql binlog二進制日記詳解）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql binlog二進制日記詳解正文
根本概念
界說：
二進制日記包括了一切更新了數據或許曾經潛伏更新了數據（例如，沒有婚配任何行的一個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而且硬盤/文件體系切實其實能依據須要停止同步(有些不須要)則不會產生，則輸入毛病新聞 (“二進制日記<名>比希冀的要小”)。
在這類情形下，二進制日記禁絕確，復制應從主辦事器的數據快照開端。
