MySQL高可用浅析:MySQL HA方案大数据应用

来源:互联网 / 作者:SKY / 2017-11-18 19:49 / 点击:
对付大都应用来说,MySQL都是作为最要害的数据存储中心的,以是,怎样让MySQL提供HA处事,是我们不得不面临的一个题目。当master当机的时辰,我们怎样担保数据尽
Tech Neo技能沙龙 | 11月25号,九州云/ZStack与您一路切磋云期间收集界线打点实践

对付大都应用来说,MySQL都是作为最要害的数据存储中心的,以是,怎样让MySQL提供HA处事,是我们不得不面临的一个题目。当master当机的时辰,我们怎样担保数据尽也许的不丢失,怎样担保快速的获知master当机并举办响应的妨碍转移处理赏罚,都是必要我们好好思索的。这里,笔者将团结这段时刻做的MySQL proxy以及toolsets相干事变,说说我们现阶段以及后续会在项目中回收的MySQL HA方案

MySQL高可用浅析:MySQL HA方案

(题图来自:comprendrechoisir.com)

Replication

要担保MySQL数据不丢失,replication是一个很好的办理方案,而MySQL也提供了一套强盛的replication机制。只是我们必要知道,为了机能考量,replication是回收的asynchronous模式,也就是写入的数据并不会同步更新到slave上面,假如这时辰master当机,我们如故也许谋面对数据丢失的风险。

为了办理这个题目,我们可以行使semi-synchronous replication,semi-synchronous replication的道理很简朴,当master处理赏罚完一个事宜,它会守候至少一个支持semi-synchronous的slave确认收到了该变乱并将其写入relay-log之后,才会返回。这样纵然master当机,起码也有一个slave获取到了完备的数据。

可是,semi-synchronous并不是100%的担保数据不会丢失,假如master在完成事宜并将其发送给slave的时辰瓦解,如故也许造成数据丢失。只是对比于传统的异步复制,semi-synchronous replication能极大地晋升数据安详。更为重要的是,它并不慢,MHA的作者都说他们在facebook的出产情形中行使了semi-synchronous(这里),以是我认为真心没须要担忧它的机能题目,除非你的营业量级已经完全逾越了facebook可能google。在这篇文章内里已经提到,MySQL 5.7之后已经行使了Loss-Less Semi-Synchronous replication,以是丢数据的概率已经很小了。

假如然的想完全担保数据不会丢失,现阶段一个较量好的步伐就是行使gelera,一个MySQL集群办理方案,它通过同时写三份的计策来担保数据不会丢失。笔者没有任何行使gelera的履历,只是知道业界已经有公司将其用于出产情形中,机能应该也不是题目。但gelera对MySQL代码侵入性较强,也许对某些有代码洁癖的同窗来说不吻合了:-)

我们还可以行使drbd来实现MySQL数据复制,MySQL官方文档有一篇文档有具体先容,但笔者并未回收这套方案,MHA的作者写了一些回收drdb的题目,,仅供参考。

在后续的项目中,笔者会优先行使semi-synchronous replication的办理方案,假如数据真的很是重要,则会思量行使gelera。

Monitor

前面我们说了行使replication机制来担保master当机之后尽也许的数据不丢失,可是我们不能比及master当了几分钟才知道呈现题目了。以是一套好的监控器材是必不行少的。

当master当掉之后,monitor能快速的检测到并做后续处理赏罚,譬如邮件关照打点员,可能关照保卫措施快速举办failover。

凡是,对付一个处事的监控,我们回收keepalived可能heartbeat的方法,这样当master当机之后,我们能很利便的切换到备机上面。但他们如故不能很即时的检测随处事不行用。笔者的公司现阶段行使的是keepalived的方法,但后续笔者更倾向于行使zookeeper来办理整个MySQL集群的monitor以及failover。

对付任何一个MySQL实例,我们都有一个对应的agent措施,agent跟该MySQL实例放到统一台呆板上面,而且按时的对MySQL实例发送ping呼吁检测其可用性,同时该agent通过ephemeral的方法挂载到zookeeper上面。这样,我们可以就能知道MySQL是否当机,首要有以下几种环境:

呆板当机,这样MySQL以及agent城市当掉,agent与zookeeper毗连天然断开

MySQL当掉,agent发明ping不通,主动断开与zookeeper的毗连

Agent当掉,但MySQL未当

上面三种环境,我们都可以以为MySQL呆板呈现了题目,而且zookeeper可以或许当即感知。agent与zookeeper断开了毗连,zookeeper触发响应的children changed变乱,监控到该变乱的管控处事就可以做响应的处理赏罚。譬如假如是上眼前两种环境,管控处事就能自动举办failover,但假如是第三种,则也许不做处理赏罚,守候呆板上面crontab可能supersivord等相干处事自动重启agent。

行使zookeeper的甜头在于它能很利便的对整个集群举办监控,并能即时的获取整个集群的变革信息并触发响应的变乱关照感乐趣的处事,同时和谐多个处事举办相干处理赏罚。而这些是keepalived可能heartbeat做不到可能做起来太贫困的。

行使zookeeper的题目在于陈设起来较为伟大,同时假如举办了failover,怎样让应用措施获取到最新的数据库地点也是一个较量贫困的题目。

对付陈设题目,我们要担保一个MySQL搭配一个agent,幸好这年初有了docker,以是真心很简朴。而对付第二个数据库地点变动的题目,着实并不是行使了zookeeper才会有的,我们可以关照应用动态更新设置信息,VIP,可能行使proxy来办理。

固然zookeeper的甜头许多,但假如你的营业不伟大,譬如只有一个master,一个slave,zookeeper也许并不是最好的选择,没准keepalived就够了。

Failover

通过monitor,我们可以很利便的举办MySQL监控,同时在MySQL当机之后关照响应的处事做failover处理赏罚,假设此刻有这样的一个MySQL集群,a为master,b,c为其slave,当a当掉之后,我们必要做failover,那么我们选择b,c中的哪一个作为新的master呢?

原则很简朴,哪一个slave拥有最近最多的原master数据,就选哪一个作为新的master。我们可以通过show slave status这个呼吁来获知哪一个slave拥有最新的数据。我们只必要较量两个要害字段Master_Log_File以及Read_Master_Log_Pos,这两个值代表了slave读取到master哪一个binlog文件的哪一个位置,binlog的索引值越大,同时pos越大,则那一个slave就是能被晋升为master。这里我们不接头多个slave也许会被晋升为master的环境。

在前面的例子中,假设b被晋升为master了,我们必要将c从头指向新的master b来开始复制。我们通过CHANGE MASTER TO来从头配置c的master,可是我们怎么知道要从b的binlog的哪一个文件,哪一个position开始复制呢?

GTID

阅读延展

1
3