您好,登錄后才能下訂單哦!
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日志模式帶來的數據是否一致問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。