诊断系统

监控图
• 实例数/运维人数 > 20 还能依赖人工？

实例诊断 卡慢诊断


全链路诊断
迭代的矛盾

云服务特点
• “最强测试”—用户

存储过程中用prepare语法创建三层视图 使用MyISAM引擎，在scheduler中使用事务语法 存储过程中死循环无限申请内存
• “我买了RDS，MySQL的bug我就认为是 RDS的bug” • “我使用中没碰到问题，为什么要强制升级”
•
恢复到任意时间点

专治剁手
• 删错库/表了！ • U/D忘记where

备份
• 定期全备 • 备份binlog
主备一致性

校验
• 常见校验方案 • 改进：利用主备复制机制

修复
• 按片检测，按片修复
主备一致性--利用主备复制机制

主库 insert into tmp (select … ) 等待备库复用
连接复用问题

流程
• • • • • 连接 创建 使用 用户关闭 放入链接池 再次连接 复用 使用

问题
• Kill connection

解决
• set connection id
高可靠
•
恢复到任意时间点
主备一致性 延迟问题 Crash数据不丢
•
•

问题
• Binlog格式 • warning日志问题
主备一致性—延迟问题

多线程复制 无主键表的问题
• Row格式 • 备库全表扫描 • 隐含主键

Crash数据不丢

主库能恢复自然不丢
• 恢复时间不可控

切换
• 直接切成备库就可以吗？ • 等备库执行完日志就可以吗？ • Semi-sync就可以吗？ • 我们的方案
迭代的矛盾



需要稳定，没问题的用户不想升级 需要迭代，有bug的用户必须升级 多租户 无法统一的“业务低峰” 升还是不升，这是个问题 我们的方案
• 单机多版本 • 按实例升级


一点感悟
人性化
谢谢
MySQL 云实践
@淘宝丁奇

基本结构 服务高可用 数据高可靠 运维成本 迭代的矛盾




基本结构—主备

常规一主一备 双M & 备库readonly 只读实例


高可用
高可用—切换闪断问题

用户只看见主库
• 主备保障数据安全 • 切换后继续使用

切换闪断
• 游戏用户痛点 • Proxy桥接方案
async
Master
Slave
•双通道（multi-source replication) •改造的semi-sync •数据补齐
运维成本
•
自动化
诊断系统
•
自动化

基本的自动化
• • • • 创建、删除 升级、迁移 备份、恢复 加锁、解锁

进一步的
• 备库自动修复 • 现场保留

一个有趣的投诉