MYSQL在双MASTER环境中由ROW日志模式带来的数据一致吗
|
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帮你生成的内部主键。） 有兴趣的同学可以自己测试一把。 （编辑：银川站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
