MySQL高可用架构设计方案
2. 风险评估
2.1.高可用环境
高可用（High Availability）有两种不同的含义，在广义环境中，是指整个系统的高可用特性，在狭义方面，一般指主机的冗余接管，如主机HA。我们目前的产品及相关系统平台主要都倾向于广义上的高可用。一个良好的高可用环境，不仅仅能避免系统本身的问题，还能防止天灾人祸，并且有一个简单可靠的系统维护方法，同时能在最小的成本资源下产生最大的效益。
高可用的计算方法一般以年在线率来计算，例如规定整个系统一年之中的可用环境要达
到99.95%，那么24*365*（1-99.95%）= 4.38小时（包括计划内维护时间）。另外，子系统的可用性一定会高于整个系统的可用性，如整个系统的可用性为99.95%，则对于子系统，可用性可能就是要求达到99.999%。
可用性级别 = 计划外与计划内停机可用性级别99.999?.99?.9?.0?.0%图 2-1 高可用级别对照表
在实际产品开发中，很难达到100%的在线能力，即使真的达到，代价会非常大。一般能达到99.9%以上的可用性的环境，都可以认为是比较高的可用环境。
每年停机时间5分钟53分钟8.8小时87.6小时438小时 MySQL高可用架构设计方案
成本高可用环境成本业务中断损失在线率99.0?.9?.95?.99?.999%
图 2-2 收益与成本
在公司收益与投入成本计算方面取得一个平衡，则是最终所希望的在线效率，但是收益与成本的计算方法则是决策者与实施者需要着重考虑的问题，适合自己的高可用环境即是最好的，不能盲目地追逐过高的可用性。
2.2.主要风险
在一个高可用的环境中，会遇到各种风险，主要的风险如下 ??系统失败或崩溃（System faults and crashes）
??应用层或中间层错误（Application and middleware failures） ??网络失败（Network failures）
??介质失效，一般指存放数据的媒体介质故障（Media failures） ??人为失误（Human Error）
??分级与容灾（Disasters and extended outages）
??计划宕机与维护（Planned downtime, maintenance and management tasks）
MySQL高可用架构设计方案
2.3.面临的主要问题
使用MySQL+PC服务器来构建高可用的MySQL集群会遇到一些主要的问题，这些问题如果忽略了或者没有去解决好，是会对高可用造成影响的，设置直接影响到整个产品及系统的稳定运行。
??MySQL会丢数据吗 ??MySQL自身的稳定性怎么样 ??MySQL的性能怎么样 ??MySQL如何快速自动切换 ??MySQL如何进行可靠的容灾 ??MySQL主备库数据的一致性校验 ??MySQL备库同步延迟，备库跟不上主库 ??MySQL在线DDL锁表（阻塞写）怎么解决
??相比商业软件成熟的解决方案，MySQL+PC架构其高可用性如何保证
MySQL高可用架构设计方案
3. MySQL数据可靠性
3.1.背景
??MySQL实例Down掉会不会丢数据
??MySQL服务器Down掉（比如断电、CPU、内存损坏等）会不会丢数据 ??硬盘坏掉会不会丢数据
说明：MySQL丢数据更多地是指，MySQL采用PC服务器，PC服务器存在硬件损坏的可
能性（比如CPU、内存、硬盘坏掉），从而导致丢数据。
3.2.解决方案
1、传统思路?
共享存储
2、非共享存储思路
可以分开对MySQL和应用两个方面进行一定的设置和处理，相当于是双保险的方
式，使数据不丢失。 对于MySQL
??设置innodb_flush_log_at_trx_commit = 1
设置为1：每个事务日志都Flush到磁盘
设置为2：每个事务刷到log file中，每秒Flush 到磁盘 ??设置sync_binlog = 1
设置为0：事务提交后，MySQL不做fsync之类的磁盘同步命令刷新binlog_cache
中的数据到磁盘，而让文件系统自行决定什么时候同步，或Cache满了 后才同步到磁盘。
设置为1：事务提交后，MySQL会将binlog_cache中的数据强制写入磁盘，是最安
全的设置。
??设置innodb_support_xa = true
MySQL高可用架构设计方案
设置为1：是否支持分布式事务（默认是打开） 设置为0：不支持分布式事务
如果确认应用中不需要使用分布式事务，可关闭该参数
??Slave远程binlog
通过Slave来保证数据不丢失，binlog实时传送到远程Slave，如果主备库之间的网
络较好的话，一般的（依赖于RTT），备库的时间基本上在毫秒之内。
??半同步复制（Semi-Sync）
半同步复制总体上可以保证数据的零丢失，但是可能对性能会有少许影响，会造成
约20%的TPS下降。 说明：
1、innodb_flush_log_at_trx_commit、sync_binlog、 innodb_support_xa 三个参数的设置在保证数据安全性和可靠性的同时，对性能是有一定的牺牲的。
innodb_flush_log_at_trx_commit、sync_binlog都为0时，性能比其中一个设置为1高出约几百倍；
innodb_flush_log_at_trx_commit、sync_binlog都为1时，性能比其中一个设置为1相差约几倍；
sync_binlog为0和1时的系统写入性能差距可能会达到5倍或更多 对于应用
??应用双写（写两份）
应用将同一记录写两份到不同的库中 ??应用通过记录log来实现
可以通过应用程序（Java、C++）自己写独立的日志来记录数据，也可以通过开源的消息中间件来实现日志记录。