标签归档:MySQL FAQ

FAQ系列 | 监控平均SQL响应时长

导读

MySQL里如何监控平均SQL响应时长?

问题由来

对MySQL的性能指标监控,除了关注tps(每秒可执行的事务数)、qps(每秒请求数)两个衡量吞吐量的重要指标外,还应该监控平均SQL响应时长指标。

怎么做

有几个可选方案:

1、利用MySQL提供的benchmark()函数。这个函数的作用是模拟进行N次某种调用,这样一来,我们就可以利用这个函数调用N次专门的存储过程,根据其执行耗时,以此作为平均SQL响应时长的依据;

2、利用pt-query-digest工具,并结合tcpdump实时抓取每个SQL请求,也就能分析出每个SQL请求的响应时长了;

3、使用Percona或者MariaDB分支版本提供的QUERY_RESPONSE_TIME插件功能,它可以帮我们统计平均SQL响应时长的分布区间,类似直方图功能;

第一种相对比较简单但不够精确(不过也是够用的),第二种略麻烦些但可以看到每次请求的详细记录,第三种则只能看到整体的分布,无法看到每次请求的详细记录。

写在最后

监控性能指标时,除了关注吞吐量,还应该关注每次请求的平均响应时长。以高速公路收费站为例,有几个收费口基本可表示其并发收费能力(tps),而每辆车的平均通行时间如果很久的话,相信你也是受不了的是不是 :)

 

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yejinrong.com 获得专属优惠

FAQ系列 | lower_case_table_names迷思

导读

关于 lower_case_table_names 选项的设置的建议是怎样的呢?

问题由来

我个人认为,纠结于这个选项设置源于有些项目是从ORACLE或SQL Server迁移过来,在这两个数据库系统中,都无需关心数据表的大小写。而在MySQL中,默认是要区分大小写的(因为Unix/Linux文件系统是区分文件名大小写的),除非在windows系统下(windows系统是不区分大小写的)。

老叶的建议

我在公司制定的规范是要求默认设置 lower_case_table_names=0 的,也就是区分大小写。那么问题来了,如果是从ORACLE或SQL Server迁移到MYSQL的应用应该怎么处理呢?
我的建议是:

  • 首先,检查确认在应用程序中(或者抓取一段时间的请求日志),数据表名的写法是大写、小写还是混用,如果都是大写或者都是小写,那就更简单些了;
  • 其次,根据上面检查的结果,确定迁移到MySQL后统一使用大写还是小写(使用哪种规则的改动代价更小);
  • 最后,利用Linux下的awk\sed等工具,将包含数据表关键字的地方全部替换成第二部定义好的表名方案;

这样一来,就可以完成数据表名方案的切换了。

当然了,肯定有人(比如某领导、某PM,你懂得的,O(∩_∩)O哈哈~)会说全部修改表名风险太大,需要全面测试,这个项目时间进度很紧张,希望能先上线。这种情况就没办法了,只能闲设置 lower_case_table_names=1,然后迁移数据,优先保证项目进度。

but,即便这时候,我们也建议数据表初始化时,统一采用大写或小写的表名,在项目的后续过程中,通过开启general log的方式,把所有请求SQL中使用的表名都记录下来,然后检查还有哪些和我们定义的规则不一样,再逐渐完善修改,最终达到最终目标。

写在最后

强烈建议在定义数据库设计规范时,统一采用全部都大写或全部都小写的数据表命名规则,没必要为了所谓的美观,弄出一堆大小写混合的表名,是在太操蛋了。

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

 

利用event为zabbix数据表定期添加和删除分区

导读

利用MySQL的event来自动维护表分区。

我们去年就开始把zabbix数据库改成用TokuDB来支撑,并且启用了表分区(详情见:迁移Zabbix数据库到TokuDB)。这样做的好处很明显,较早的历史数据可以通过删除分区快速废弃掉。要知道,zabbix数据表默认是没有针对时间字段创建索引的,因此如果执行删除的SQL命令,其效率会很差,而直接删除分区就快多了。

先看history表的分区规则:

