用MHA架构实现MySQL高可用方法

下面一起来了解下用MHA架构实现MySQL高可用方法,相信大家看完肯定会受益匪浅,文字在精不在多,希望用MHA架构实现MySQL高可用方法这篇短内容是你想要的。MySQL复制是异步或者半同步的。当master故障时,一些slave可能并没有收到最新的relay log,也就意味着每个slave可能处于不同的状态。手动处理这些一致性问题是小事,因为不修复这些问题,就不能开始复制。但是手动修复这些问题,花费一个小时或更多的时间并不少见。一主一从如果架构是一主一从,就不会出现一部分slave的状态落后于最开发云主机域名新的slave的问题。当master出现故障,可以将应用的流量全部发送给新的master(原来的slave)。故障切换很容易解决。但是会有下面的问题。首先,不能扩展读流量。在很多情况下,可能会运行一些重要的操作,比如备份、分析查询、批量处理。这可能会导致slave的性能问题。如果只要一个slave,当这个slave出现故障后,master必须处理所有这些流量。其次,可用性问题。如果master出现故障,只剩下一台服务(原来的slave成为主),就成为了单点故障问题。为了创建一个新的slave,需要在线备份,然后存储到新的slave上并立即启动slave。但是这些操作通常会花费数小时(甚至是不止一天才能完成复制)。在一些重要的应用上,可能忍受不了数据库这么长时间有单点故障问题。并且,在线备份会大大增加master的I/O负载,因此在高峰期进行备份是很危险的。双主多从双主多从也是常见的架构。如果当前的master出现故障,备用的master就会变为新master。大很多场景下,备用的master都配置为只读。但这不总是作为master故障切换解决方案运行的。当目前的master出现故障,余下的slave可能没有接收到全部的relay log,因此在slave之间解决一致性问题仍需要其它解决方案。如果不能忍受一致性问题并且还想立即启动服务。只需要将备用的master作为新的master,并且抛弃剩余的slave。之后再从这个新的master做线上备份创建新的slave。但是这个方法和前面提到的一主一从的发法有同样的问题。剩余的slave不能进行读扩展和进行冗余的目的。另外,使用双主(一个只读)并且每个master都至少有一个从也是可能的。至少一个从可以进行复制,如果目前的master出现故障。但是事实上,很多使用者都不会采用这种架构,因为最大的缺点是复杂性。在这种架构中使用了三层复制。管理三层复制并不容易。例如,如果备用master出现故障,备用master的slave就无法继续进行复制。很多情况下,必须重新配置备用master和它的slave。重要的是,在这种架构中,必须要使用至少4台云服务器。心跳+DRBD使用心跳(Heartbeat)+DRBD+MySQL是非常常见的HA解决方案。但是这个解决方案有一些严重的问题。第一个问题是开销,特别是想运行大量MySQL复制环境的时候。心跳+DRBD是主用/备用解决方案,因此需要一个不处理任何应用流量的被动(standby)master。被动云服务器不能被用来进行读扩展。通常,你至少需要4台MySQL服务,一个主动(active)master,一个被动(passive)master,两个slave。第二个问题是停机。因为心跳+Heartbeat是active/standby集群,因此如果active server出现故障,故障恢复会发生在passive server上。这可能需要花费很长的时间,特别是没有用InnoDB插件。即使使用了InnoDB插件,只花费几分钟在passive server开始接收访问连接的情况并不常见。除了故障恢复时间,在故障恢复后,热身(warm-up)(填充数据到缓冲池)也要花费时间,因为在passive上,数据库/文件系统缓存是空的。在实际中,需要一个或更多额外的slave来处理足够的读流量。在warm-up期间,由于还粗是空的,因此写性能会显著下降。第三个问题是写性能下降或一致性问题。为了保证active/passive高可用集群运行,在每次commit必须把事务日志(二进制日志和InnoDB日志)刷新到磁盘,因此必须设置innodb-flush-log-at-trx-cmmit=1和sync-binlog=1。但是sync-binlog=1会降低写性能,因为在当前的MySQL版本fsync()是连续的(如果sync-binlog是1,组提交就会打破)。大多数情况下,不会设置sync-binlog=1。但是如果sync-binlog=1没有设置,当active master故障,新的master(之前的passive server)可能会丢失已经被发送到slave上的二进制日志事件。假如,master出现故障,并且slave A接收到mysql-bin.00123的1500位置。如果binlog数据近刷新到1000位置到磁盘,新的master仅只有mysql-bin.00123到1000位置并且创建新的二进制文件mysql-bin.00124。如果出现这种情况,由于新的master没有mysql-bin.00123的1500位置,slave A就不能进行复制了。第四个问题是复杂性。对于很多用户来说,安装/配置心跳和DRBD是不简单的。在很多部署环境,配置DRBD经常需要重建系统分区,这在很多情况下是不容易的。另外,也需要在DRBD和Linux内核层有足够的经验。如果执行了一个错误的命令(比如在passive节点执行了drbd –overwrite-data-of-peer)非常容易损坏生产数据。当使用DRBD,一旦出现磁盘I/O层的问题,对于大多数DBA来说,解决这个问题是很难的。MySQL集群MySQL集群真正实现了高可用解决方案,但是必须使用NDB存储引擎。大多数情况下都是使用InnoDB,因此无法使用MySQL集群的优势。半同步复制半同步复制大大降低了”binlog仅存在故障master上”的风险。这对避免数据的丢失有很大的帮助。但是半同步复制并没有解决一致性问题。半同步复制保证在master提交时至少有一个(并不是所有)slave接收到binlog事件。仍有可能一些slave没有接收到binlog事件。如果没有将最新的slave上的relay log应用到非最新的slave上,slave就无法处于一致性状态。MHA解决了一致性问题,因此通过将半同步复制和MHA一起使用,几乎没有数据丢失和slave保持一直就能实现。全局事务ID(GTID)全局事务ID的目的和MHA想要实现的是基本相同的,但是全局事务ID包括的更多。MHA只能支持两层复制,但是全局事务ID可以支持很多层复制的环境,因此即使第二层复制故障了,仍然可以恢复三层复制。从MySQL5.6开始就开始支持GTID了。Oracle的官方工具mysqlfailover支持带GTID的master故障切换。从MHA的0.56版本开始,也支持基于GTID的故障切换。MHA会自动检测mysqld是否在GTID运行,如果GTID开启,MHA就实现带GTmysql数据库指定条数数据查询的主要方法ID的故障切换,如果没有启用,MHA就使用基于relay log的故障切换。看完用MHA架构实现MySQL高可用方法这篇文章后,很多读者朋友肯定会想要了解更多的相关内容,如需获取更多的行业信息,可以关注我们的行业资讯栏目。

相关推荐: Java数据库常用操作

一、JDBC驱动JDBC驱动的加载:1、通过容器加载:对于有容器的Java应用,可以直接将相应的驱动jar包放在容器的lib目录下,例如在Tomcat做容器的web应用,将驱动复制到tomcat的lib子目录下;2、应用运行时加载:如果希望应用自行加载相应的驱…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 06/09 10:16
下一篇 06/09 10:16

相关推荐

发表评论

您的电子邮箱地址不会被公开。