共计 2627 个字符，预计需要花费 7 分钟才能阅读完成。
MYSQL 在双 MASTER 环境中由 ROW 日志模式带来的数据是否一致，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
## 实验环境：双 MASTER 结构
Master1 == 10.249.160.132
Master2 == 10.249.160.133
RHEL 5.4 X64, MYSQL 5.1.40
binlog_format = MIXED
tx_isolation = READ-COMMITTED
(这里有一个要点：READ-COMMITTED + INNODB , MYSQL 强制使用 ROW 日志模式）
[@more@]
## 初始化数据
use test;
set names gbk;
drop table if exists h2 ;
create table h2 (id int , name varchar(20),comment varchar(500) , primary key (id))
engine=innodb default charset =gbk ;
insert into h2 values
(1, h2 , h211),
(2, h3 , h212),
(3, h4 , h213),
(4, h5 , h214),
(5, h6 , h215
flush logs ;
## 首先来认识一下，在 ROW 模式中，MYSQL 是如何记录 UPDATE 语句的。
比如：update h2 set name= h-m@2 where id=5;
BINLOG 日志里这样记录的：
BINLOG
wX3rSxMCAAAALwAAAHAGAAAAACYAAAAAAAAABHRlc3QAAmgxAAMDDw8EKADoAwY=
wX3rSxgCAAAAPQAAAK0GAAAQACYAAAAAAAEAA///+AUAAAACaDUEAGgxMTX4BQAAAAVoLW1AMgQA
aDExNQ==
/*!*/;
### UPDATE test.h2
### WHERE
### @1=5 /* INT meta=0 nullable=0 is_null=0 */
### @2= h6 /* VARSTRING(40) meta=40 nullable=1 is_null=0 */
### @3= h215 /* VARSTRING(1000) meta=1000 nullable=1 is_null=0 */
### SET
### @1=5 /* INT meta=0 nullable=0 is_null=0 */
### @2= h-m@2 /* VARSTRING(40) meta=40 nullable=1 is_null=0 */
### @3= h215 /* VARSTRING(1000) meta=1000 nullable=1 is_null=0 */
#### 我们发现 MYSQL 只是记录了字段对应的号码。@1，而不记录具体是哪个字段。（这正是俺担心的问题）
#### 下面我们用实验来验证一下问题。
#### Step 1 , at Master1 , 意图是让 MASTER2 的 SQL 在 Master1 上延时应用。
stop slave ;
#### Step 2，at Master2
update h2 set name= h-m@2 where id=5;
insert into h2 values (6, h7@2 , dsflk
### Have not apply on Master1
#### Step 3 ,at Master1
alter table h2 add addr varchar(500) after name ; ### 这里故障打断原的字段顺序
select * from h2;
+—-+——+——+———+
| id | name | addr | comment |
+—-+——+——+———+
| 1 | h2 | NULL | h211 |
| 2 | h3 | NULL | h212 |
| 3 | h4 | NULL | h213 |
| 4 | h5 | NULL | h214 |
| 5 | h6 | NULL | h215 |
+—-+——+——+———+
start slave; ### Start to apply sql log from Master 2
select * from h2;
+—-+——-+——-+———+
| id | name | addr | comment |
+—-+——-+——-+———+
| 1 | h2 | NULL | h211 |
| 2 | h3 | NULL | h212 |
| 3 | h4 | NULL | h213 |
| 4 | h5 | NULL | h214 |
| 5 | h-m@2 | h215 | h215 | ### addr = h215 ?????
| 6 | h7@2 | dsflk | NULL | ### addr = dsflk ?????
+—-+——-+——-+———+
#### At here . what we see ?
#### Column Addr, we have not do anything on it . bug it have data .
#### Column Comment for record 6 , it should be dsflk . not NULL
#### Step 4 ,at Master2 , There are data looks right ;
select * from h2;
+—-+——-+——+———+
| id | name | addr | comment |
+—-+——-+——+———+
| 1 | h2 | NULL | h211 |
| 2 | h3 | NULL | h212 |
| 3 | h4 | NULL | h213 |
| 4 | h5 | NULL | h214 |
| 5 | h-m@2 | NULL | h215 |
| 6 | h7@2 | NULL | dsflk |
+—-+——-+——+———+
#### at last,
Data in Master1 and Master2 are not same anymore.
当然，我们如果在作表结构变更时，把字段都加到最后，是没有这个问题的。
这应该当成是一个 BUG 处理。提交 MYSQL
还留了一个问题是：MYSQL 的应用日志时，是通过什么来匹配行的？主键？还是日志里所列条件都必须匹配。
理论上的答案应该是：主键，（如果没有主键，就是 MYSQL 帮你生成的内部主键。）有兴趣的同学可以自己测试一把。
关于 MYSQL 在双 MASTER 环境中由 ROW 日志模式带来的数据是否一致问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