CREATE TABLE history (
 itemid bigint(20) unsigned NOT NULL,
 clock int(11) NOT NULL DEFAULT '0',
 value double(16,4) NOT NULL DEFAULT '0.0000',
 ns int(11) NOT NULL DEFAULT '0',
 KEY history_1 (itemid,clock)
 ) ENGINE=TokuDB DEFAULT CHARSET=utf8 ROW_FORMAT=TOKUDB_QUICKLZ
 PARTITION BY RANGE (clock)
 (PARTITION p20150531 VALUES LESS THAN (1433088000) ENGINE = TokuDB,
 ...
 PARTITION p20160411 VALUES LESS THAN (1460390400) ENGINE = TokuDB);

对这个表,我们每天要的是:创建一个新的分区,而后删除N个月前的历史旧分区。这个工作可以通过系统的cron来实施,也可以利用MySQL自身的event来做,在这里我们选择用event,没什么特殊的原因,只是想顺便尝试下event而已,呵呵。

一个定期调度的event写起来并不难,下面是参考样例,相信很快就能看明白:

delimiter $$$
 drop event if exists zabbix_alter_partition_daily;
 CREATE EVENT zabbix_alter_partition_daily
 ON SCHEDULE EVERY 1 DAY -- 每天执行
 DO
 begin

 -- 记日志
 insert into zlogs select 0, now(), date_format(date_sub(now(), INTERVAL 180 DAY),
 " ALTER TABLE history DROP PARTITION p%Y%m%d");

 -- 删除history表180天前的旧分区
 -- 用PREPARE & EXECUTE 准备和执行删除的SQL
 SET @drop_p_stmt = date_format(date_sub(now(), INTERVAL 180 DAY)," ALTER TABLE history DROP PARTITION p%Y%m%d");
 PREPARE drop_p_stmt FROM @drop_p_stmt;
 EXECUTE drop_p_stmt;

 -- 创建history表30天后的新分区
 insert into zlogs select 0, now(), concat(
 date_format(date_add(now(), INTERVAL 180 DAY)," ALTER TABLE history ADD PARTITION ( PARTITION p%Y%m%d VALUES LESS THAN "),
 "(", 
 unix_timestamp( date_add(date_format(now(), "%Y%m%d"), INTERVAL 31 DAY) ),
 "))");

 SET @add_p_stmt = concat(
 date_format(date_add(now(), INTERVAL 30 DAY)," ALTER TABLE history ADD PARTITION ( PARTITION p%Y%m%d VALUES LESS THAN "),
 "(",
 unix_timestamp( date_add(date_format(now(), "%Y%m%d"), INTERVAL 31 DAY) ),
 "))");

 PREPARE add_p_stmt FROM @add_p_stmt;
 EXECUTE add_p_stmt;

 end $$$
 delimiter ;

FAQ系列 | 如何保证主从复制数据一致性

导读

MySQL主从复制环境中,如何才能保证主从数据的一致性呢?

关于主从复制

现在常用的MySQL高可用方案,十有八九是基于 MySQL的主从复制(replication)来设计的,包括常规的一主一从、双主模式,或者半同步复制(semi-sync replication)。

我们常常把MySQL replication说成是MySQL同步(sync),但事实上这个过程是异步(async)的。大概过程是这样的:

  1. 在master上提交事务后,并且写入binlog,返回事务成功标记;
  2. 将binlog发送到slave,转储成relay log;
  3. 在slave上再将relay log读取出来应用。

步骤1和步骤3之间是异步进行的,无需等待确认各自的状态,所以说MySQL replication是异步的。

MySQL semi-sync replication在之前的基础上做了加强完善,整个流程变成了下面这样:

  1. 首先,master和至少一个slave都要启用semi-sync replication模式;
  2. 某个slave连接到master时,会主动告知当前自己是否处于semi-sync模式;
  3. 在master上提交事务后,写入binlog后,还需要通知至少一个slave收到该事务,等待写入relay log并成功刷新到磁盘后,向master发送“slave节点已完成该事务”确认通知;
  4. master收到上述通知后,才可以真正完成该事务提交,返回事务成功标记;
  5. 在上述步骤中,当slave向master发送通知时间超过rpl_semi_sync_master_timeout设定值时,主从关系会从semi-sync模式自动调整成为传统的异步复制模式。

半同步复制看起来很美好有木有,但如果网络质量不高,是不是出现抖动,触发上述第5条的情况,会从半同步复制降级为普通复制;此外,采用半同步复制,会导致master上的tps性能下降非常严重,最严重的情况下可能会损失50%以上。

