周五晚上晚班，回来拾掇快到1点半才睡 ，早晨5点半起，从芳村赶去南站，坐上了7点半去深圳的高铁，8点40到达腾讯大厦门口， 多功能厅里面还是一片杂乱，似乎和之前的用户大会有些许不一样，没有各种赞助商的宣传牌，没有各种小礼品在门口堆砌， 也没有各种小吃， 各种阵仗，似乎这次要打的是一场技术的硬仗。一天下来，似乎也验证了这一开始的感受。 No1：去哪儿 周彦伟 从MNC到MGC再到MIC，三种集群方案听下来，感觉大同小异。 MNC集群中的三种角色，manager管理，data node 数据存储，sql node 语句merge 传送，是一种shard nothing结构， 不禁想起mycat的8066 9066和各个mysql节点node，有点相似哦。 不过MNC从2012年05月22日MySQL Cluster 7.2.6 GA 发布至今这么多年，这一集群架构还没有大范围使用并推广说明使用限制 还是很多。诸如，节点个数限制，内存成本较高， 各个数据节点内存只能使用节点中最下，节点间网络网络可靠性的依赖等等。 MGC在去哪儿应用应该是有几年了，记得去年7月份的时候在上海也听过去哪儿的某位工程师讲过这个集群相关的知识，不过总监还是 总监，给我的感觉就是周总对他们使用的MGC绝对的自信， 没有一点怀疑和动摇，去年那位工程师则或多或少透露出些许的不自信。特别是其中对集群DDL的执行，当时好像是特别的揪心的一个 痛点，也许是经过快一年的努力，已经解决了呢，嘿嘿！ MGC通过group communicate引擎实现各节点间的通讯，最终实现任意节点写入，全局依赖于事务发起到commit提交之前在各节 点间通讯以及处理来保证事务的各节点落入和一致性，有限制也能解决一些痛点问题， 像DDL和大事务的支持就是个大问题，像周老师说的，寸有所短尺有所长，适合的才是最好的。 MIC的route（proxy）感觉还是和其他的集群有些许差异的地方，shell manager和MIC的概念还是有点陌生，后面应该多翻翻 文档熟悉熟悉了。 最后列举了一下江湖上现有的集中集群方案，percona的PHX，MariaDB的集群方案，周总讲的详细的应该就是QunarDB了，模拟 redis的哨兵机制引入的主从状态监控的哨兵，以及zookeeper和连接池的设计虽然没有听太懂感觉也是厉害了我的自主研发。 No2 在线ddl 吴夏 tdsql内核开发 这是我见过年轻人里面为数不多的棒棒哒的的讲演人了！不慌不忙，有条有理，对自己要讲的清楚，对别人想知道的清晰， 不用看ppt。层层深入，不卡顿，不抢赶，佩服佩服，带个眼睛，T恤牛仔，一看就是文化人儿。。。 首先对比了mysql自身的onlinddl的发展，从5.5的FIC开始使用in-place的方式，再到5.6onlineddl，也就是使用缓存变更 期间的dml语句的方式，再到5.7的 alter table rename index 的新语法以及在线更改varchar长度的新方式。 algorithm的copy inplace和default三种值定义和lock 的default shard exclusive none 四种锁选择以及各个选择 搭配之后的优缺点讲的很易懂，总结的也很精辟，推荐使用inplcae+none的组合。 点了几个在平时使用原生onlineddl中注意的地方，删除和添加列的时候会使用到临时表空间，要保证空间足够；删除主键的时候 不会使用onlinddl的方式，会使用copy的方式，修改列的默认值和索引的有关操作相对来说是比较安全的。 其次就是两个工具pt以及gh的使用和注意规范以及和mysql原生规则的性能压测结果对比分析了。其中特别提到gh工具的binlog 解析方式对原表dml操作回放来保证原表不阻塞dml操作以及利用修改rename语句锁的优先级以及增加占位表来顺畅加锁和释放锁的过程 来控制rename过程不出现表不存在的错误的新奇方式。
