[MySQL Patch]自动处理备库错误

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:

转载请署名:印风

————————————————–

备库因为某些错误停止时有发生,最常见的错误就是”HA_ERR_KEY_NOT_FOUND”和 “HA_ERR_FOUND_DUPP_KEY”.这既有可能是主备切换导致的,也可能是MySQL Bug导致的

通常有两种办法来处理备库错误:

1). 设置 “sql_slave_skip_counter”来忽略错误.
2).set slave_exec_mode = “idempotent”来处理 “HA_ERR_FOUND_DUPP_KEY” (overwritten the record) 和”HA_ERR_KEY_NOT_FOUND”(简单的忽略掉错误).

这两种方法都可能导致主备不一致

如果你使用的是innodb存储引擎,并且使用的是ROW模式复制,那我们就可以fix这个Bug。

很久之前我写了一个工具(http://code.google.com/p/relay-fetch/,下面的slave_error_handler文件夹)可以用来处理这个问题。

以下的patch则通过修改代码,为slave_exec_mode增加新的选项SMART,来自动处理。

思想很简单

1) HA_ERR_KEY_NOT_FOUND
UPDATE_ROWS_EVENT: 先写记录的’Before Image’ ,然后再update
DELETE_ROWS_EVENT: 先写后删 , 或者直接忽略错误

2)HA_ERR_FOUND_DUPP_KEY
WRITE_ROWS_EVENT: overwrite the record

对UPDATE_ROWS_EVENT导致的重复键错误暂不做处理。

以下patch基于Percona Server 5.5.18:

 

Index: /PS5518/branches/PS-r1086-slave-auto-fix/sql/log_event.cc
===================================================================
— /PS5518/branches/PS-r1086-slave-auto-fix/sql/log_event.cc (revision 1136)
+++ /PS5518/branches/PS-r1086-slave-auto-fix/sql/log_event.cc (revision 1180)
@@ -8750,6 +8750,7 @@
applying the event in the replace (idempotent) fashion.
*/
if ((slave_exec_mode == SLAVE_EXEC_MODE_IDEMPOTENT) ||
+ (slave_exec_mode == SLAVE_EXEC_MODE_SMART) ||
(m_table->s->db_type()->db_type == DB_TYPE_NDBCLUSTER))
{
/*
@@ -8829,6 +8830,7 @@
m_table->next_number_field=0;
m_table->auto_increment_field_not_null= FALSE;
if ((slave_exec_mode == SLAVE_EXEC_MODE_IDEMPOTENT) ||
+ (slave_exec_mode == SLAVE_EXEC_MODE_SMART) ||
m_table->s->db_type()->db_type == DB_TYPE_NDBCLUSTER)
{
m_table->file->extra(HA_EXTRA_NO_IGNORE_DUP_KEY);
@@ -9124,7 +9126,9 @@
Write_rows_log_event::do_exec_row(const Relay_log_info *const rli)
{
DBUG_ASSERT(m_table != NULL);
– int error= write_row(rli, slave_exec_mode == SLAVE_EXEC_MODE_IDEMPOTENT);
+
+ int error= write_row(rli, slave_exec_mode == SLAVE_EXEC_MODE_IDEMPOTENT ||
+ slave_exec_mode == SLAVE_EXEC_MODE_SMART);

if (error && !thd->is_error())
{
@@ -9662,7 +9666,19 @@
Delete the record found, located in record[0]
*/
error= m_table->file->ha_delete_row(m_table->record[0]);
+ } else if ( (slave_exec_mode == SLAVE_EXEC_MODE_SMART) &&
+ (error == HA_ERR_KEY_NOT_FOUND)) {
+ tmp_disable_binlog(rli->sql_thd);
+ error = m_table->file->ha_write_row(m_table->record[0]) ||
+ m_table->file->rnd_pos_by_record(m_table->record[0]);
+
+ reenable_binlog(rli->sql_thd);
+ if (!error)
+ error = m_table->file->ha_delete_row(m_table->record[0]);
+ else
+ error = HA_ERR_KEY_NOT_FOUND;
}
+
return error;
}

