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 h1 ;
create table h1 (id int , name varchar(20),comment varchar(500 ) , primary key (id))
engine=innodb default charset =gbk ;

insert into h1 values
(1,'h1','h111'),
(2,'h2','h112'),
(3,'h3','h113'),
(4,'h4','h114'),
(5,'h5','h115');

flush logs ;

## 首先来认识一下，在ROW模式中，MYSQL是如何记录UPDATE语句的。
比如：update h1 set name='h-m@2' where id=5;

BINLOG日志里这样记录的：

BINLOG '
wX3rSxMCAAAALwAAAHAGAAAAACYAAAAAAAAABHRlc3QAAmgxAAMDDw8EKADoAwY=
wX3rSxgCAAAAPQAAAK0GAAAQACYAAAAAAAEAA///+AUAAAACaDUEAGgxMTX4BQAAAAVoLW1AMgQA
aDExNQ==
'/*!*/;
### UPDATE test.h1
### WHERE
### @1=5 /* INT meta=0 nullable=0 is_null=0 */
### @2='h5' /* VARSTRING(40) meta=40 nullable=1 is_null=0 */
### @3='h115' /* 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='h115' /* 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 h1 set name='h-m@2' where id=5;
insert into h1 values (6,'h6@2','dsflk');
### Have not apply on Master1

#### Step 3 ,at Master1
alter table h1 add addr varchar(500) after name ; ### 这里故障打断原的字段顺序
select * from h1;
+----+------+------+---------+
| id | name | addr | comment |
+----+------+------+---------+
| 1 | h1 | NULL | h111 |
| 2 | h2 | NULL | h112 |
| 3 | h3 | NULL | h113 |
| 4 | h4 | NULL | h114 |
| 5 | h5 | NULL | h115 |
+----+------+------+---------+
start slave; ###　Start to apply sql log from Master 2
select * from h1;
+----+-------+-------+---------+
| id | name | addr | comment |
+----+-------+-------+---------+
| 1 | h1 | NULL | h111 |
| 2 | h2 | NULL | h112 |
| 3 | h3 | NULL | h113 |
| 4 | h4 | NULL | h114 |
| 5 | h-m@2 | h115 | h115 | ### addr = h115 ?????
| 6 | h6@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 h1;
+----+-------+------+---------+
| id | name | addr | comment |
+----+-------+------+---------+
| 1 | h1 | NULL | h111 |
| 2 | h2 | NULL | h112 |
| 3 | h3 | NULL | h113 |
| 4 | h4 | NULL | h114 |
| 5 | h-m@2 | NULL | h115 |
| 6 | h6@2 | NULL | dsflk |
+----+-------+------+---------+

#### at last,
Data in Master1 and Master2 are not same anymore.

#### 小结
当然，我们如果在作表结构变更时，把字段都加到最后，是没有这个问题的。
这应该当成是一个BUG处理。提交MYSQL
　
还留了一个问题是：MYSQL的应用日志时，是通过什么来匹配行的？　主键？　还是日志里所列条件都必须匹配。　
　理论上的答案应该是：主键，（如果没有主键，就是MYSQL帮你生成的内部主键。） 有兴趣的同学可以自己测试一把。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/703656/viewspace-1033580/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/703656/viewspace-1033580/