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