@@ -9782,6 +9798,17 @@
int error= find_row(rli);
if (error)
{
+ if ((slave_exec_mode == SLAVE_EXEC_MODE_SMART) &&
+ (error == HA_ERR_KEY_NOT_FOUND)) {
+ tmp_disable_binlog(rli->sql_thd);
+ error = m_table->file->ha_write_row(m_table->record[0]) ||
+ m_table->file->rnd_pos_by_record(m_table->record[0]);
+ reenable_binlog(rli->sql_thd);
+ if (error)
+ error = HA_ERR_KEY_NOT_FOUND;
+ }
+
+ if (error) {
/*
We need to read the second image in the event of error to be
able to skip to the next pair of updates
@@ -9789,6 +9816,7 @@
m_curr_row= m_curr_row_end;
unpack_current_row(rli);
return error;
+ }
}

/*
Index: /PS5518/branches/PS-r1086-slave-auto-fix/sql/sql_class.h
===================================================================
— /PS5518/branches/PS-r1086-slave-auto-fix/sql/sql_class.h (revision 1136)
+++ /PS5518/branches/PS-r1086-slave-auto-fix/sql/sql_class.h (revision 1180)
@@ -90,6 +90,7 @@
enum enum_log_warnings_suppress { log_warnings_suppress_1592 };
enum enum_slave_exec_mode { SLAVE_EXEC_MODE_STRICT,
SLAVE_EXEC_MODE_IDEMPOTENT,
+ SLAVE_EXEC_MODE_SMART,
SLAVE_EXEC_MODE_LAST_BIT};
enum enum_slave_type_conversions { SLAVE_TYPE_CONVERSIONS_ALL_LOSSY,
SLAVE_TYPE_CONVERSIONS_ALL_NON_LOSSY};
Index: /PS5518/branches/PS-r1086-slave-auto-fix/sql/sys_vars.cc
===================================================================
— /PS5518/branches/PS-r1086-slave-auto-fix/sql/sys_vars.cc (revision 1136)
+++ /PS5518/branches/PS-r1086-slave-auto-fix/sql/sys_vars.cc (revision 1180)
@@ -1962,7 +1962,7 @@
DEFAULT(FALSE));

#ifdef HAVE_REPLICATION
-static const char *slave_exec_mode_names[]= {“STRICT”, “IDEMPOTENT”, 0};
+static const char *slave_exec_mode_names[]= {“STRICT”, “IDEMPOTENT”, “SMART”,0};
static Sys_var_enum Slave_exec_mode(
“slave_exec_mode”,
“Modes for how replication events should be executed. Legal values ”

 

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
4月前
|
canal 关系型数据库 MySQL
实时计算 Flink版产品使用问题之在进行整库同步MySQL数据到StarRocks时,遇到全量数据可以同步,但增量数据无法同步,是什么导致的
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
19天前
|
SQL 关系型数据库 MySQL
MySQL操作利器——mysql-connector-python库详解
MySQL操作利器——mysql-connector-python库详解
192 0
|
1月前
|
SQL 监控 关系型数据库
MySQL 延迟从库介绍
本文介绍了MySQL中的延迟从库功能,详细解释了其工作原理及配置方法。延迟从库允许从库在主库执行完数据变更后延迟一段时间再同步,主要用于快速恢复误操作的数据。此外,它还可用于备份、离线查询及数据合规性需求。通过合理配置,可显著提升数据库系统的稳定性和可靠性。
|
10天前
|
Oracle 关系型数据库 MySQL
shell获取多个oracle库mysql库所有的表
请注意,此脚本假设你有足够的权限访问所有提到的数据库。在实际部署前,请确保对脚本中的数据库凭据、主机名和端口进行适当的修改和验证。此外,处理数据库操作时,务必谨慎操作,避免因错误的脚本执行造成数据损坏或服务中断。
32 0
|
2月前
|
监控 关系型数据库 MySQL
mysql误删的performance_schema库
`performance_schema`库是MySQL性能监控的重要工具,误删除后可以通过上述方法尝试恢复。在操作过程中,重启MySQL服务器是最简单的尝试方法。如果这不起作用,可以尝试使用MySQL的初始化选项,但请注意备份数据以防数据丢失。检查MySQL配置也是一个好的步骤,以确保 `performance_schema`没有被禁用。最后,如果有备份,通过恢复备份来恢复 `performance_schema`库是最保险的方法。在操作过程中,确保遵循最佳实践和操作前备份重要数据。
88 5
|
2月前
|
SQL 关系型数据库 MySQL
MySQL主从:延时从库恢复全解
MySQL主从:延时从库恢复全解
|
2月前
|
SQL 监控 关系型数据库
MySQL 延迟从库介绍
我们都知道,MySQL 主从延迟是一件很难避免的情况,从库难免会偶尔追不上主库,特别是主库有大事务或者执行 DDL 的时候。MySQL 除了这种正常从库外,还可以设置延迟从库,顾名思义就是故意让从库落后于主库多长时间,本篇文章我们一起来了解下 MySQL 中的延迟从库。
48 0
|
2月前
|
SQL 监控 关系型数据库
mysql统计数据库大小
通过这些方法,数据库管理员可以有效地监控和规划MySQL数据库的存储需求,确保数据库的稳定运行。
76 3
|
3月前
|
存储 SQL 关系型数据库
(三)MySQL之库表设计篇:一、二、三、四、五范式、BC范式与反范式详解!
几种设计范式,大部分小伙伴应该仅了解过三范式,对于其他的应该未曾接触,那在本篇中会重点阐述库表设计时,会用到的这些范式。
|
2月前
|
SQL 监控 关系型数据库
mysql统计数据库大小
通过这些方法,数据库管理员可以有效地监控和规划MySQL数据库的存储需求,确保数据库的稳定运行。
48 2