日韩性视频-久久久蜜桃-www中文字幕-在线中文字幕av-亚洲欧美一区二区三区四区-撸久久-香蕉视频一区-久久无码精品丰满人妻-国产高潮av-激情福利社-日韩av网址大全-国产精品久久999-日本五十路在线-性欧美在线-久久99精品波多结衣一区-男女午夜免费视频-黑人极品ⅴideos精品欧美棵-人人妻人人澡人人爽精品欧美一区-日韩一区在线看-欧美a级在线免费观看

歡迎訪問 生活随笔!

生活随笔

當前位置: 首頁 > 运维知识 > 数据库 >内容正文

数据库

mysql主主同步冲突_MySQL主主同步主键冲突处理

發布時間:2023/12/4 数据库 41 豆豆
生活随笔 收集整理的這篇文章主要介紹了 mysql主主同步冲突_MySQL主主同步主键冲突处理 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

兩臺數據庫都報slave同步失敗了,先說明一下環境,架構:lvs+keepalived+amoeba+mysql,主主復制,單臺寫入,

主1:192.168.0.223(寫)

主2:192.168.0.230

好吧,先show slave status \G看一下同步失敗的具體報錯吧

登錄主2庫查看:

mysql> show slave status \G

*************************** 1. row ***************************

Slave_IO_State:

Master_Host: 192.168.0.223

Master_User: slave

Master_Port: 13204

Connect_Retry: 60

Master_Log_File: mysql-bin.000009

Read_Master_Log_Pos: 50419

Relay_Log_File: mysqld-relay-bin.000014

Relay_Log_Pos: 34626

Relay_Master_Log_File: mysql-bin.000009

Slave_IO_Running: No

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB: mysql,information_schema,performance_schema,test,mysql,information_schema,performance_schema,test

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 1062

Last_Error: Error 'Duplicate entry '1329544' for key 'PRIMARY'' on query. Default database: 'data'. Query: 'insert into kn_chongzhi(orderid,aa,buyNum,state,type,create_time,fac,cc,flag)

values(20130702173025036581,15935779926,1,0,'SJ',1372757425,'30.27','30',100)'

Skip_Counter: 0

Exec_Master_Log_Pos: 34480

Relay_Log_Space: 51171

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: NULL

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 1062

Last_SQL_Error: Error 'Duplicate entry '1329544' for key 'PRIMARY'' on query. Default database: 'data'. Query: 'insert into kn_chongzhi(orderid,aa,buyNum,state,type,create_time,fac,cc,flag)

values(20130702173025036581,15935779926,1,0,'SJ',1372757425,'30.27','30',100)'

Replicate_Ignore_Server_Ids:

Master_Server_Id: 2

1 row in set (0.00 sec)

尼瑪,苦逼的又是主鍵沖突,先查看一下這張表的結構:

mysql> desc? kn_chongzhi;

+-------------+-----------------+------+-----+---------+----------------+

| Field? ? ? | Type? ? ? ? ? ? | Null | Key | Default | Extra? ? ? ? ? |

+-------------+-----------------+------+-----+---------+----------------+

| id? ? ? ? ? | int(10)? ? ? ? | NO? | PRI | NULL? ? | auto_increment |

| aa? ? | varchar(32)? ? | NO? | MUL | NULL? ? |? ? ? ? ? ? ? ? |

| bizOfferId? | varchar(32)? ? | NO? |? ? | NULL? ? |? ? ? ? ? ? ? ? |

| number? ? ? | varchar(20)? ? | NO? | MUL | NULL? ? |? ? ? ? ? ? ? ? |

| cc? ? ? | float(10,2)? ? | NO? |? ? | NULL? ? |? ? ? ? ? ? ? ? |

| fac? | float(10,2)? ? | YES? |? ? | 0.00? ? |? ? ? ? ? ? ? ? |

| buyNum? ? ? | int(10)? ? ? ? | NO? |? ? | NULL? ? |? ? ? ? ? ? ? ? |

| state? ? ? | tinyint(4)? ? ? | NO? |? ? | 0? ? ? |? ? ? ? ? ? ? ? |

| type? ? ? ? | enum('SJ','QB') | NO? |? ? | SJ? ? ? |? ? ? ? ? ? ? ? |

| create_time | int(11)? ? ? ? | NO? |? ? | NULL? ? |? ? ? ? ? ? ? ? |

| update_time | int(11)? ? ? ? | NO? |? ? | NULL? ? |? ? ? ? ? ? ? ? |

| flag? ? ? ? | int(10)? ? ? ? | NO? |? ? | 0? ? ? |? ? ? ? ? ? ? ? |

+-------------+-----------------+------+-----+---------+----------------+

12 rows in set (0.00 sec)

想必大家已經知道問題是這么產生的了,這里我再大體的說一下,可能有些人還不明白哈,回頭看前面的架構,引起 這個問題的原因是主1的網絡抖動,導致amoeba把寫切到了主2,主1的網絡好了,寫又切回了主1,由于主鍵ID是自曾的,所以就出現了這個問題,我舉個例子:

開始是寫主1的,已經寫6條數據(id=1、2、3、4、5、6),突然主1網絡抖動,開始在主2寫了三條(id=7、8、9),主1的網絡又恢復了,寫又在主1上了(id=7、8、9、10、。。。。),這時,主1要把id=7、8、9、10.。。。。的數據復制給主2,主2 要把id=7、8、9三條數據復制給主1,這不就傻逼了嗎?

處理的過程:

1、在兩個庫上stop slave;

2、在主2上執行select * from kn_chongzhi where id>=1329544\G (查看在主2上寫了幾條數據)

mysql> select * from kn_chongzhi where id>=1329544\G

*************************** 3661. row ***************************

id: 1329545

aa: 20130702213504529562

bizOfferId: DK201307021139565210

number: 13991056094

cc: 30.00

fac: 30.22

buyNum: 1

state: 2

type: SJ

create_time: 1372772104

update_time: 1372772474

flag: 100

*************************** 3662. row ***************************

id: 1329546

aa: 20130702213506629648

bizOfferId: DK201307021139588209

number: 15511391791

cc: 30.00

fac: 30.17

buyNum: 1

state: 0

type: SJ

create_time: 1372772106

update_time: 0

flag: 100

*************************** 3663. row ***************************

id: 1329547

aa: 20130702213516595293

bizOfferId: DK201307021139758209

number: 13615611693

cc: 100.00

fac: 99.85

buyNum: 1

state: 2

type: SJ

create_time: 1372772116

update_time: 1372772315

flag: 101

3、在主2上delete from kn_chongzhi where id>=1329544;? 并設置自曾ID從1329545開始

mysql> delete from kn_chongzhi where id>=1329544;

Query OK, 0 rows affected (0.00 sec)

mysql> alter table kn_chongzhi auto_increment=1329545;

Query OK, 0 rows affected (0.15 sec)

Records: 0? Duplicates: 0? Warnings: 0

4、主2上slave start,show slave? status \G,發現主2同步主1已經ok了;

5、在主2上show master? status \G,獲取binlog文件名和Position點,在主1上重新change master

6、把上面三條數據保存好,發給程序猿手到錄入主1,

PS:當然,如果我按一下設置,肯定不會出現這個問題,如果業務有要求,ID必須連續,那就不能設置這兩個參數了:

主1:

auto-increment-increment=2

auto-increment-offset=1

主2:

auto-increment-increment=2

auto-increment-offset=2

總結

以上是生活随笔為你收集整理的mysql主主同步冲突_MySQL主主同步主键冲突处理的全部內容,希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯,歡迎將生活随笔推薦給好友。