【转载】备库由于表无主键导致延迟

摘要: 由于ROW模式的复制已经广泛使用,但对于没有主键的表而言,如果发生大更新,在备库上会表现出极大的延迟,因为在binlog中产生的大量行记录将无法根据主键快速查找,最差的情况,需要对每条修改的记录进行全表扫描。 5.6已经解决了这个问题,可以只扫描一次表;5.5最新的版本只是在错误日志里输出了一些信...

由于ROW模式的复制已经广泛使用,但对于没有主键的表而言,如果发生大更新,在备库上会表现出极大的延迟,因为在binlog中产生的大量行记录将无法根据主键快速查找,最差的情况,需要对每条修改的记录进行全表扫描。

5.6已经解决了这个问题,可以只扫描一次表;5.5最新的版本只是在错误日志里输出了一些信息。

Port 5.6的实现不太现实,因为改动太大。因此我做了些小改动,对于无主键表上的DELETE/UPDATE,转换为STATEMENT模式的binlog记录。

以下是一个改动非常简单的patch,基于Percona5.5.18

Index: /PS5518/branches/PS-r3633-nopk-logstmt/sql/sys_vars.cc
===================================================================
--- /PS5518/branches/PS-r3633-nopk-logstmt/sql/sys_vars.cc	(revision 3639)
+++ /PS5518/branches/PS-r3633-nopk-logstmt/sql/sys_vars.cc	(revision 3641)
@@ -396,6 +396,13 @@
        CMD_LINE(OPT_ARG), DEFAULT(FALSE),
        NO_MUTEX_GUARD, NOT_IN_BINLOG, ON_CHECK(binlog_direct_check));

+static Sys_var_mybool Sys_binlog_use_stmt_for_non_pk(
+      "binlog_use_stmt_for_non_pk",
+      "if a table doesn‘t have primary key ,then log the changes (SQLCOM_DELETE"
+      "and SQLCOM_UPDATE) using STATEMENT.",
+      SESSION_VAR(binlog_use_stmt_for_non_pk),
+      CMD_LINE(OPT_ARG), DEFAULT(FALSE));
+
 static Sys_var_ulong Sys_bulk_insert_buff_size(
        "bulk_insert_buffer_size", "Size of tree cache used in bulk "
        "insert optimisation. Note that this is a limit per thread!",
Index: /PS5518/branches/PS-r3633-nopk-logstmt/sql/sql_class.h
===================================================================
--- /PS5518/branches/PS-r3633-nopk-logstmt/sql/sql_class.h	(revision 3639)
+++ /PS5518/branches/PS-r3633-nopk-logstmt/sql/sql_class.h	(revision 3641)
@@ -492,6 +492,7 @@

   ulong binlog_format; ///< binlog format for this thd (see enum_binlog_format)
   my_bool binlog_direct_non_trans_update;
+  my_bool binlog_use_stmt_for_non_pk;
   my_bool sql_log_bin;
   ulong completion_type;
   ulong query_cache_type;
Index: /PS5518/branches/PS-r3633-nopk-logstmt/sql/sql_class.cc
===================================================================
--- /PS5518/branches/PS-r3633-nopk-logstmt/sql/sql_class.cc	(revision 3639)
+++ /PS5518/branches/PS-r3633-nopk-logstmt/sql/sql_class.cc	(revision 3641)
@@ -4495,10 +4495,14 @@
       Get the capabilities vector for all involved storage engines and
       mask out the flags for the binary log.
     */
+    my_bool table_no_key= false;
     for (TABLE_LIST *table= tables; table; table= table->next_global)
     {
       if (table->placeholder())
         continue;
+
+      if (table->table->s->primary_key >=  MAX_KEY)
+        table_no_key= true;

       if (table->table->s->table_category == TABLE_CATEGORY_PERFORMANCE ||
           table->table->s->table_category == TABLE_CATEGORY_LOG)
@@ -4680,6 +4684,13 @@
           /* log in row format! */
           set_current_stmt_binlog_format_row_if_mixed();
         }
+        /*if there is a table without any primary key,log in stmt format*/
+        else if (table_no_key &&
+                 (variables.binlog_use_stmt_for_non_pk) &&
+                 (variables.binlog_format == BINLOG_FORMAT_ROW ) &&
+                 (lex->sql_command == SQLCOM_DELETE ||
+                   lex->sql_command == SQLCOM_UPDATE))
+          clear_current_stmt_binlog_format_row();
       }
     }