这样来看,除非需要非常严格保证数据一致性等迫不得已的场景,就不太建议使用半同步复制了。当然了,事实上我们也可以通过加强程序端的逻辑控制,来避免主从数据不一致时发生逻辑错误,比如说如果在从上读取到的数据和主不一致的话,那么就触发主从间的一次数据修复工作。或者,我们也可以用 pt-table-checksum & pt-table-sync 两个工具来校验并修复数据,只要运行频率适当,是可行的。

真想要提高多节点间的数据一致性,可以考虑采用PXC方案。现在已知用PXC规模较大的有qunar、sohu,如果团队里初期没有人能比较专注PXC的话,还是要谨慎些,毕竟和传统的主从复制差异很大,出现问题时需要花费更多精力去排查解决。

如何保证主从复制数据一致性

上面说完了异步复制、半同步复制、PXC,我们回到主题:在常规的主从复制场景里,如何能保证主从数据的一致性,不要出现数据丢失等问题呢?

在MySQL中,一次事务提交后,需要写undo、写redo、写binlog,写数据文件等等。在这个过程中,可能在某个步骤发生crash,就有可能导致主从数据的不一致。为了避免这种情况,我们需要调整主从上面相关选项配置,确保即便发生crash了,也不能发生主从复制的数据丢失。

1. 在master上修改配置

innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

上述两个选项的作用是:保证每次事务提交后,都能实时刷新到磁盘中,尤其是确保每次事务对应的binlog都能及时刷新到磁盘中,只要有了binlog,InnoDB就有办法做数据恢复,不至于导致主从复制的数据丢失。

2. 在slave上修改配置

master_info_repository = "TABLE"
relay_log_info_repository = "TABLE"
relay_log_recovery = 1

上述前两个选项的作用是:确保在slave上和复制相关的元数据表也采用InnoDB引擎,受到InnoDB事务安全的保护,而后一个选项的作用是开启relay log自动修复机制,发生crash时,会自动判断哪些relay log需要重新从master上抓取回来再次应用,以此避免部分数据丢失的可能性。

通过上面几个选项的调整,就可以确保主从复制数据不会发生丢失了。但是,这并不能保证主从数据的绝对一致性,因为,有可能设置了ignore\do\rewrite等replication规则,或者某些SQL本身存在不确定因素,或者人为在slave上修改数据,最终导致主从数据不一致。这种情况下,可以采用pt-table-checksumpt-table-sync 工具来进行数据的校验和修复。

FAQ系列 | MySQL索引之主键索引

导读

在MySQL里,主键索引和辅助索引分别是什么意思,有什么区别?

上次的分享我们介绍了聚集索引和非聚集索引的区别,本次我们继续介绍主键索引和辅助索引的区别。

1、主键索引

主键索引,简称主键,原文是PRIMARY KEY,由一个或多个列组成,用于唯一性标识数据表中的某一条记录。一个表可以没有主键,但最多只能有一个主键,并且主键值不能包含NULL。

在MySQL中,InnoDB数据表的主键设计我们通常遵循几个原则:

  1. 采用一个没有业务用途的自增属性列作为主键;
  2. 主键字段值总是不更新,只有新增或者删除两种操作;
  3. 不选择会动态更新的类型,比如当前时间戳等。

