背景

建立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 …