时间: 2024-08-26 12:01:17

【转载】备库由于表无主键导致延迟的相关文章

binlog_format=ROW模式下mysql表无主键造成的从库延迟(卡住)

场景: MySQL-5.6.30, 主从架构, 只读从库的SQL线程卡在某一个事务两个多小时没有动过, show processlist发现从库当时没有连接和慢查询语句;show open TABLES where In_use >0; 发现一个表被锁定如下: mysql> show open TABLES where In_use >0; +----------+---------------+--------+-------------+ | Database | Table | I

模拟主库创建数据文件,dg备库空间不足时问题处理

本篇文档测试目的: 模拟实际环境中,主库对表空间添加数据文件,备库空间不足,最终导致MRP进程自动断开,处理方式. 1.问题环境模拟 1)正常情况下的dg 主库创建数据文件,备库接受日志,自动创建表空间及数据文件. RFS[49]: Selected log 4 for thread 1 sequence 115 dbid 699220720 branch 994543603 Fri Feb 22 23:20:36 2019 Media Recovery Log /u01/app/oracle/

【转载】mysql主键的缺少导致备库hang

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

mysql主键的缺少导致备库hang

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

ORA-21561、ORA-15055、ORA-25253 导致DG备库无法应用归档

昨天去某客户那里做巡检,顺便看一下上次搭建的RAC-DG环境是否正常,不看不知道,一看吓一跳,上次的DG是8月20日运行的,而DG备库从8月31日之后实例就没有开启过,后来询问后才得知,原来那天断过一次电,后来重启了机器.直到今天我过去了,才把实例启动起来.也就是说,从8月31日到今天快1个月的时间,备库一致处于未使用状态. 接着查看备库归档,显然已经缺失了很多了,tnread1 最后一个日志为1661,tnread2 最后一个日志为1324,而此时主库中还保留的最早的日志是9月8日的,thre

#技塑人生# windows2008无法远程— 注册表缺失键值导致高级防火墙服务异常

windows2008无法远程— 注册表缺失键值导致高级防火墙服务异常 阿里云技术支持中心:章阿贵 一.远程无法访问(windows server 2008) 症状:无法远程但是系统内网络正常,防火墙打开报错,如下图: 启动防火墙服务Windows Firewall(MpsSvc),如果无法启动,报错误代码5,日志记录错误代码7024,如下图所示: 解决方法: 1.到相同版本的系统中将如下键值导出 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\servi

MySQL 之 第二章: 库与表的基本操作; 数据类型; 完整性约束; 外键;

库与表的基本操作 数据类型 完整性约束 外键 库与表的基本操作 库的增删改查: 查看系统库语句: show databases; information_schema: 虚拟库,不占用磁盘空间,存储的是数据库启动后的一些参数,如用户表信息.列信息.权限信息.字符信息等performance_schema: MySQL 5.5开始新增一个数据库:主要用于收集数据库服务器性能参数,记录处理查询请求时发生的各种事件.锁等现象mysql: 授权库,主要存储系统用户的权限信息 sys: 创建数据库语法:

DG备库磁盘空间满导致无法创建归档

上周五去某客户那里做数据库巡检,是window 2008系统上10g的一套NC系统的库,已经配置了DG,但是巡检时发现数据库报错: Tue Nov 11 10:13:57 2014 LNS: Standby redo logfile selected for thread 1 sequence 3945 for destination LOG_ARCHIVE_DEST_2 Tue Nov 11 10:14:29 2014 Errors in file d:\oracle\product\10.2

ORA-0402导致oracle11gADG备库宕机问题处理

发现数据库告警,查看alert日志,发现如下报错Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_lgwr_26383.trc:ORA-04021: timeout occurred while waiting to lock object LGWR (ospid: 26383): terminating the instance due to error 4021Sun Mar 25 03:29:07 2018Sy