数据库自动化运维平台--DDL平台服务
最近做了一个自认为很牛逼的平台，RD自助DDL操作，其实这种操作开放给RD自助执行是非常危险的，即便是DBA在做大表操DDL的时候，都经常会出现一些状况，比如造成锁等待，连接打满，主从延迟等。
其实这部分只要用对工具，把特殊情况考虑到，也是可以做成服务开放出去的。
先来了解下目前在线DDL的几种方式以及优缺点
1, 通过InnoDB在线online功能
2, 通过pt-online-schema-change工具
第一种方式，InnoBD的online功能也只是支持一部分DDL操作，有很多的DDL是不支持online的，具体相关内容这里不展开。即便是能online的操作，也是有很多其他问题，二进制文件中的日志把修改操作序列化了，从库应用日志时会导致复制延迟，而且DDL还是不可中断的，要是在修改时把操作杀掉的话还需要更长的时间去回滚，甚至导致数据字典崩溃。在系统负载高时也不能限速或者暂停。这样的操作还有可能会耗尽系统资源。
对应第二种方式，我们使用pt-online-schema-change很多年了。但每次更数据量比较大的表的时候，都会担心会发生什么，都是因为被它伤害过的，哈哈。有一些操作只敢在非业务高峰期或晚上凌晨几点钟。所有现有的在线修改表定义工具都是用MySQL触发器来迁移数据的，因此本身就存在着一些问题。触发器这种方式的缺点具体不展开了，要了解详细可以自行查询相关内容。
下面介绍下我们平台低层使用的技术gh-ost
这东东是什么东西呢，（port一部分内容） go-ost是gitHub's Online Schema Transmogrifier/Transfigurator/Transformer/Thingy的缩写，意思是GitHub的在线表定义转换器。它主要有以下特点：无触发器 轻量级 可暂停 动态可控 可审计 可测试 可靠。想要详细了解次工具，请自行查看相关资料。
部分截图展示
1）, 任务提交页面
2) 提交任务，并验证任务
对于用户提交的alter操作进行任务验证是很有必要的，比如用户权限，SQL语法，一个表的操作多条sql是否合并成一条SQL，SQL是否符合审核规范，比如字段备注，索引长度，索引名字等。
这个就是SQL有问题导致的提交失败
这个是因为表没有主键提交失败
。。。。等等，更多情况不再列出。
3) 能正确提交的会生成任务列表
4) 进入任务id连接 可以做大部分任务的操作
主要有三种操作类型：执行任务， 临时暂停任务，取消任务(只要任务没完成都可以取消，对数据库没有太大影响) ，其中审核部分，后期会接入审核流系统。
5) 执行任务
点击执行后能在面板上看到很多的信息：
执行耗时：这条任务已经执行的时间。
剩余时间：预计还需要多长时间。
堆积状态：数据库压力比较大，生成的binlog比较多的时候，可能会出现应用处理binlog堆积，比如：1000/1000 此时任务会自动 暂停
执行状态：这里能看到大部分的实时状态信息，比如，正在拷贝数据，由于数据库压力大，或者延迟等原因任务暂停保护。失败，成功，任务取消等信息。
错误信息：如果任务执行的过程中发生错误，在这里会实时显示出来。
数据行进度：第一个数字是已经拷贝的行数，第二个数字是表的总行数。
百分比进度：进度条方式显示进度。
已经执行完成。
这条任务执行的时候有错误发生
可以查看错误信息，这个信息是说alter最后阶段rename之前获得锁的时候超时，这时候应该是表上有长事务造成的。
6) 取消或暂停任务
任务已暂停，并且对数据库基本没影响
运行的过程中随时暂停，这里是手动触发暂停，如果数据库压力threads_running ，延迟等原因 会自动暂停。
可能遇到的问题：
1) binlo*生过多出现堆积情况
当负载变高时，gh-ost无法跟上二进制日志处理 ,gh-ost的未来版本可以通过并行应用binlog事件来改善这个问题
2) 长事务造成的切表问题
被修改的表上如果有长事务存在，就造成ghost频繁的尝试加锁，这样间歇性的对后面查询造成影响。这里如果发现有这种锁频繁超时问题，就会自动设置成延迟切表，这样不会对线上造成大的影响。
3) 拷贝期间出现锁等待
执行状态显示正在拷贝数据，但那时进度条长时间没有变化，这种情况一般是等待行上面的锁释放，因为拷贝是当前读，
如果行上面有写锁的话会一直等待写锁释放，最终可能锁等待超时。不过这里不会对数据库造成坏的影响。
4)负载高自动暂停
如果数据库负载比较大，任务会自动暂停，以保护数据库的可用性。另一个场景是延迟
达到阈值的时候也会暂停拷贝。
到这里主要功能 介绍的差不多了， 对于权限控制，执行时间控制（高峰的时候禁止使用平台操作）等 这里就不展示了。