问题描述

收到一枚RDS TokuDB实例crash导致HA切换的报警，上去一看错误如下：

1
2
3
4
5
6
7
8
9
10
11

tokudb/ft-index/ft/cachetable/cachetable.cc toku_cachetable_openfd_with_filenum: Assertion `filenum.fileid != FILENUM_NONE.fileid' failed
/bin/mysqld(_Z19db_env_do_backtraceP8_IO_FILE+0x1b)[0xc57ddb]
/bin/mysqld(_Z35toku_cachetable_openfd_with_filenumPP9cachefileP10cachetableiPKc7FILENUMPb+0x223)[0xbb49b3]
/bin/mysqld(_Z19toku_ft_handle_openP9ft_handlePKciiP10cachetableP7tokutxn+0x135)[0xbf3c05]
/bin/mysqld(_Z20toku_ft_handle_clonePP9ft_handleS0_P7tokutxn+0xb5)[0xbf42f5]
/bin/mysqld(_Z29toku_db_lt_on_create_callbackPN4toku8locktreeEPv+0x2a)[0xb801ba]
/bin/mysqld(_Z18toku_db_open_inameP9__toku_dbP13__toku_db_txnPKcji+0x276)[0xb805b6]
/bin/mysqld(_ZN9ha_tokudb20open_main_dictionaryEPKcbP13__toku_db_txn+0x1ab)[0xb50a0b]
/bin/mysqld(_ZN9ha_tokudb16initialize_shareEPKci+0x2c8)[0xb70848]
/bin/mysqld(_ZN9ha_tokudb4openEPKcij+0x5e9)[0xb71349]
/bin/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x33)[0x5e74b3]

这个错误信息在RDS上第一次碰到，隐隐感到这是一个“可遇不可求”的bug导致，开始捉虫。

表定义

MySQL的表包含表名，表空间、索引、列、约束等信息，这些表的元数据我们暂且称为表定义信息。 对于InnoDB来说，MySQL在server层和engine层都有表定义信息。server层的表定义记录在frm文件中，而InnoDB层的表定义信息存储在InnoDB系统表中。例如:

1
2
3
4
5
6
7
8
9

InnoDB_SYS_DATAFILES
InnoDB_SYS_TABLESTATS
InnoDB_SYS_INDEXES
InnoDB_SYS_FIELDS
InnoDB_SYS_TABLESPACES
InnoDB_SYS_FOREIGN_COLS
InnoDB_SYS_FOREIGN
InnoDB_SYS_TABLES
InnoDB_SYS_COLUMNS

背景

我们知道MySQL的主备同步是通过binlog在备库重放进行的，IO线程把主库binlog拉过去存入relaylog，然后SQL线程重放 relaylog 中的event，然而这种模式有一个问题就是SQL线程只有一个，在主库压力大的时候，备库单个SQL线程是跑不过主库的多个用户线程的，这样备库延迟是不可避免的。为了解决这种n对1造成的备库延迟问题，5.6 引入了并行复制机制，即SQL线程在执行的时候可以并发跑。

关于其背后的设计思想，可以参考这几个worklog WL#4648，WL#5563，WL#5569，WL#5754，WL#5599，之前的月报也对并行复制原理进程了阐述，读者朋友可以回顾下。

本篇将从代码实现角度讲述并行复制是如何做的，分析基于MySQL 5.6.26。

背景

最近在Aliyun RDS的环境上，有些用户碰到了打开文件句柄数过多的错误，查看用户实例的打开句柄个数，确实超过了系统设置的值，一旦出现了这种错误，将会带来连锁的各种错误(取决于当时正在操作什么类型的文件，以及什么操作)。下面，我们就一起来看一下MySQL在操作过程中，牵涉到文件打开和关闭的关键点，以及你一直以来可能存在的认识误区。

介绍

当你对InnoDB进行修改操作时，例如删除一些行，这些行只是被标记为“已删除”，而不是真的从索引中物理删除了，因而空间也没有真的被释放回收。InnoDB的Purge线程会异步的来清理这些没用的索引键和行，但是依然没有把这些释放出来的空间还给操作系统重新使用，因而会导致页面中存在很多空洞。如果表结构中包含动态长度字段，那么这些空洞甚至可能不能被InnoDB重新用来存新的行，因为空间空间长度不足。 有些用户可能会使用 OPTIMIZE TABLE 或者 ALTER TABLE \

最近上游发布了MySQL 5.6.26版本，从Release Note来看，MySQL 5.6版本已经相当成熟，fix的bug数越来越少了。本文主要分析releae note上fix的相关bug，去除performance scheama、mac及windows平台、企业版、package相关内容。从本期开始，我们会在新版本发布时，在当月的月报上为大家做详细的版本Release Note分析。

背景：Punch hole和Sparse file

Punch hole是一个需要操作系统和文件系统支持的特性，顾名思义就是在文件中打洞。这个特性的目的是为了减少数据文件的磁盘开销。比如一个大文件中有一部分数据我们是不需要的，就可以通过punch hole特性将其删除，相当于在文件中打了个洞，这个洞是不占用磁盘的。

Punch hole特性通过fallocate调用来实现，在其第二个参数指定flag FALLOC_FL_PUNCH_HOLE时，第三个参数指定需要punch hole的偏移位置，第四个参数指定punch hole的长度。当成功打洞后，以后访问到这个范围的数据都返回0。

背景

我们执行一个大SQL时（长度大于512M），会返回如下错误：

1

ERROR: invalid memory alloc request size 1073741824

问题现象

最近我们的几个非生产实例中，均出现了由archiver进程产生的core dump文件，让人如临大敌：是不是遇到了PG的大BUG导致了crash？

先来看看这些core文件。由于我们在/proc/sys/kernel/core_pattern指定了存放core文件的目录，所以可以在这个目录里面找到这些core文件。幸运的是，这些core文件都不大，一般几百KB，没有对文件系统的存储空间造成压力：

1
2
3
4

$du -sh *
248K    core.170254
248K    core.242719
248K    core.31624

背景

在RDS环境中，多租户使用同一台主机是很常见的事情，为了隔离用户资源，有很多手段，例如使用虚拟机，或者CGROUP技术。以CGROUP为例，可以控制进程的CPU使用、内存使用、块设备的IOPS或者吞吐速率等资源使用。限制资源的好处是可以在共用的硬件层面为多个用户提供承诺的性能指标。当然这种方法也有一定的弊端，例如当用户需要运行消耗较多资源的SQL的时候，无法利用机器的空闲资源，因为它被限制住了。还有一些弊端可能导致RDS的不稳定，本文将展开讨论其中的弊端之一，资源限制是如何导致备库延迟的。