Mysql13 複製2，mysql13複製2

Mysql13 複製2，mysql13複製2
複製管理監控

SHOW MASTER LOGS;
查看主庫當前有哪些二級制日誌，其logname是其他命令的入參， file_size是位移量也是入參。

假設我們知道日誌的位移量(來源於上面的命令)使用：
SHOW BINLOG EVENTS IN ‘mysql-bin.0000023’ FROM 13634;
能查看最後執行的sql語句。

測量備庫延遲

SHOW SLAVE STATUS命令，但是會有問題：

• 使用伺服器當前日期，與二進位檔案中的時間時間戳記進行對別的
• 大事件會導致延遲波動
  更好的解決辦法是使用heart record.這是一個主庫上會每秒更新一次的時間戳記。

確認主備是否一致

pt-table-checksum檢查主備是否一致的工具

從主庫重新同步備庫

移除備庫，重新同步一個出來
使用mysqldump命令。 這個命令需要鎖住表之後再操作
pt-table-sync工具

改變主庫

計劃內

計劃外
這種會面臨，主庫資料丟失， 不同步。 備庫間也不同步

複製問題資料損毀或者丟失

主庫意外宕機
如果沒有設定sync_binlog，那麼有一定的可能崩潰前幾個二進位日誌沒有刷進磁碟。 重啟之後備庫線程再次連上來。主庫會告訴他位移量不存在。
解決方式是，讓備庫從下一個二進位日誌的開頭讀，然後用工具查看主備一致性。 或者開啟sync_binlog避免丟失，但是會帶來效能損失
。。。 還有很多，具體的不贅述了

使用非事務型表

要保證主庫重啟前，運行了STOP SLAVE否則有可能資料不一致。

不確定語句

主要是基於語句的複製，這個開發的時候就要注意。考慮到有可能產生這種現象的原因。

使用唯一的伺服器IDInnoDB加鎖讀引起的鎖爭用

INSERT… SELECT操作會引起讀鎖，會使序列化。
可以拆分成小命令
使用SELECT INTO OUTFILE,, LOAD DATA INFILE代替INSERT..SELECT.更快，不加鎖。

過大的複寫延遲

注意，應用設計上要允許出現延遲
延遲一般都是突然出現的很不好監測

可以用些手段來提升備庫的效能：

• 發現延遲之後如果開啟了log_slows_slave_statements可以查看問題
• 關閉備庫二進位日誌
• 設定重新整理磁碟的點innodb_flush_log_at_trx_commit
• 不重複寫操作中代價較高的部分
  比如一個更新統計表的操作，可以最佳化為。在主庫中建立一個庫。統計結構更新這個庫。然後用SELECT INTO OUTFILE和LOAD DATA INFILE來寫回主庫。這樣就不會再備庫同步執行這個操作
  基於同樣的思想，還可以把這部分操作放到應用程式層面來做統計，然後應用程式層顯示調用更新資料庫操作。
• 在複製之外進行操作 主要是解決了備庫是串列的問題
  常見的有兩種，一種是歸檔型資料庫。歸檔操作進位歸檔操作記錄到二進位檔案中，然後在主庫和備庫上單獨執行這些歸檔查詢
  還可以對一些特殊的表單獨處理。 使用應用程式手工的方式來處理這些標的同步。這樣可能會帶來資料效能的提升。

主備庫 包大小配置不一致

如果主備的 max_allowed_packet 不匹配，有可能主庫傳來過大的包。 可能造成報錯或者日誌損壞等等。

頻寬不足

可以通過開啟備庫的 slave_compressed_protocol選項，來讓傳輸時對資料進行壓縮及解壓。

複製速度

測試：

INSERT INTO lag_test(now_usec) VALUES (NOW_USEC())//要保證主從庫時間同步// 注意庫必須是varchar列，因為時間列的精確度可能是到秒

然後使用TIMESTAMPDIFF方法來查詢時間差異
可以插入1000比輸入，然後根據數量級進行分組，或者求下平均值。看下一般的延遲是多久
一般情況下都是在0.幾毫秒以內

一些進階特性

• 5.1引入了行複製
• 5.5引入了半同步。
  在提交食物後，返回給用戶端結果前保證二進位日誌傳輸到了至少一台備庫上，這樣就能更好的保證主從同步。但是會給用戶端事務提交的時間延遲一點點。半同步還會有一點點效能改善，因為有半同步，可以更大膽的關閉bin-log。本地寫磁碟轉化為遠程寫記憶體。事實證明遠程寫記憶體更快。
• 5.5還增加了複製心跳監測
• 5.6引入了並行複製，對部分平行處理

其他複製行為

Percona Toolkit和Percona Xtrabackup都提供了基於複製或者協助複製的功能
Tungsten Java的開源中介軟體複製產品。提供了自動資料分區，並發執行，資料複製，款平台複製，多源複製等功能。 他很實用，一些優點：
- 內建一致性檢查
- 外掛程式特性
- 全域事務ID，不用再去匹配日致命和位移量了
- 能快速的將備庫提升為主庫
- 異構複製 比如Mysql到PostgreSQL
- 不同版本之間
- 並行
缺點則是要學習，更複雜，效率稍低。

總結一下：

• 顯著增加了Mysql的功能和可用性
• 不提供監控，配置，管理等功能，可以使用其他管局最佳化，比如：Percona Toolkit和XtraBackup
• 複製配置前需要用上面的工具來進行對比，確認是考慮
• 監控不會落後於主庫
• 應用設計要避免主備延遲的髒資料情況
• 備庫制度並且增加許可權，不要多處寫。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。