主从复制格局下跳过不当

发布时间:2019-04-21  栏目:NoSQL  评论:0 Comments

mysql 的为主错误跳过和mariadb的多源主从复制错误跳过操作不相同,请留意:
改变会话的default_master_connection变量

今天我们最首要看主从方式下,二种跳过荒唐的法子,跳过事情,依旧跳过event?那么些在前面其实大家平昔都以忽视的,那在大家保险主题进度中,很轻松就变成基本数据越来越大的区别。
测试机器5.7.1八 主从 gtid 开启
主库数据
图片 1
从库数据
图片 2
很明朗主从数据有多少个不直接的地点,从库少了一条(2八,二)
的数量。这年主库开启以下专门的学业:
图片 3
这早晚导致从库出现谬误,报103贰谬误,如下所示:
mysql> show slave status\G;
***1. row***
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.56
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000023
Read_Master_Log_Pos: 1928
Relay_Log_File: hadoop2-relay-bin.000012
Relay_Log_Pos: 1595
Relay_Master_Log_File: mysql-bin.000023
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1032
Last_Error: Could not execute Delete_rows event on table
yhtest1.yhtest; Can’t find record in ‘yhtest’, Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND; the event’s master log
mysql-bin.000023, end_log_pos 1812
Skip_Counter: 0
Exec_Master_Log_Pos: 1502
Relay_Log_Space: 2384
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: 1032
Last_SQL_Error: Could not execute Delete_rows event on table
yhtest1.yhtest; Can’t find record in ‘yhtest’, Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND; the event’s master log
mysql-bin.000023, end_log_pos 1812
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: ab8c3ec3-b588-11e7-a769-000c29c57be6
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 171130 23:55:18
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: ab8c3ec3-b588-11e7-a769-000c29c57be6:96-101
Executed_Gtid_Set: ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-100,
b6ddfda0-d8bc-4272-a58f-4ea75acbbc79:1-22:1000012-1000013:2000012-2000013,
d24c1c76-b4ef-11e7-969a-000c29a75f68:1-17
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.01 sec)

STOP SLAVE 'slave_account';
SET @@default_master_connection = 'slave_account';
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE 'slave_account';
SET @@default_master_connection = '';

焚薮而田办法:
方法1
伍.柒下,由于开启了GTID ,不能够通过参数sql_slave_skip_counter=N
跳过错误,可是大家能够通过在从库实行空事物的艺术,跳过该错误,但要注意,那样跳过的是1个事物。
从以上报错新闻中,大家很轻易看到目前执行职位在:
ab八c叁ec三-b58八-11e7-a76玖-000c2九c5七be6:一:77-拾0 也正是报错地点在:
ab八c三ec3-b58八-1壹e7-a76玖-000c2九c57be6:一:77-十一
操作如下:
图片 4
本条时候,大家再一次show slave status\G
看到中央已经恢复生机平常,不过大家再对照数据,发掘大家刚刚主库的多个event
在同多个事变中,被大家凡事跳过了,约等于五个插入数据也未尝在从库实行!
主库数据:
图片 5
从库数据:
图片 6

方法2
倘使大家以为以上措施步骤比较多,仍是能够借住与pt-slave-restart
来进行主从错误跳过,跳过方法如下:
图片 7
以此一样能够高达跳过主从漏洞百出的目标!不过其跳过的单位也是职业,一样也会招致主库所做的五个插入未有在从库进行!
方法3
利用slave_exec_mode参数来拍卖主从中境遇的荒谬,操作步骤如下:

stop slave;
set global slave_exec_mode=’IDEMPOTENT’; 幂等情势(暗中认可是STOdysseyICT严俊方式)
start slave;
查看主从数据
图片 8
意识一律了,也正是说在调动参数slave_exec_mode后,大家跳过的delete
错误,不过四个插入操作任然是推行的,同时,查看错误日志,大家开采记录如下:
图片 9
方法4
采用参数slave_skip_errors跳过错误,操作方法如下,在配备文件中增添slave_skip_errors=106二,十3二等,重启数据库,运转slave ,也会意识测试结果和章程叁同样。可是slave_skip_errors 不扶助动态修改!
方法5
从库103二时,大家直接去主库找到相应的笔录,插入到从库个中,restart
salve, 拾6二 时 大家直接在从库中备份删除掉冲突记录就可以。

那边稍微提一下:mariadb 的Gtid
错误,大家能够接纳参数sql_slave_skip_counter=N直接跳过,然而,却不援助采纳pt-slave-restart
跳过不当,而且mariadb 的Gtid
和官方不通用,达成原理同样,达成形式缺区别,所以大家也不可能用那多少个版本之间搭建gtid主从。

留下评论

网站地图xml地图