事件背景
晚上11点通过数据库sql审核平台（yearning）进行表结构变更，变更类型为在线添加字段。待添加表大约130万行，执行工具为在线ddl工具 pt-online-schema-change
，执行后发生整个数据库集群hang住，无法对外提供服务。
系统架构
生产数据库集群为mariadb-galera集群，共计5台，其中1台做为写节点，其他节点为读节点。整体架构图如下
公司使用该集群为历史遗留问题，初步判断当时创建该集群是为了防止单节点故障，毕竟5台节点都是主节点，都可以写入。
事件过程
- 11:25开始执行添加索引的sql,此时Prometheus已经存在部分告警，但是我认为是性能抖动，就忽略此次告警了
- 11：45开始执行添加字段操作，执行完成后，接口的ELK告警频发，当时已经知道是出故障了。
- 11：46开始检查数据库负载，发现load1 比平时高了3倍左右
- 11：47 此时尝试kill 添加字段的sql线程，但是一直提示root不是这个线程的主人，无法KILL
- 11：50 此时尝试进行重启数据库来规避此问题，已经出现客户保障，运维领导开始介入
- 12：00 开始进行切数据库操作，把haproxy指向新的数据库集群（此集群为生产集群的备用集群）
事件造成影响
数据库集群不可用状态大概持续40min,公司依赖数据库的服务全部不可用，客户进行保障和投诉。
事件问题分析
sql执行如下：
alter table table add column col1 varchar(36) not null default '';
该表数据量并不大，只有130万，但是该表更新较为频繁，会频繁进行update，并且该表的查询会使用加锁的方式执行，
示例
select * from table where xxx=xxx for update;
本次sql执行时间为1000s,最后依然报错，后面在测试环境进行复盘，假如对于for update的表进行在线添加字段，
pt工具在insert会进行LOCK IN SHARE MODE 加锁操作，此锁和 for update锁产生冲突，导致元数据锁的产生。
后续解决方案：
- 生产环境执行ddl一定需要和开发同事沟通是否待操作的表更新频繁，是否使用锁，不可以认为小表操作一定安全。
- 新版本数据库支持 wait N 语法，假如在规定时间内未获取到锁，则自动回退，但是生产该参数设置较大，未能在规定时间内进行sql回滚
- 新版本数据库执行各类online-ddl算法（COPY，INPLACE，NOCOPY，INSTANT），使用指定算法进行在线表字段变更。
对于小表我们进行在线添加索引，如下为操作步骤：
show open tables where in_use >=1;
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
SET SESSION alter_algorithm='INSTANT';
ALTER TABLE xxx wait 10 ADD COLUMN xxx VARCHAR(36)
总结
- 对生产环境操作太随意，生产环境操作要加倍注意，尤其是数据库！
- 对于业务的了解太少，假如不发生此次故障，根本不知道一个130万的表更新和查询会非常频繁，只是想当然认为count才130万，执行应该很快
- 对于数据库参数的认识不足，lock_wait_timeout和innodb_lock_wait_timeout 等，假如故障那天这两个参数都设置为5s，就是发生锁冲突，和元数据锁，也会很快因为锁超时而回滚，而不是一直等待。
- 对于在线sql添加工具原理认识不足，使用工具需要充分学习其操作原理。
