MySQL高可架构设计方案.docx

MySQL高可架构设计方案2.1.高可用环境高可用（High Availability）有两种不同的含义，在广义环境中，是指整个系统的高可用特性，在狭义方面，一般指主机的冗余接管，如主机HA。我们目前的产品及相关系统平台主要都倾向于广义上的高可用。一个良好的高可用环境，不仅仅能避免系统本身的问题，还能防止天灾人祸，并且有一个简单可靠的系统维护方法，同时能在最小的成本资源下产生最大的效益。高可用的计算方法一般以年在线率来计算，例如规定整个系统一年之中的可用环境要达到99.95%，那么24*365*（1-99.95%）= 4.38小时（包括计划内维护时间）。另外，子系统的可用性一定会高于整个系统的可用性，如整个系统的可用性为99.95%，则对于子系统，可用性可能就是要求达到99.999%。图 2-1 高可用级别对照表在实际产品开发中，很难达到100%的在线能力，即使真的达到，代价会非常大。一般能达到99.9%以上的可用性的环境，都可以认为是比较高的可用环境。图 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）2.3.面临的主要问题使用MySQL+PC服务器来构建高可用的MySQL集群会遇到一些主要的问题，这些问题如果忽略了或者没有去解决好，是会对高可用造成影响的，设置直接影响到整个产品及系统的稳定运行。 MySQL会丢数据吗 MySQL自身的稳定性怎么样 MySQL的性能怎么样 MySQL如何快速自动切换 MySQL如何进行可靠的容灾 MySQL主备库数据的一致性校验 MySQL备库同步延迟，备库跟不上主库 MySQL在线DDL锁表（阻塞写）怎么解决 相比商业软件成熟的解决方案，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 = 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：不支持分布式事务如果确认应用中不需要使用分布式事务，可关闭该参数 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+）自己写独立的日志来记录数据，也可以通过开源的消息中间件来实现日志记录。4. MySQL数据一致性4.1.背景 MySQL主库异常Down掉，会导致主备库之间的数据不一致 MySQL主备切换后，备库成为主库，数据存在不一致 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恢复，保证数据一致 Slave提供部分服务（比如只能新建，不允许修改），等待Master恢复后，保持数据一致对于我们的MySQL高可用环境，我们采用的处理策略1、Slave立即提供服务2、Slave（旧） Master（新）3、Master（旧）Rollback4、Master（旧） Slave（新）5、Master（新）ReplayRollback & Replay Rollback Master回滚，保持与Slave一致 重新恢复主备复制关系 Replay Slave重放，减少数据丢失 冲突检测机制5. MySQL容灾5.1.背景 互联网应用以普通的PC服务器为主 通过业务功能的写入主库通常只有一个，造成单点 意外操作导致数据丢失 会遇到不可抗力因素或异常导致宕机5.2.解决方案 应用写入数据时，记录应用日志，日志可以用来恢复丢失的数据 MySQL复制模式是M-M-S，切换时只需修改read-only MySQL主从采用半同步复制（Remi-Sync） Slave作为备库，Slave2也是备库，作为容灾库6. MySQL自动切换6.1.背景 互联网应用以普通的PC服务器为主 MySQL的主库Down掉后，需要保持提供高可用的服务 人工调整切换时间太长 多个MySQL的主库Down掉后，需要及时切换6.2.解决方案6.2.1.架构方式1、整体架构说明： Switch Manager是页面化操作管理切换，目前暂时不实现，采用App+动态数据源直接与Zookeeper进行通信。2、详细架构3、整体思路 主备库构成分布式环境，但是有状态 确保Agent可以重启，可以任意次重启，但是有超时限制 主库切换逻辑可以通过Zookeeper实现 锁的升级实现 切换时，MySQL的read-only的设置很重要 切换时，需要将异常的故障节点+App数据源一起切换1、首先在Zookeeper初始化，创建对应的节点，写入模块信息、数据库源名称、数据库IP、数据库端口信息等，然后写入下面的数据库子节点中，并添加watcher，增加监视事件。2、创建lock子节点，不需要设置watcher，如果当前client的id是当前最小的节点，则获得了lock，退出。否则继续等待，如果id不存在，则创建子节点3、当发生异常master宕机后，则watcher事件触发，然后从当前id序列中得到最小的id,将该节点置为新的master，同时将DB的read-only置为on，保证可以读写6.2.2.流程设计流程1：Agent启动根据传入的参数在Zookeeper上注册节点启动数据库监视器检查工作环境是否满足工作要求满足退出注册成功告警，等待手工处理流程2：数据库监控正常流程3：数据库监控数据库Down流程4：Master库正常停止流程五：应用启动，初始化数据库连接池流程六：应用监听到Active数据库宕机6.2.3.应用层切换设计目前我们连接池重建连接的过程是当在连接上执行DB操作时发生特定异常时触发连接池关闭不可用连接，重新向数据源获取连接。在使用Oracle的RAC配置特性时，Oracle在驱动层会自行判断数据源是否可用，若不可用则尝试从另外一个数据源获取连接，Oracle的这个特性可以理解为对等数据源的优先选择。但MYSQL的复制机制（非共享存储）决定了其驱动层不能支持当主库出问题时自动连接到从库上，因此我们考虑使用GroupDataSource来实现类似Oracle驱动做的事情，即数据源组中的首选数据源不可用时，我们尝试同组中的其他数据源来获取连接，对于连接池来说这个过程是透明的。连接池还是保持之前当连接异常时，触发执行关闭不可用连接并重新获取连接即可。主备切换和按权重选择、按优先级选择数据源的选择策略是不一样的，因此设计DbSelector来描述数据源的选择策略，不同的选择策略在同一数据源组中会同时存在，一个GroupDataSource包括写数据源选择策略、读数据源选择策略和运行时切换策略，使用何种具体策略取决于组数据源的配置。待选择的数据源要求是对等的，即读数据源选择策略只针对标识为读的数据源，不能把读写数据源混在一起选择。引入了Zookeeper之后，我们可以通过Zookeeper感知到主数据库的状态。Zookeeper在完成主备切换后会通知应用程序主数据库发生了变更，应用程序收到通知后，需要关闭连接池中之前已建立的主数据库连接，重新创建新的主库连接。基于Zookeeper的通知机制，我们在AtomDataSource中接收数据源配置变化的信息,收到变化通知后更新数据源本身的状态，同时建立listner机制，把数据源状态变化发布给连接池等对象进行相应的处理。1、类图：2、获取连接时序图3、应用监听到Active库发生切换时序图：6.2.4.切换步骤以下具体切换步骤是按7.2.1中的架构方式为基准进行的6.2.5.切换的触发条件1、Agent异常No异常表现触发动作说明a1异常退出要求在recv_timeout的时间内可重启，否则会进行切换需要记住client端的session，否则进行自动recover。无法设置read-only，需要第三方a2与MySQL的通信异常与MySQL进行读写测试，重试机制、重试次数、间隔可控制若MySQL正常，通信问题可以忽略（同一台机器）a3与zk之间的网络异常（设置read-only）通过超时来控制，大于recv_timeount则切换由于session的绑定无法恢复，需进行切换a4机器死机（设置read-only）与zk之间的通信中断，在大于recv_timeout之后进行自动切换2、MySQL异常No异常表现触发动作说明m1访问异常定期进行读写（设置read-only）主库：插入时间戳（可重试，重试间隔可设置）从库：读取时间戳（同上）若MySQL连接被kill掉，重新创建连接若异常，认为MySQL挂掉，进行切换m2机器死机同a4m3机器的网络异常同a3m4所在的整个机房down掉（Zookeeper也挂掉，被踢出集群）发起自动切换6.2.6.Zookeeper节点设计说明：1、basedb这一级的节点，当进行分库扩展的时候，就在后面加上数值进行区分，比如basedb1、basedb2等6.3.部署及使用场景6.3.1.部署方式 对MySQL进行水平切分，拆分成很多套数据库，主备库可以部署在不同机房 MySQL的复制模式采用Master（read-only）Master（rw）Slave（read-only） 数据库中间层（动态数据源包括在内）部署在程序端，配置推送 采用IP的方式 采用可靠的Zookeeper集群保障，Zookeeper可以部署在三个机房优势 多机房部署可实现IDC容灾 不受限于DNS 可以进行全页面操作的方式 在人工情况下可以将主库切换到任意备库Tips Zookeeper集群中机器的可靠性可以保障，只要半数以上的机器存活即可，是稳定的第三方。 Zookeeper集群为了保证其自身的稳定性，机器的最少数量为3，因此对应的MySQL在一个集群节点中的最少部署数量也为3个库，两个Master库分别为只读和读写，一个Slave库作为容灾库。6.3.2.使用场景1、场景1：单机房部署2、场景2：多机房部署6.4.页面化管理及监控6.4.1.切换管理目前暂时不实现6.4.2.Zookeeper监控 Zookeeper提供一些简单但是功能强大的4字命令，通过对这些4字命令的返回内容进行解析，可以获取不少关于ZK运行时的信息。 用jmx也能获取一些运行的信息/doc/r3.4.3/zookeeperJMX.html 开源的浏览器查看Zookeeper插件6.5.测试场景设计6.5.1.测试环境测试环境硬件环境1台MySQL主库服务器（2个实例master1、master2）1台MySQL从库服务器（2个实例slave1、slave2）1台Zookeeper服务器（1个实例）操作系统RedHat6 2.6.32-71 64位软件环境MySQL 5.6.11-log 二进制分发版Zookeeper 3.4.5 stable版6.5.2.测试用例用例编号ha001测试场景MySQL连接中断 场景描述Agent与MySQL之间的连接中断测试目的Agent的自动重连机制及连接失败后的切换处理前提条件1、Agent与Zookeeper之间的通信正常2、Agent与MySQL之间的通信正常3、Agent正常运行 4、Zookeeper正常运行5、MySQL正常运行测试方法在MySQL服务器上杀掉Agent的连接进程输入/动作在MySQL中Kill 掉Agent的连接进程期望的输出1、Agent在设置的间隔时间内进行自动重连，连续尝试5次，如果没有连接成功，则发起自动切换，重连的间隔和时间是可以设置的2、Agent如果自动重连成功，则返回成功的消息3、MySQL的连接如果是被Kill掉了，则需要创建连接用例编号ha002测试场景MySQL连接超时场景描述Agent与MySQL的一次连接超过设置的连接超时时间测试目的Agent的自动重连机制及处理策略前提条件1、Agent与Zookeeper之间的通信正常2、Agent与MySQL之间的通信正常3、Agent正常运行 4、Zookeeper正常运行5、MySQL正常运行测试方法将MySQL的连接超时时间设置的足够小输入/动作设置MySQL的wait_timeout参数期望的输出1、Agent在设置的间隔时间内进行自动重连，连续尝试5次，如果没有连接成功，则发起自动切换，重连的间隔和时间是可以设置的2、Agent如果自动重连成功，则返回成功的消息用例编号ha003测试场景MySQL主库的单个实例挂掉场景描述MySQL主库上的1个实例直接挂掉了测试目的MySQL主库上的实例挂掉后能否及时切换并提供正常的服务前提条件1、Agent与Zookeeper之间的通信正常2、Agent与MySQL之间的通信正常3、Agent正常运行 4、Zookeeper正常运行5、MySQL正常运行测试方法人为停掉MySQL主库上的1个实例输入/动作通过mysqladmin shutdown关闭MySQL实例通过kill -9杀掉MySQL主库的实例期望的输出1、Agent发起自动切换，在较短的时间内将1个从库置为主库，并提供MySQL服务2、如果在可接受的时间内恢复了MySQL，Agent不发起自动切换用例编号ha004测试场景MySQL服务器挂掉 场景描述MySQL主库服务器直接挂掉不可用测试目的MySQL主库服务器挂掉后能否进行正常的MySQL服务前提条件1、Agent与Zookeeper之间的通信正常2、Agent与MySQL之间的通信正常3、Agent正常运行 4、Zookeeper正常运行5、MySQL正常运行测试方法人为关闭MySQL的主库服务器输入/动作通过shutdown命令关掉MySQL的主库服务器期望的输出1、Agent发起自动切换，在较短的时间内将1个从库置为主库，并提供MySQL服务2、如果在可接受的时间内恢复了MySQL，Agent不发起自动切换用例编号ha005测试场景MySQL主从连接断掉场景描述MySQL主库的1个实例与从库的1个实例主从复制异常中断测试目的MySQL主从复制异常中断能否进行自动切换前提条件1、Agent与Zookeeper之间的通信正常2、Agent与MySQL之间的通信正常3、Agent正常运行 4、Zookeeper正常运行5、MySQL的主库和备库上的1个实例是正常运行的测试方法关闭MySQL主库上的1个实例停止MySQL从库的复制进程输入/动作用mysqladmin shutdown命令关闭MySQL主库上的1个实例用stop slave关闭从库的复制进程 期望的输出1、Agent能够在可接受的时间内对MySQL进行切换，并将从库置为新的主库，read-only属性为可写2、如果在规定的时间内将MySQL主从复制恢复正常，则Agent不需要发起自动切换用例编号ha006测试场景Agent出现异常退出场景描述Agent因为异常或压力过大导致退出测试目的Agent的自动恢复机制是否完善前提条件1、Agent与Zookeeper之间的通信正常2、Agent与MySQL之间