7:基於語句和行復制的優缺點

每種二進制日誌格式都有優點和缺點。對於大多數用戶,混合複製格式提供了數據完整性和性能的最佳組合。但是,如果您希望在執行某些任務時利用特定於基於語句或基於行的複製格式的功能優勢,則可以使用本節中的信息,其中總結了它們的相對優點和缺點,以確定哪一個最適合您的需求

  1. 基於語句的複製的優點
    • 成熟的技術
    • 寫入日誌文件的數據較少。當更新或刪除影響許多行時,這會導致日誌文件所需的存儲空間大大減少。這也意味着從備份中獲取和恢復可以更快地完成。
    • 日誌文件包含進行任何更改的所有語句,因此可用於審覈數據庫。
  2. 基於語句的複製的缺點
    • Statements that are unsafe for SBR.並非所有修改數據的語句(例如INSERT DELETE,UPDATE和REPLACE語句)都可以使用基於語句的複製進行復制。使用基於語句的複製時,任何非確定性行爲都難以複製。此類數據修改語言(DML)語句的示例包括以下內容:
      • 依賴於UDF或不確定的存儲程序的語句,因爲這樣的UDF或存儲程序返回的值或取決於提供給它的參數以外的因素。(但是,基於行的複製只是複製UDF或存儲程序返回的值,因此它對錶行和數據的影響在master和slave上都是相同的。)更多信息請看 Section 16.4.1.16, “Replication of Invoked Features”
      • 不帶ORDER BY的LIMIT子句的DELETE和UPDATE語句是不確定的。更多信息請看Section 16.4.1.17, “Replication and LIMIT”.
      • 必須在slaves上應用確定性UDF
      • 使用基於語句的複製無法正確複製使用以下任何方法的語句:
        • LOAD_FILE()
        • UUID(), UUID_SHORT()
        • USER()
        • FOUND_ROWS()
        • SYSDATE() (unless both the master and the slave are started with the --sysdate-is-now option)
        • GET_LOCK()
        • IS_FREE_LOCK()
        • IS_USED_LOCK()
        • MASTER_POS_WAIT()
        • RAND()
        • RELEASE_LOCK()
        • SLEEP()
        • VERSION()
      • 但是,使用基於語句的複製(包括NOW()等)可以正確複製所有其他函數。更多信息請看Section 16.4.1.15, “Replication and System Functions”.
      • 使用基於語句的複製無法正確複製的語句將記錄如下所示的警告
      • [Warning] Statement is not safe to log in statement format.
      • 在這種情況下,也會向客戶端發出類似的警告。 客戶端可以使用SHOW WARNINGS顯示它
    • INSERT ... SELECT需要比基於行的複製更多的行級鎖
    • 需要進行表掃描的UPDATE語句(因爲WHERE子句中沒有使用索引)必須鎖定比基於行的複製更多的行
    • 對於InnoDB:使用AUTO_INCREMENT的INSERT語句會阻止其他非衝突的INSERT語句
    • 對於複雜語句,必須在更新或插入行之前在slave上評估和執行該語句。對於基於行的複製,slave只需修改受影響的行,而不是執行完整語句。
    • 如果在對slave的評估中出現錯誤,特別是在執行復雜語句時,基於語句的複製可能會隨着時間的推移逐漸增加受影響行的誤差範圍,更多信息請看Section 16.4.1.28, “Slave Errors During Replication
    • 存儲函數執行時與調用語句的NOW()值相同。但是,存儲過程不是這樣的。
    • 表定義在master和slave上必須(幾乎)相同。更多信息請看Section 16.4.1.10, “Replication with Differing Table Definitions on Master and Slave”
  3. 基於行的複製的優點
    • 可以複製所有更改。 這是最安全的複製形式。
      • 注意:
        • 更新mysql數據庫中的信息的語句(如GRANT,REVOKE和觸發器操作,存儲的例程(包括存儲過程)和視圖)都使用基於語句的複製複製到slave上
        • 對於諸如CREATE TABLE ... SELECT之類的語句,將從表定義生成CREATE語句並使用基於語句的格式進行復制,而行插入使用基於行的格式進行復制。
        • 對於以下類型的語句,master上需要更少的行鎖,從而實現更高的併發性
    • 對於以下類型的語句,master上需要更少的行鎖,從而實現更高的併發性
      • INSERT ... SELECT
      • INSERT statements with AUTO_INCREMENT
      • UPDATE or DELETE statements with WHERE clauses that do not use keys or do not change most of the examined rows.
    • 對於任何INSERT,UPDATE或DELETE語句,slave需要更少的行鎖。
  4. 基於行的複製的缺點
    • RBR會生成更多必須記錄的數據。要複製DML語句(例如UPDATE或DELETE語句),基於語句的複製僅將語句寫入二進制日誌。相比之下,基於行的複製將每個更改的行寫入二進制日誌。如果語句更改了許多行,則基於行的複製可能會將更多數據寫入二進制日誌; 即使對於回滾的語句也是如此。這也意味着製作和恢復備份可能需要更多時間。此外,二進制日誌被鎖定較長時間來寫入數據,這可能會導致併發問題。使用binlog_row_image = minimal來顯著減少缺點。
    • 與基於語句的複製相比,使用基於行的複製生成大型BLOB值的確定性UDF需要更長的時間來複制。這是因爲記錄了BLOB列值,而不是生成數據的語句。
    • 您無法在slave上看到從master接收和執行的語句。但是,您可以使用mysqlbinlog以及--base64-output = DECODE-ROWS和--verbose選項查看更改了哪些數據。 或者,使用binlog_rows_query_log_events變量,如果啓用,則在使用-vv選項時將該語句添加到mysqlbinlog輸出的Rows_query事件。
    • 對於使用MyISAM存儲引擎的表,當將INSERT語句作爲基於行的事件應用於二進制日誌而不是將它們作爲語句應用時,INSERT語句的slave需要更強的鎖。這意味着在使用基於行的複製時,不支持在MyISAM表上進行併發插入。

參考鏈接:https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html

PREV:6:多源複製的實現 https://blog.51cto.com/itzhoujun/2353940

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章