MySQL DBA MySQL複製技術的變革(九)

複製環境搭建：基於ROW+GTID

statement格式複製不足及解決辦法

GTID用於解決什麼問題

半同步複製有什麼缺點？加強半同步用於解決什麼問題？半同步會不會有延遲？

複製的瓶頸點及改進建議

複製建議選擇

 

 

statement格式複製不足

理解binlog

記錄最小的單位是一個Event。前4個字節是magic number,接下來的19個字節記錄Format desc event：FDE

一個事務由多個Event組成

（hexdump mysql-bin.00000x |head -n 3）

now()取到的是set timestamp的值

sysdate()取到的是系統的時間

show binlog events in 'mysql-bin.00000x'

 

row格式，binlog每條語句都帶有庫名

statement是加use

 

row格式優勢

相對statement格式更加安全的複製格式

在某些狀況下複製速度更快(sql複雜，表有主鍵）

系統的特殊函數也能夠複製

更少的鎖

 

缺點

binary log比較大（支持binlog_row_image）

單條語句更新【刪除】表的行數過多，會造成大量的binlog

沒法從binlog看見用戶執行的sql（Event：binlog_row_query_log_events,記錄用戶的query)

 

uuid()結果太多離散，insert寫入慢

 

 GTID用於解決什麼問題

事務是由誰產生的，產生了多少事務，複製架構中求事務個數差集很是簡單

gtid_purged  --表示已通過期的日誌的位置

監控方便

 

半同步                                         

半同步複製有什麼缺點？

加強半同步用於解決什麼問題？

半同步會不會有延遲？

rpl_semi_sync_master_wait_point=after_commit

redo(xid)->binlog->redo commit（同時redo中寫入binlog filename，pos）

Xid同一個binlog是順序增加的

redo->Xid

業務層幻讀

引擎層已經commit，可是dump線程還未dump binlog時master crash，那麼主庫的數據就會比從庫多

 

 

 

 

加強半同步                                                                            

半同步複製有什麼缺點？

rpl_semi_sync_master_wait_point=after_sync

若是在dump線程還未dump binlog時master crash，那麼主庫重啓後的數據會比從庫多

幽靈事務--掉電狀況會發生

rpl_semi_sync_master_timeout

沒有從庫會hang住

https://bugs.mysql.com/bug.php?id=83158