《MySQL高可架构设计方案》由会员分享，可在线阅读，更多相关《MySQL高可架构设计方案（31页珍藏版）》请在金锄头文库上搜索。
1、MySQL高可架构设计方案2.1. 高可用环境高可用（ High Availability）有两种不同的含义，在广义环境中，是指整个系统的高可用特性，在狭义方面，一般指主机的冗余接管，如主机HA。我们目前的产品及相关系统平台主要都倾向于广义上的高可用。一个良好的高可用环境，不仅仅能避免系统本身的问题，还能防止天灾人祸，并且有一个简单可靠的系统维护方法，同时能在最小的成本资源下产生最大的效益。高可用的计算方法一般以年在线率来计算，例如规定整个系统一年之中的可用环境要达到 99.95%，那么 24*365* （ 1-99.95% ） = 4.38 小时（包括计划内维护时间）。另外，子系统的可用性一
2、定会高于整个系统的可用性，如整个系统的可用性为99.95%，则对于子系统，可用性可能就是要求达到99.999%。可用性级别 = 计划外与计划内停机可用性级别每年停机时间99.999%分钟599.99%53分钟99.9%小时8.899.0%87.6小时95.0%小时438图2-1高可用级别对照表在实际产品开发中，很难达到100%的在线能力，即使真的达到，代价会非常大。一般能达到99.9%以上的可用性的环境，都可以认为是比较高的可用环境。成本高可用环境成本业务中断损失在线率99.0%99.9%99.95%99.99%99.999%图 2-2 收益与成本在公司收益与投入成本计算方面取得一个平衡，则是
3、最终所希望的在线效率， 但是收益与成本的计算方法则是决策者与实施者需要着重考虑的问题，适合自己的高可用环境即是最好的，不能盲目地追逐过高的可用性。2.2. 主要风险在一个高可用的环境中，会遇到各种风险，主要的风险如下系统失败或崩溃（ System faults and crashes）?应用层或中间层错误（ Application and middleware failures）网络失败 （ Network failures）介质失效，一般指存放数据的媒体介质故障（ Media failures）人为失误 （ Human Error）分级与容灾 （ Disasters and extended
4、 outages）计划宕机与维护（ Planned downtime, maintenance and management tasks）2.3. 面临的主要问题使用 MySQL+PC服务器来构建高可用的MySQL集群会遇到一些主要的问题，这些问题如果忽略了或者没有去解决好，是会对高可用造成影响的，设置直接影响到整个产品及系统的稳定运行。MySQL会丢数据吗MySQL自身的稳定性怎么样MySQL的性能怎么样MySQL如何快速自动切换MySQL如何进行可靠的容灾MySQL主备库数据的一致性校验MySQL备库同步延迟，备库跟不上主库MySQL在线 DDL锁表（阻塞写）怎么解决相比商业软件成熟的解决
5、方案，MySQL+PC架构其高可用性如何保证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 =
6、 1设置为 1：每个事务日志都Flush 到磁盘设置为 2：每个事务刷到log file中，每秒Flush到磁盘设置 sync_binlog = 1设置为 0：事务提交后， MySQL不做 fsync 之类的磁盘同步命令刷新binlog_cache中的数据到磁盘，而让文件系统自行决定什么时候同步，或Cache 满了后才同步到磁盘。设置为 1：事务提交后， MySQL会将 binlog_cache中的数据强制写入磁盘，是最安全的设置。设置 innodb_support_xa = true设置为 1：是否支持分布式事务（默认是打开）设置为 0：不支持分布式事务如果确认应用中不需要使用分布式事务，可
7、关闭该参数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、 sy
8、nc_binlog都为 0 时，性能比其中一个设置为1高出约几百倍；innodb_flush_log_at_trx_commit、 sync_binlog都为 1 时，性能比其中一个设置为1相差约几倍；sync_binlog为 0 和 1 时的系统写入性能差距可能会达到5 倍或更多对于应用应用双写（写两份）应用将同一记录写两份到不同的库中应用通过记录log 来实现可以通过应用程序（Java 、C+）自己写独立的日志来记录数据，也可以通过开源的消息中间件来实现日志记录。4. MySQL 数据一致性4.1. 背景MySQL主库异常Down掉，会导致主备库之间的数据不一致MySQL主备切换后，备库成
9、为主库，数据存在不一致MySQL的逻辑复制理论上是有风险的，极端情况下可能存在主备数据不一致4.2. 解决方案4.2.1. 常规设置 innodb_flush_log_at_trx_commit = 1设置 sync_binlog = 1设置 innodb_support_xa = true半同步复制（ Semi-Sync ）主备库尽量采用row 模式复制，不要采用statement模式复制主备库定期数据一致性校验数据生命周期内的binlog尽量保存下来4.2.2. 主备切换Master 宕机后，有三个选择Slave 立即提供服务，存在数据不一致风险Slave 不提供服务，等待Master 恢
10、复，保证数据一致Slave 提供部分服务（比如只能新建，不允许修改），等待 Master 恢复后，保持数据一致对于我们的MySQL高可用环境，我们采用的处理策略1、Slave 立即提供服务2、Slave （旧）Master（新）3、Master （旧） Rollback4、Master （旧）Slave（新）5、Master （新） ReplayRollback & ReplayMasterSlaveRollbackReplayRollback Master 回滚，保持与 Slave 一致重新恢复主备复制关系ReplaySlave 重放，减少数据丢失冲突检测机制5. MySQL 容灾5.1.
11、背景互联网应用以普通的PC服务器为主通过业务功能的写入主库通常只有一个，造成单点意外操作 导致数据丢失会遇到不可抗力因素或异常导致宕机5.2. 解决方案writeApp分布式数据中间层writeRemi-SyncMasterSlaveread-only = offRemi-SyncSlave2应用写入数据时，记录应用日志，日志可以用来恢复丢失的数据MySQL复制模式是M-M-S，切换时只需修改read-onlyMySQL主从采用半同步复制（Remi-Sync ）Slave 作为备库， Slave2 也是备库，作为容灾库6. MySQL 自动切换6.1. 背景互联网应用以普通的PC服务器为主MySQL的主库 Down掉后，需要保持提供高可用的服务人工调整切换时间太长多个 MySQL的主库 Down掉后，需要及时切换6.2. 解决方案6.2.1. 架构方式1、整体架构AppSwitch
