생산 환경 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 knchongzhi 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 mastatus\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