主从复制形式下跳过不当

发布时间:2019-08-30  栏目:sqlite  评论:0 Comments

mysql 的主导错误跳过和mariadb的多源主从复制错误跳过操作区别,请留神:
转移会话的default_master_connection变量

那边稍微提一下:mariadb 的Gtid
错误,我们得以采取参数sql_slave_skip_counter=N直接跳过,可是,却不协助使用pt-slave-restart
跳过荒唐,并且mariadb 的Gtid
和官方不通用,达成原理一样,完成格局缺分歧,所以大家也无法用那五个版本之间搭建gtid主从。

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 = '';

明日大家注重看主从格局下,三种跳过荒唐的法子,跳过事情,照旧跳过event?这几个在事先其实大家平素都是忽视的,那在大家维护宗旨进度中,很轻便就形成基本数据更加大的差异等。
测量试验机器5.7.18 主从 gtid 开启
主库数据
图片 1
从库数据
图片 2
很显明主从数据有二个不直接的地方,从库少了一条(28,2)
的数据。那年主库开启以下专门的学业:
图片 3
那明显导致从库出现错误,报1032不当,如下所示:
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)

方法2
假定大家感到以上措施步骤相当多,还足以借住与pt-slave-restart
来举办主从错误跳过,跳过方法如下:
图片 4
以此一样可以完成跳过主从八花九裂的指标!可是其跳过的单位也是专门的职业,一样也会招致主库所做的多少个插入未有在从库实施!
方法3
利用slave_exec_mode参数来管理主从中遭逢的一无所长,操作步骤如下:

stop slave;
set global slave_exec_mode=’IDEMPOTENT’; 幂等格局(暗中同意是STEscortICT严酷格局)
start slave;
翻看主从数据
图片 5
发觉同样了,也便是说在调解参数slave_exec_mode后,大家跳过的delete
错误,但是八个插入操作任然是进行的,同期,查看错误日志,我们开采记录如下:
图片 6
方法4
行使参数slave_skip_errors跳过荒唐,操作方法如下,在安排文件中加多slave_skip_errors=1062,1032
等,重启数据库,运转slave ,也会开掘测量检验结果和艺术3一模二样。可是slave_skip_errors 不辅助动态修改!
方法5
从库1032时,我们一向去主库找到相应的笔录,插入到从库在那之中,restart
salve, 1062 时 大家直接在从库中备份删除掉争辨记录就可以。

减轻方法:
方法1
5.7下,由于开启了GTID ,无法透过参数sql_slave_skip_counter=N
跳过不当,可是我们能够透过在从库施行空事物的办法,跳过该错误,但要注意,那样跳过的是三个事物。
从以上报错音讯中,大家很轻巧看到方今施行职位在:
ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-100 也便是报错地点在:
ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-101
操作如下:
图片 7
那个时候,我们再次show slave status\G
看到中央已经恢复正常,然而大家再对照数据,发掘大家刚刚主库的七个event
在同三个平地风波中,被我们任何跳过了,也便是三个插入数据也从没在从库进行!
主库数据:
图片 8
从库数据:
图片 9

留下评论

网站地图xml地图