现象

Sysbench对MySQL进行压测, 并发数过大(>5k)时, Sysbench建立连接的步骤会超时.

猜想

猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.

验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.

检查环境

猜想失败, 回到常规的环境检查:

1. MySQL error log 未见异常.
2. syslog 未见异常.
3. tcpdump 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.
4. 自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响
…

前言

MySQL 5.6引入了GTID，每个事务都会产生一个GTID，我们可以通过验证主从GTID来验证主从数据的一致性。

为了叙述简便，定义一个量ALL_GTID: 表示某个数据库实例上 所有存在过的 或 将要存在的事务 的GTID（包括已经被purge掉的事务）。

在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID，可以确定需要补偿多少数据:

1. 在实例存活的情况，可以在实例状态中查询ALL_GTID。
2. 在实例崩溃的情况，无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

下面列举与ALL_GTID相关的变量。

与ALL_GTID相关的变量 Previous-GTIDs

Previous-GTIDs格式如下（环境为MySQL5.7，日志手动flush binary …

背景

创建文件及目录时，我们会对相关的权限有一定的要求，默认的可以通过系统的umask来控制。然而，在我们使用MySQL时，无论是开始使用前的初始化，还是MySQL实例启动后，创建的相关文件及目录，并不受umask控制，MySQL 默认创建出来的文件权限是0660，目录权限是0700，并且，在通过引入MySQL初始化相关的环境变量解决了这一问题后，在以不同的MySQL的启动方式启动实例后，创建的文件及目录的权限也不相同。以下，将从几个方面分别讨论。

umask对系统文件及目录的影响

以下是linux man-page中对umask的相关描述

DESCRIPTION         top
       umask() sets the calling process's file mode creation mask (umask) to
       mask & 0777 (i.e., only the file permission bits of mask are used),
       and returns the previous value of the mask.
       The umask is used by open(2), …

背景

建立MySQL的性能模型, 对 MySQL的服务器参数调优 和 容量规划 有很大意义.

性能模型指的是如何通过观测得到量化的性能数值, 并能对 环境调整造成的影响 进行准确的量化预测.

其中最简单的性能模型是使用单线程进行insert.

测试场景

1. MySQL 5.7.12
2. 主要测试 不同刷盘参数 对性能的影响, 使用以下三个场景:
   1. sync_binlog=1, innodb_flush_log_at_trx_commit=1, 简写为b1e1 (binlog-1-engine-1)
   2. sync_binlog=0, innodb_flush_log_at_trx_commit=1, 简写为b0e1
   3. sync_binlog=0, innodb_flush_log_at_trx_commit=0, 简写为b0e0

MySQL 环境搭建使用 MySQL sandbox, 对应三个场景的启动参数如下:
1. ./start --sync-binlog=1 --log-bin=bin …

背景

在保障MySQL高可用时, 数据零丢失是某些场景比较关心的指标, 一种常用的方案是用半同步插件并将超时时间调整的比较大. 这种用法可以保障一定场景内的数据零丢失, 不过会丧失一定运维性(需要实时监控半同步插件的状况, 不能简单地通过show slave status获取), 也会丧失一定的架构健壮性(需要考虑备机故障时将高可用性降级, 维持业务连续性).

除了上面的特性丧失, 还有一个比较稀有的场景需要考虑, 就是网络的健壮性.

测试背景是MySQL 5.7.12.

半同步流程简述

MySQL组提交分为三个阶段:
1. Flush (将待提交事务的日志写入cache)
2. Sync (将待提交事务的日志cache刷盘)
3. Commit (将待提交事务提交, 更新存储引擎/更新GTID等)

每个阶段由一个leader线程负责, …

Systemtap

MySQL 支持 Dtrace probe, 即提供了一些Dtrace用的有用的观测点(probe). Systemtap同样也可以利用这些观测点, 可以作为一种低成本的观测MySQL的手段.

常用的几种观测点:
1. function, 可以观测函数的访问/返回
2. statement, 可以直接观测源码中的某一行
3. marker, 由源码提供的观测点

日常常用的是function和marker. 尤其是marker, MySQL源码提供的观测点对于学习MySQL行为有所帮助.

Systemtap 观测点的支持程度 官方编译的MySQL 5.7.11

官方编译的MySQL支持function观测点

> stap -L …