Row replication in MySQL

MySQL-based replication maximizes the consistency of master-slave replication, and for RBR (row-based replication) and SBR (based on statement replication), which is well known to all, the following records the row copy in the binary log total record.

Row based replication is position-dependent, and Binlog only records data for columns that have changed in the related table. Four new events were introduced: Table_map, write_rows,delete_rows,update_rows.

After a statement is executed, within Binlog, the Table_map event contains the table ID, and the type of the column (without the column name, slave can use this information to compare to the table structure on master), followed by the other three events, with the end flag of Stmt_end_f.

The event executes on the slave side:

1. The SQL thread reads the events from the secondary Japanese.

2, for and Table_map event, SQL thread will extract table information, save table definition

3, lock the table to be changed, and check the master and slave table structure is consistent.

4. If the table schema is inconsistent, stop copying, or continue the row event until the end marker is encountered: Stmt_end_f.

This column more highlights: http://www.bianceng.cn/database/MySQL/

For Update_rows and Delete_rows events, the SQL thread first navigates to a specific row and finds the steps for the operation:

1, primary KEY or

First select the primary key on the slave. That's the best way. When a matching primary key value is found, the matching row is considered to have been found, and the contents of the other columns of the row are not matched.

2. Non-null unique index Scan

This also only compares key values

3, other index or full table scan

This compares the entire row's data to master and slave (it does guarantee the consistency of master-slave replication, but also the slowest)

Specific test data please refer to

Http://www.mysqlops.com/2011/06/07/mysql-replication-data-consistency.html