这么做的好处有几点:

  1. 新增数据时,由于主键值是顺序增长的,innodb page发生分裂的概率降低了;可以参考以往的分享“[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键”;
  2. 业务数据有变更时,不修改主键值,物理存储位置发生变化的概率降低了,innodb page中产生碎片的概率也降低了。

MyISAM表因为是堆组织表,主键类型设计方面就可以不用这么讲究了。

2、辅助索引

辅助索引,就是我们常规所指的索引,原文是SECONDARY KEY。辅助索引里还可以再分为唯一索引非唯一索引

唯一索引其实应该叫做唯一性约束,它的作用是避免一列或多列值存在重复,是一种约束性索引。

3、主键索引和辅助索引的区别

在MyISAM引擎中,唯一索引除了key值允许存在NULL外,其余的和主键索引没有本质性区别。也就是说,在MyISAM引擎中,不允许存在NULL值的唯一索引,本质上和主键索引是一回事

而在InnoDB引擎中,主键索引和辅助索引的区别就很大了。主键索引会被选中作为聚集索引,而唯一索引和普通辅助索引间除了唯一性约束外,在存储上没本质区别

从查询性能上来说,在MyISAM表中主键索引和不允许有NULL的唯一索引的查询性能是相当的在InnoDB表通过唯一索引查询则需要多一次从辅助索引到主键索引的转换过程InnoDB表基于普通索引的查找代价更高,因为每次检索到结果后,还需要至少再多检索一次才能确认是否还有更多符合条件的结果,主键索引和唯一索引就不需要这么做了。

经过测试,对100万行数据的MyISAM做随机检索(整数类型),主键和唯一索引的效率基本一样,普通索引的检索效率则慢了30%以上。换成InnoDB表的话,唯一索引比主键索引效率约慢9%,普通索引比主键索引约慢了50%以上。

 

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

 

FAQ系列 | EXPLAIN执行计划中要重点关注哪些要素

导读

EXPLAIN的结果中,有哪些关键信息值得注意呢?

MySQL的EXPLAIN当然和ORACLE的没法比,不过我们从它输出的结果中,也可以得到很多有用的信息。

总的来说,我们只需要关注结果中的几列:

列名 备注
type 本次查询表联接类型,从这里可以看到本次查询大概的效率
key 最终选择的索引,如果没有索引的话,本次查询效率通常很差
key_len 本次查询用于结果过滤的索引实际长度,参见另一篇分享(FAQ系列-解读EXPLAIN执行计划中的key_len
rows 预计需要扫描的记录数,预计需要扫描的记录数越小越好
Extra 额外附加信息,主要确认是否出现 Using filesort、Using temporary 这两种情况

首先看下 type 有几种结果,分别表示什么意思:

类型 备注
ALL 执行full table scan,这事最差的一种方式
index 执行full index scan,并且可以通过索引完成结果扫描并且直接从索引中取的想要的结果数据,也就是可以避免回表,比ALL略好,因为索引文件通常比全部数据要来的小
range 利用索引进行范围查询,比index略好
index_subquery 子查询中可以用到索引
unique_subquery 子查询中可以用到唯一索引,效率比 index_subquery 更高些
index_merge 可以利用index merge特性用到多个索引,提高查询效率
ref_or_null 表连接类型是ref,但进行扫描的索引列中可能包含NULL值
fulltext 全文检索
ref 基于索引的等值查询,或者表间等值连接
eq_ref 表连接时基于主键或非NULL的唯一索引完成扫描,比ref略好
const 基于主键或唯一索引唯一值查询,最多返回一条结果,比eq_ref略好
system 查询对象表只有一行数据,这是最好的情况

上面几种情况,从上到下一次是最差到最好

再来看下Extra列中需要注意出现的几种情况:

关键字 备注
Using filesort 将用外部排序而不是按照索引顺序排列结果,数据较少时从内存排序,否则需要在磁盘完成排序,代价非常高,需要添加合适的索引
Using temporary 需要创建一个临时表来存储结果,这通常发生在对没有索引的列进行GROUP BY时,或者ORDER BY里的列不都在索引里,需要添加合适的索引
Using index 表示MySQL使用覆盖索引避免全表扫描,不需要再到表中进行二次查找数据,这是比较好的结果之一。注意不要和type中的index类型混淆
Using where 通常是进行了全表/全索引扫描后再用WHERE子句完成结果过滤,需要添加合适的索引
Impossible WHERE 对Where子句判断的结果总是false而不能选择任何数据,例如where 1=0,无需过多关注
Select tables optimized away 使用某些聚合函数来访问存在索引的某个字段时,优化器会通过索引直接一次定位到所需要的数据行完成整个查询,例如MIN()\MAX(),这种也是比较好的结果之一

再说下,5.6开始支持optimizer trace功能,看样子在执行计划方面是要逐渐和ORACLE看齐 :)

 

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

 

FAQ系列 | MySQL索引之聚集索引

导读

在MySQL里,聚集索引和非聚集索引分别是什么意思,有什么区别?

在MySQL中,InnoDB引擎表是(聚集)索引组织表(clustered index organize table),而MyISAM引擎表则是堆组织表(heap organize table)。

也有人把聚集索引称为聚簇索引。

当然了,聚集索引的概念不是MySQL里特有的,其他数据库系统也同样有。

简言之,聚集索引是一种索引组织形式,索引的键值逻辑顺序决定了表数据行的物理存储顺序,而非聚集索引则就是普通索引了,仅仅只是对数据列创建相应的索引,不影响整个表的物理存储顺序。

我们先来看看两种存储形式的不同之处:
简单说,IOT表里数据物理存储顺序和主键索引的顺序一致,所以如果新增数据是离散的,会导致数据块趋于离散,而不是趋于顺序。而HOT表数据写入的顺序是按写入时间顺序存储的。
IOT表相比HOT表的优势是:

  • 范围查询效率更高;
  • 数据频繁更新(聚集索引本身不更新)时,更不容易产生碎片;
  • 特别适合有一小部分热点数据频繁读写的场景;
  • 通过主键访问数据时快速可达;

IOT表的不足则有:

  • 数据变化如果是离散为主的话,那么效率会比HOT表差;

HOT表的不足有:

  • 索引回表读开销很大;
  • 大部分数据读取时随机的,无法保证被顺序读取,开销大;

每张InnoDB表只能创建一个聚集索引,聚集索引可以由一列或多列组成。

上面说过,InnoDB是聚集索引组织表,它的聚集索引选择规则是这样的:

  1. 首先选择显式定义的主键索引做为聚集索引;
  2. 如果没有,则选择第一个不允许NULL的唯一索引;
  3. 还是没有的话,就采用InnoDB引擎内置的ROWID作为聚集索引;

我们来看看InnoDB主键索引的示意图:

图片来自高性能MySQL

可以看到,在这个索引结构的叶子节点中,节点key值是主键的值,而节点的value则存储其余列数据,以及额外的ROWID、rollback pointer、trx id等信息。

结合这个图,以及上面所述,我们可以知道:在InnoDB表中,其聚集索引相当于整张表,而整张表也是聚集索引。主键必然是聚集索引,而聚集索引则未必是主键

MyISAM是堆组织表,它没有聚集索引的概念。

 

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

 

FAQ系列 | 解读EXPLAIN执行计划中的key_len

导读

EXPLAIN中的key_len一列表示什么意思,该如何解读?

EXPLAIN执行计划中有一列 key_len 用于表示本次查询中,所选择的索引长度有多少字节,通常我们可借此判断联合索引有多少列被选择了。

在这里 key_len 大小的计算规则是:

  • 一般地,key_len 等于索引列类型字节长度,例如int类型为4-bytes,bigint为8-bytes;
  • 如果是字符串类型,还需要同时考虑字符集因素,例如:CHAR(30) UTF8则key_len至少是90-bytes;
  • 若该列类型定义时允许NULL,其key_len还需要再加 1-bytes;
  • 若该列类型为变长类型,例如 VARCHAR(TEXT\BLOB不允许整列创建索引,如果创建部分索引,也被视为动态列类型),其key_len还需要再加 2-bytes;

综上,看下面几个例子:

列类型 key_len 备注
id int key_len = 4+1 = 5 允许NULL,加1-byte
id int not null key_len = 4 不允许NULL
user char(30) utf8 key_len = 30*3+1 允许NULL
user varchar(30) not null utf8 key_len = 30*3+2 动态列类型,加2-bytes
user varchar(30) utf8 key_len = 30*3+2+1 动态列类型,加2-bytes;允许NULL,再加1-byte
detail text(10) utf8 key_len = 30*3+2+1 TEXT列截取部分,被视为动态列类型,加2-bytes;且允许NULL

备注,key_len 只指示了WHERE中用于条件过滤时被选中的索引列,是不包含 ORDER BY/GROUP BY 这部分被选中的索引列。
例如,有个联合索引 idx1(c1, c2, c3),3个列均是INT NOT NULL,那么下面的这个SQL执行计划中,key_len的值是8而不是12:

SELECT…WHERE c1=? AND c2=? ORDER BY c1;

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

FAQ系列 | 磁盘空间满了之后MySQL会怎样

导读

当磁盘空间爆满后,MySQL会发生什么事呢?又应该怎么应对?

会发生什么事

当磁盘空间写满了之后,MySQL是无法再写入任何数据的,包括对表数据的写入,以及binlog、binlog-index等文件。
当然了,因为InnoDB是可以把脏数据先放在内存里,所以不会立刻表现出来无法写入,除非开启了binlog,写入请求才会被阻塞。

当MySQL检测到磁盘空间满了,它会:

  • 每分钟:检查空间是否得到释放,以便写入新数据。当发现有剩余空间了,就会继续写入数据,一切照旧。
  • 每十分钟:如果还是发现没剩余空间,则会在日志中写入一条记录,报告磁盘空间满(这时候只写入几个字节还是够的)。

应该怎么办

那么,当发现磁盘空间满了之后,我们应该怎么处理呢,建议:

  • 提高监控系统检测频率,预防再次发生;
  • 及时删除不用的文件,释放空间;
  • 若有线程因磁盘满的问题被阻塞了,可先杀掉,等到下一分钟重新检测时它可能又可以正常工作了;
  • 可能因磁盘满导致某些线程被阻塞,引发其他线程也被阻塞,可把导致阻塞的线程杀掉,其他被阻塞的线程也就能继续工作了。

例外

有个例外的情况是:
当执行 REPAIR TABLE 或者 OPTIMIZE TABLE 操作时,或者执行完 LOAD DATA INFILEALTER TABLE 之后批量更新索引时,这些操作会创建临时文件,当执行这些操作过程中mysqld发现磁盘空间满了,就会把这个涉及到的表标记为crashed,删掉临时文件(除了 ALTER TABLE 操作,MySQL会放弃正在执行的操作,删除临时文件,释放磁盘空间)。

备注:当执行这些命令过程中mysqld进程被意外被杀掉的话,其所生成临时文件不会自动删除,需要手工删掉才能释放磁盘空间。

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠
 
 

[MySQL FAQ]系列 — 不同复制模式下,如何忽略某些binlog事件

导读

在MySQL复制中,如何忽略slave节点上发生的主键冲突、数据不存在等错误。

在MySQL复制中,如果slave节点上遇到错误,比如数据不存在或者主键冲突等错误时,想要忽略这些错误,可以采用以下几种方法:

1、未启用GTID模式时

只需通过设定 SQL_SLAVE_SKIP_COUNTER 的值,即可忽略一些复制事件。例如:

#需要先关闭SLAVE服务
root@imysql.com [test]> STOP SLAVE;

#忽略N个事件(event),通常一个SQL是一个事件
root@imysql.com [test]> SET SQL_SLAVE_SKIP_COUNTER=N;

#再次启动SLAVE服务
root@imysql.com [test]> START SLAVE;

2、启用GTID模式时

启用GTID,想要忽略某些错误事件就稍微麻烦一点点了。
首先,我们需要先查看当前SLAVE复制的进度:

mysql> SHOW SLAVE STATUS\G

从中看到,当前SLAVE复制的GTID进展是:

Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1062
Last_Error: …Duplicate…key ‘PRIMARY’, Error_code: 1062;…
Master_UUID: f2b6c829-9c87-11e4-84e8-deadeb54b599
Retrieved_Gtid_Set: 3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-33
Executed_Gtid_Set: 3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-31
Auto_Position: 1

从上面的信息可以看到,当前从MASTER取到了1-33的事务列表,并且已执行(看Executed_Gtid_Set)到了31这个事务GTID位置,在这下一个位置(32)上发生错误。

这时候,我们需要手工调整SLAVE已清除的GTID列表 GTID_PURGED,人为通知SLAVE哪些事务已经被清除了,后续可以忽略:

root@imysql.com [test]> STOP SLAVE;
root@imysql.com [test]> RESET MASTER;
root@imysql.com [test]> SET @@GLOBAL.GTID_PURGED = “3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-32”;
root@imysql.com [test]> START SLAVE;

上面这些命令的用意是,忽略 f2b6c829-9c87-11e4-84e8-deadeb54b599:32 这个GTID事务,下一次事务接着从 33 这个GTID开始,即可跳过上述错误。

3、无论是否启用GTID,使用pt-slave-restart工具

首先不得不说,percona toolkit工具集对DBA而言实在太方便了。pt-slave-restart工具的作用是监视某些特定的复制错误,然后忽略,并且再次启动SLAVE进程(Watch and restart MySQL replication after errors)。
简单用法示例:

#忽略所有1062错误,并再次启动SLAVE进程
[yejr@imysql.com ]# pt-slave-resetart -S./mysql.sock —error-numbers=1062

#检查到错误信息只要包含 test.yejr,就一概忽略,并再次启动 SLAVE 进程
[yejr@imysql.com ]# pt-slave-resetart -S./mysql.sock —error-text=”test.yejr”

综上,我们虽然可以利用工具来快速忽略复制错误,但还是要掌握如何人为忽略复制错误的方法,在没有工具的时候也能了然于胸。

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