1、binlog複製方式html
mysql複製主要有三種方式:基於SQL語句的複製(statement-based replication, SBR),基於行的複製(row-based replication, RBR),混合模式複製(mixed-based replication, MBR)。對應的,binlog的格式也有三種:STATEMENT,ROW,MIXED。mysql
① STATEMENT模式(SBR)sql
每一條會修改數據的sql語句會記錄到binlog中,slave在複製的時候sql進程會解析成master端執行過的相同的sql在slave庫上再次執行。數據庫
優勢:statement level下的優勢首先就是解決了row level下的缺點,不須要每一條sql語句和記錄每一行的變化,較少binlog日誌量,節約IO,提升性能。由於它只須要記錄在master上所執行的語句的細節,以及執行語句時候的上下文信息。緩存
缺點:因爲它是記錄執行語句,因此,爲了讓這些語句在slave端也能正確執行,那麼它還必須記錄每條語句在執行的時候的一些相關信息,也就是上下文信息,來保證全部語句在slave端可以獲得和在master端相同的執行結果。因爲mysql更新較快,使mysql的賦值遇到了不小的挑戰,天然賦值的時候就會涉及到越複雜的內容,bug也就容易出現。在statement level下,目前就已經發現了很多狀況會形成mysql的複製出現問題,主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現。好比:sleep()函數在有些版本中就不能正確賦值,在存儲過程當中使用了last_insert_id()函數,以及user-defined functions(udf)等,可能會使slave和master上獲得不一致的id等等。因爲row level是基於每一行記錄的裱花,因此不會出現相似的問題。tomcat
總結:安全
Statement level優勢:服務器
一、解決了row level的缺點,不須要記錄每一行的變化。多線程
二、日誌量少,節約IO,從庫應用日誌塊。併發
Statement level缺點:一些新功能同步可能會有障礙,好比函數、觸發器等。
② ROW模式(RBR)
不記錄每條sql語句的上下文信息,僅需記錄哪條數據被修改了,修改爲什麼樣了。並且不會出現某些特定狀況下的存儲過程、或function、或trigger的調用和觸發沒法被正確複製的問題。缺點是會產生大量的日誌,尤爲是alter table的時候會讓日誌暴漲。日誌中會記錄成每一行數據修改的形式,而後在slave端再對相同的數據進行修改。
優勢:在row level的模式下,binlog中能夠不記錄執行的sql語句的上下文信息,僅僅只須要記錄哪一條記錄被修改,修改爲什麼樣。因此row level的日誌內容會很是清楚的記錄每一行數據修改的細節,很是容易理解。並且不會出現某些特定狀況下的存儲過程,或fuction,以及trigger的調用或處罰沒法被正確複製的問題。
缺點:row level模式下,全部的執行語句都會記錄到日誌中,同時都會以每行記錄修改的來記錄,這樣可能會產生大量的日誌內容。
總結:
row level的優勢:
一、記錄詳細
二、解決statement level模式沒法解決的複製問題。
row level的缺點:日誌量大,由於是按行來拆分。
③ MIXED模式(MBR)
以上兩種模式的混合使用,通常的複製使用STATEMENT模式保存binlog,對於STATEMENT模式沒法複製的操做使用ROW模式保存binlog,MySQL會根據執行的SQL語句選擇日誌保存方式,也是在statement和row之間選擇一種。
新版本中的mysql中對row level模式也作了優化,並非全部的修改都會以row level來記錄,像遇到表結構變動的時候就會以statement模式來記錄,若是sql語句確實就是update或者delete等修改數據的語句,那麼仍是會記錄全部行的變動。
binlog複製配置
在mysql的配置文件my.cnf中,能夠經過一下選項配置binglog相關
binlog_format = MIXED //binlog日誌格式,mysql默認採用statement,建議使用mixed log-bin = /data/mysql/mysql-bin.log //binlog日誌文件 expire_logs_days = 7 //binlog過時清理時間 max_binlog_size = 100m //binlog每一個日誌文件大小 binlog_cache_size = 4m //binlog緩存大小 max_binlog_cache_size = 512m //最大binlog緩存大小
對於執行的SQL語句中包含now()這樣的時間函數,會在日誌中產生對應的unix_timestamp()*1000的時間字符串,slave在完成同步時,取用的是sqlEvent發生的時間來保證數據的準確性。另外對於一些功能性函數slave能完成相應的數據同步,而對於上面指定的一些相似於UDF函數,致使Slave沒法知曉的狀況,則會採用ROW格式存儲這些Binlog,以保證產生的Binlog能夠供Slave完成數據同步。
如今來比較如下 SBR 和 RBR 2中模式各自的優缺點:
SBR 的優勢:
歷史悠久,技術成熟
binlog文件較小
binlog中包含了全部數據庫更改信息,能夠據此來審覈數據庫的安全等狀況
binlog能夠用於實時的還原,而不只僅用於複製
主從版本能夠不同,從服務器版本能夠比主服務器版本高
SBR 的缺點:
不是全部的UPDATE語句都能被複制,尤爲是包含不肯定操做的時候。
調用具備不肯定因素的 UDF 時複製也可能出問題
使用如下函數的語句也沒法被複制:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啓動時啓用了 --sysdate-is-now 選項)
INSERT ... SELECT 會產生比 RBR 更多的行級鎖
複製須要進行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時,須要比 RBR 請求更多的行級鎖
對於有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 語句會阻塞其餘 INSERT 語句
對於一些複雜的語句,在從服務器上的耗資源狀況會更嚴重,而 RBR 模式下,只會對那個發生變化的記錄產生影響
存儲函數(不是存儲過程)在被調用的同時也會執行一次 NOW() 函數,這個能夠說是壞事也多是好事
肯定了的 UDF 也須要在從服務器上執行
數據表必須幾乎和主服務器保持一致才行,不然可能會致使複製出錯
執行復雜語句若是出錯的話,會消耗更多資源
RBR 的優勢:
任何狀況均可以被複制,這對複製來講是最安全可靠的
和其餘大多數數據庫系統的複製技術同樣
多數狀況下,從服務器上的表若是有主鍵的話,複製就會快了不少
複製如下幾種語句時的行鎖更少:
* INSERT ... SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒有附帶條件或者並無修改不少記錄的 UPDATE 或 DELETE 語句
執行 INSERT,UPDATE,DELETE 語句時鎖更少
從服務器上採用多線程來執行復製成爲可能
RBR 的缺點:
binlog 大了不少
複雜的回滾時 binlog 中會包含大量的數據
主服務器上執行 UPDATE 語句時,全部發生變化的記錄都會寫到 binlog 中,而 SBR 只會寫一次,這會致使頻繁發生 binlog 的併發寫問題
UDF 產生的大 BLOB 值會致使複製變慢
沒法從 binlog 中看到都複製了寫什麼語句
當在非事務表上執行一段堆積的SQL語句時,最好採用 SBR 模式,不然很容易致使主從服務器的數據不一致狀況發生
另外,針對系統庫 mysql 裏面的表發生變化時的處理規則以下:
若是是採用 INSERT,UPDATE,DELETE 直接操做表的狀況,則日誌格式根據 binlog_format 的設定而記錄
若是是採用 GRANT,REVOKE,SET PASSWORD 等管理語句來作的話,那麼不管如何都採用 SBR 模式記錄
注:採用 RBR 模式後,能解決不少原先出現的主鍵重複問題。
2、調整binlog日誌模式
binlog日誌默認模式:
Server version: 5.6.17 Source distribution
mysql> show variables like "%binlog_format%";
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.00 sec)
方法一:在線修改當即生效
mysql> set global binlog_format='MIXED';
Query OK, 0 rows affected (0.00 sec)
退出mysql,查看當前mysql日誌模式
mysql> show variables like "%binlog_format%";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
1 row in set (0.00 sec)
方法二:在配置文件中參數以下:
[mysqld]
log-bin=/var/lib/mysql/mysql-bin
#binlog_format="ROW"
binlog_format="MIXED" #開啓MIXED模式
#binlog_format="STATEMENT"
修改後重啓mysql服務日誌模式:
mysql> show variables like "%binlog_format%";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
1 row in set (0.00 sec)
MIXED(STATEMENT):
# at 193(開始位置)
#110708 10:03:06(時間截) server id(產生該事件的服務id) 1 end_log_pos(日誌的結束位置) 280 Query(事件類型) thread_id=10 exec_time=0 error_code=0
SETTIMESTAMP=1310090586/*!*/;
insert into tvalues(17)
/*!*/;
ROW模式:
BEGIN
/*!*/;
# at 174
# at 214
#110708 10:49:22server id 1 end_log_pos 214 Table_map: `test`.`t` mapped to number 14
#110708 10:49:22server id 1 end_log_pos 248 Write_rows: table id 14 flags: STMT_END_F
BINLOG '
MnAWThMBAAAAKAAAANYAAAAAAA4AAAAAAAEABHRlc3QAAXQAAQMAAQ==
MnAWThcBAAAAIgAAAPgAAAAAAA4AAAAAAAEAAf/+MgAAAA==
'/*!*/;
# at 248
#110708 10:49:22server id 1 end_log_pos 317 Query thread_id=1 exec_time=0 error_code=0
SETTIMESTAMP=1310093362/*!*/;
COMMIT
[root@i-3vsptbun mysql]# mysqlbinlog --base64-output=decode-rows -v mysql-bin.000011
小結:執行sql部分的sql顯示爲base64編碼格式
#171126 17:35:53 server id 1 end_log_pos 458 Table_map: `boy`.`tomcat1` mapped to number 15
#171126 17:35:53 server id 1 end_log_pos 571 Delete_rows: table id 15 flags: STMT_END_F
### DELETE FROM `boy`.`tomcat1`
### WHERE
### @1=11
### @2='huang1'
### DELETE FROM `boy`.`tomcat1`
### WHERE
### @1=2
### @2='huang2'
### DELETE FROM `boy`.`tomcat1`
### WHERE
### @1=3
### @2='huang3'
### @2='zhang7'
# at 571
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
每一個binlog的開始都是由4個字節:fe 62 69 6e,組成的魔數(後面三個字節就是bin)。
而後接下來的就是一條記錄的內容它包括:Common-Header,這部分不一樣版本的大小不同,4.0以上的都是19個字節。在這個以後就是BODY。
Common-Header格式:(單位:字節)
Timestamp(4) |
Type(1) |
Server_id(4) |
Total_size(4) |
End_log_pos(4) |
Flag(2) |
Timestamp:從1970開始
Type:此log event type如FORMAT_DESCRIPTION_EVENT、QUERY、LOAD_EVENT等,其中每一個binlog的第一條記錄的類型都是FORMAT_DESCRIPTION_EVENT,它記錄了該binlog的相關信息,如版本,這些信息對於後序分析binlog記錄是有用的,因此對於任務要讀取binlog的內容的工具都必須先讀取第一條記錄。QUERY包括咱們常常操做的如:create,drop,update,insert等。
Server_id:建立這個事件的server id。防止循環主從致使的主機被從寫。The master's server id (is preserved in therelay log; used to prevent from infinite loops in circular replication).
Total_size:該記錄的大小,包括common_header及body。
End_log_pos:此下一條記錄的開始位置。也是此條記錄結束位置的上一個字節。
Flag:標誌位。
QUERY類型的記錄:
QUERY類型的記錄除了開始的common-header以外,在body的開頭是一個Post-header,而後以後纔是真正的body內容。
Query Post-Header:(單位字節)
Thread_id(4) |
Exec_time(4) |
Db_len(1) |
Error_code(2) |
Status_var_len(2) |
Thread_id:is used to distinguish temporary tables that belong to differentclients.
Exec_time:The time from whenthe query started to when it was logged in the binlog, in seconds.QUERY到達到這個binlog事件生成的時間間隔。
Db_len:當前數據庫的名稱長度。
Error_code:執行出錯的錯誤號。