做物流网站计划,yahoo怎么提交网站,中国建设银行网址多少,网站建设 pdfmysql高可用方案MHA介绍概述MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案#xff0c;来保证数据库系统的高可用.在宕机的时间内#xff08;通常10—30秒内#xff09;#xff0c;完成故障切换#xff0c;部署MHA#xff0c;可避免主从一致性问题#xff0c;节… mysql高可用方案MHA介绍概述MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案来保证数据库系统的高可用.在宕机的时间内通常10—30秒内完成故障切换部署MHA可避免主从一致性问题节约购买新服务器的费用不影响服务器性能易安装不改变现有部署。还支持在线切换从当前运行master切换到一个新的master上面只需要很短的时间0.5-2秒内此时仅仅阻塞写操作并不影响读操作便于主机硬件维护。在有高可用数据一致性要求的系统上MHA 提供了有用的功能几乎无间断的满足维护需要。优点1 master自动监控和故障转移在当前已存在的主从复制环境中MHA可以监控master主机故障并且故障自动转移。即使有一些slave没有接受新的relay log eventsMHA也会从最新的slave自动识别差异的relay log events并apply差异的event到其他slaves。因此所有的slave都是一致的。MHA秒级别故障转移9-12秒监测到主机故障任 选7秒钟关闭电源主机避免脑裂接下来apply差异relay logs注册到新的master通常需要时间10-30秒即total downtime。另外在配置文件里可以配置一个slave优先成为master。因为MHA修复了slave之间的一致性dba就不用去处理一致 性问题。当迁移新的master之后并行恢复其他slave。即使有成千上万的slave,也不会影响恢复master时间slave也很快完成。DeNA公司在150主从环境中用MHA。当其中一个master崩溃MHA4秒完成故障转移这是主动/被动集群解决方案无法完成的。2 互动(手动)master故障转移MHA可以用来只做故障转移而不监测masterMHA只作为故障转移的交互。3 非交互式故障转移非交互式的故障转移也提供不监控master自动故障转移。这个特性很有用特别是你已经安装了其他软件监控master。比如用Pacemaker(Heartbeat)监测master故障和vip接管用MHA故障转移和slave提升。4 在线切换master到不同主机在很多情况下有必要将master转移到其他主机上如替换raid控制器提升master机器硬件等等。这并不是master崩溃但 是计划维护必须去做。计划维护导致downtime必须尽可能快的恢复。快速的master切换和优雅的阻塞写操作是必需的MHA提供了这种方式。优 雅的master切换 0.5-2秒内阻塞写操作。在很多情况下0.5-2秒的downtime是可以接受的并且即使不在计划维护窗口。这意味着当需要更换更快机器升级高版 本时dba可以很容易采取动作。5 master crash不会导致主从数据不一致性当master crash后MHA自动识别slave间relay logevents的不同然后应用与不同的slave最终所有slave都同步。结合通过半同步一起使用几乎没有任何数据丢失。其他高可用方案6 MHA部署不影响当前环境设置MHA最重要的一个设计理念就是尽可能使用简单。使用与5.0以上主从环境其他HA方案需要改变mysql部署设置MHA不会让dba做这些部署配置同步和半同步环境都可以用。启动/停止/升级/降级/安装/卸载 MHA都不用改变mysql主从如启动/停止。当你需要升级MHA到新版本时不需要停止mysql仅仅更新HMA版本然后重新启动MHAmanger即可。MHA 支持包含5.0/5/1/5.5(应该也支持5.6翻译文档时MHA开发者没更新对于5.6版本)。有些HA方案要求特定的mysql版本如 mysqlclustermysql with global transaction id 等,而且你可能不想仅仅为了MasterHA而迁移应用。很多情况下公司已经部署了许多传统的mysql应用开发或dba不想花太多时间迁移到不同 的存储引擎或新的特性newer bleeding edge distributions 不知道这个是否该这么翻译。7 不增加服务器费用MHA 包含MHA Manager和MHA node。MHA node运行在每台mysql服务器上Manager可以单独部署一台机器监控100以上master总服务器数量不会有太大增加。需要注意的是 Manager也可以运行在slaves中的一台机器上。8 性能无影响当监控masterMHA只是几秒钟默认3秒发送ping包不发送大的查询。主从复制性能不受影响9 适用任何存储引擎Mysql不仅仅适用于事务安全的innodb引擎在主从中适用的引擎MHA都可以适用。即使用遗留环境的mysiam引擎不进行迁移也可以用MHA。与其他HA方案比较Doing everything manuallyMysql replication 是同步或半同步。当master崩溃时很有可能一些slave还没有接受最新的relay log events这意味着每一个slave都相互处在不同的状态。人为修复一致性问题显得不再平凡。没有一致性问题主从也可能不会启动如 duplicate key error。花费1个多小时重新启动主从复制显得不同寻常。Single master and single slave在单一主从情况下一些slave 落后与其他slave的情况将不会发生。其中一个master崩溃可以轻松的让应用转移到一个新的master上面提供对外服务故障迁移很简单。Master, one candidate master, and multiple slaves双主多从双主多从的架构也很常见。主master挂掉备用master将接替主master提供服务。某些情况配置为多主架构。M(RW)-----M2(R) M(RW), promoted from M2| |-------- --(master crash)-- -x----x-S(R) S2(R) S(?) S(?)(Fromwhich position should S restart replication?)但是这并不作为master故障转移方案。当前master挂掉剩余slave不一定接受全部relay log events修复数据一致性还是问题。这种架构使用广泛但是不是所有人都能深刻理解上述问题。当前master挂掉slave变得不统一或者slave不能从新的master复制数据。也许双master其中一个master只读每个master都至少有一个slave也许可能解决问题。M(RW)--M2(R)| |S(R) S2(R)Pacemaker DRBDPecemaker(Heartbeat)DRBDMysql是一个通用方案。但是这个方案也有以下问题1 费用问题特别是跑大量主从环境。PecemakerDRBD是主动/被动的解决方案因此需要一台被动服务器对外不提供任何应用服务。基本的需要四台 mysql服务器one active masterone passive mastertwo slaves。2 宕机时间(downtime)。PacemakerDRBD是主备集群主master挂掉备用master启用。这可能花费长的时间特别是没有用 innodb plugin。即使用innodb plugin花费几分钟开始在备用master上接受连接也不寻常。另外因为备用master上数据/文件缓存是空的恢复时间热身(填充数据到 data buffer pool)花费不可忽视的时间。实践中需要一台或更多slave提供足够的读服务。在热身时间内空缓存导致写性能降低3 写问题下降或一致性问题。为了让主动/被动集群真正的工作每次提交(commit)后必须刷新事务日志(binary log和innodb log)也就是必须设置innodb-flush-log-at-trx-commit1,sync-binlog1。设置sync- binlog1会降低写性能因为fsync()函数被序列化(sync-binlog1group commit失效)。大部分案例中不设置sync-binlog1.如果没有设置sync-binlog1活动master crash新的master(先前被动服务器)可能会丢失一些已经发送到slave的binary log events。假如 master 挂掉slave A接受到mysqld-bin.000123,位置1500。binlog data刷新到硬盘的位置在1000那么新的master数据也只能mysqld-bin.000123的1000处然后在启动时创建一个新的 binary log mysqld-bin.000124。如果发生这种情况slave A不能继续复制因为新的master 没有mysqld-bin.000123位置1500.4 复杂。对多数人来说安装/初始化pacemake和DRBD不是容易的事情。相对于其他案例初始化DRBD需要重新创建系统分 区也不容易。要求dba在DRBD和linux内核层有足够的技能。如果dba执行了一个错误命令如执行drbdadm–overwrite- data-of-peer primary 在被动节点那么将会损坏活动的数据。重要的是另外一旦硬盘io层出现问题多数dba处理这种问题不是容易的。MySQL ClusterMysql cluster是真正的高可用解决方案但是必须得用NDB存储引擎。如果你用innodb将不能发挥mysql cluster集群优势。Semi-Synchronous Replication半同步复制大大降低了binlog event仅仅存在于崩溃master上的这种风险。这非常有用的能避免数据丢失。但是半同步不能解决所有一致性问题只能保证一个不是所 有slave接受到master端的commit的binlog events其他slave也许还没有接受全部的binlog events。不能apply不同的binlog events 从新的slave到 其他slave上也不能保证相互一致性Global Transaction IDGlobalTransaction ID所要达到的目的跟MHA相同但它覆盖更多。MHA只是两级复制但是global transaction id覆盖任何级别的复制环境即使第两级复制失败dba也能覆盖第三级。Check Googlesglobal transaction id project for details。来源 http://blog.csdn.net/wulantian/article/details/11770159来自为知笔记(Wiz)转载于:https://www.cnblogs.com/pangguoping/p/5589802.html
