分享主题：《MySQL的高可用架构》，主要介绍MySQL双节点的高可用架构，着重分析这种架构存在的问题，如退化问题、数据重复执行问题，及数据不一致的问题等，并针对这些问题给出优化方案。
提示：PPT的内容有限，建议直接观看视频，效果更佳！
本次公开课的PPT、视频均已上传到百度云盘，链接: https://pan.baidu.com/s/1c25Y9nM。扫描下方二维码识别，或者点击文末“阅读原文”直达链接，欢迎转存及转发。
1、王老师 ,您好, 我想问一下" 在公有云环境中, 如果master宕了, 如何实现自动切换,自动把slave提升为master?"
答： 在公有云上大多采用双主双向复制结构，但同时只有一个节点写入，前端基于Proxy对外提供服务。
当写节点发生故障时，只需在Proxy上把写切到另一个库上即可（切换前需检查双主一致性、延迟等情况）。
而Proxy提供高可用，通常是基于VIP实现。
2、王老师，可以详细说下 VIP proxy 实现切换？
答：VIP切换通常是基于keepalived的VRRP协议实现，但这种受限于协议，通常在云服务器环境中没办法使用，只能在自有服务器上实现。
在云环境中更多的使用基于raft或是多数据的选举实现的VIP切换。
3、数据库很大，怎么有效的添加索引，有什么工具？谢谢老师。
答：现在MySQL 5.7的Online DDL已经很好用了，不过还是建议先做下调研测试，看看有没有意外情况（一些特定例外情况下，可能没办法做到Online DDL）。
另外，在主从复制环境中，直接Online DDL可能会造成主从延迟比较厉害。为了避免这种延迟一般还是使用pt-online-schema-change来做大表DDL（实际上pt-osc也会造成延迟，只是没那么严重，也需要注意），或者用gh-ost以及facebook前阵子开源的OnlineSchemaChange工具（以前用PHP写的，后来用Python重写）。
4、360的atlas做这个主从用起来怎么样？建议用么？
答： 现在360的atlas已经没人维护。
可以考虑美团维护的那版DBproxy，这个Proxy更多强调的分库分表，智能读写分离。
5、初级问题求回答：一主双从架构mysql5.5，其中某一台slave修改了参数，要重启，需要先stop slave吗？
答： 是的，建议重启前先把复制停掉（stop slave），然后再重启实例。
6、半同步复制的binlog，是先dump 到slave以后，自己这边才写到binlog文件里面的吧。否则 master dump 到slave之前，并且自己又写入到了binlog，那不是妥妥的master 多执行event了？
答：你的理解基本没错，实际上肯定不用担心master端会写多次binlog的情况。
复制分为 异步复制（什么也不保证），半同步，After_sync(主库先写日志，保证从库IO_thread响应后，再进行引擎的Commit，给client响应），After_commit(引擎层提交后，待io_thread给响应后，才给Client响应）。 所以存在写多的情况， 但通过after_sync设置可以保持一致。
7、 主从同步没问题。这个vip proxy用什么软件靠谱点？
答：vip是虚拟IP，它和proxy（主）的网卡绑定，方便外部的账户通过这个IP来访问。
如果当前proxy（主）挂掉了，proxy进行了切换，那这时使用这个IP再绑定新的proxy（备）的网卡。
这样做的目的是对于使用这个数据库的人来说，即使proxy发生了宕机，发生了切换，业务方面也不需要修改IP就能继续访问数据库。
具体的实现方式以及使用方式可以咨询一下网络相关的同事或者同学。
Proxy在ucloud是使用haproxy做为前端，如果只为了简单的双主路由的话，选简单的haproxy、mysql proxy这类proxy即可，这些都是开源的。
如果需要复杂的功能，比如自动的容灾切换，或者读写分离的功能，可以选功更复杂的mha、mycat这类，这些也都是开源的。
当然也可以选择没有开源的有售后保证的，比如oracle官方的router。
8、 主从复制延迟是，slave的slave_io_thread出现system lock或者
slave_sql_thread出现system lock，为什么会出现system lock？
答：当线程处于system lock时，通常是在等待表级锁，但是引起这个状态的原因比较多，需要具体的情况具体分析，可以参考手册：
https://dev.mysql.com/doc/refman/5.7/en//general-thread-states.html
9、 Mysql主要延迟的原因有哪些？
答：复制的延迟主要体现在sql线程回放的速度上，通常IO线程不会存在延迟问题，Sql线程产生复制延迟的主要原因是：
Sql线程对于relay log的回放速度慢于主库事务的执行速度（5.6之前的版本较为明显）
执行较长的事务，如在一个事务中批量的导数据执行较慢的的DDL语句。
10、 io线程是把binlog写入到relay log中，这个relay log是fsync到磁盘才发给主库ack么，还是写到内存就可以了？
答：relay log是否执行fsync到磁盘受参数sync_relay_log影响，同参数
sync_binlog_log对binlog是否执行fsync到磁盘的影响类似。
如果sync_relay_log设置为1，那么每次写入event到relay log后均会执行fsync，发送给主库ack是一个事务（多个event）写入relay log后。
11、短时间内大量DDL操作，是否有方法避免主从延迟发生？
答：可以在不影响业务的前提下，关掉session的binlog主从同时执行。
12、Ucloud的高可用方案是怎么做的？
答：Zk + haproxy + mysql节点。
13、MySQL有没有基于共享存储这种方式做高可用的解决方案？
答：使用共享存储做高可用的解决方案，相当于使用硬件来解决数据同步的问题，如早一些的SAN、NFS，比较新Aurora数据库都是基于共享存储。
14、MHA现在过时么？group replication目前有没有成熟的案例？
答：现在使用MHA的仍然在使用，因为MHA是开源的，很多公司会维护自己版本的MHA。也有公司在MHA基础上寻找新的解决方案，比如说MHA+group replication这种架构。
毕竟group replication还比较新，处于观望、或者研发状态的会比较多。官方的innodb cluster是官方推出的基础group replication的产品，感兴趣可以研究一下。
关于知数堂
http://zhishuedu.com
“知数堂培训”是由资深MySQL专家叶金荣、吴炳锡联合推出专业优质在线培训品牌，当前主要有MySQL DBA实战优化、Python运维开发、SQL优化等多门优质课程，是业内最有品质的培训课程。
