• 博客访问: 13963976
  • 博文数量: 1488
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1500多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

文章分类

全部博文(1488)

文章存档

2018年(132)

2017年(320)

2016年(356)

2015年(346)

2014年(270)

2013年(43)

2012年(21)

分类: MySQL

2018-04-25 09:38:50

我在去年QCon和Gdevops广州站的时候,讲到MySQL和Oracle的现状和发展时,简单总结了下一个常见的使用误区:把MySQL当Oracle用,或者把Oracle当做MySQL用。

在我们身边这种情况太多,以至于很多重度依赖Oracle的人觉得MySQL太弱,MySQL的人觉得Oracle的方案扩展性不够好。其实可以从几个维度来看,我们今天就着重从MySQL的一些技术点来说起吧。

MySQL的高可用其实如果延展开来,可以从三个维度来考虑,应用层,数据库层,系统层(包含网络层)。假设数据库层面已经能够做到最好了,数据层面可以保持数据业务的访问,从网络层面来说,我们需要DNS的支持能够满足两个层面的高可用,一个是同城机房(或者同机房)的DNS高可用,另外一个是跨机房(跨区域)的DNS高可用,从数据库的业务诉求和网络规划来说,使用的DNS是不对外服务的,所以可以理解是local DNS的角色,这样一来,我们都不需要刻意去维护VIP的切换,网络层或者中间件层足够强大,我们只需要格外关注数据库服务的可用性和数据一致性就可以了。

如果往上层来看,就是应用层面,其实应用访问数据库服务使用域名,他压根不需要知道对应的IP是什么,就跟我们访问谷歌只需要知道是google.com就可以了。如果有了网络层面的高可用,保证一个DNS的生效策略,比如10秒,1分钟等,那么应用层需要的改造就是短连接或者是应用重连机制,因为毫无疑问程序端会有一层缓存,长连接很容易出现“迷失在过去状态”的情况。

所以一个较为完整的方案应该是系统层,网络层,数据库层和应用层来共同配合,才能保证一个基本的高可用方案。

如果要实现更为复杂的高可用,比如已经不局限于容灾,做双活多活等,其实整个架构的复杂度会高很多。

我就抛砖引玉,来说说MySQL高可用方案的一些想法。

大家知道MHA是MySQL DBA非常喜欢用的高可用方案,因为确实非常经典,我看了下代码的实现,逻辑的部分是非常的完善的,很多我们没有考虑到的点在代码层都做了校验。所以说MHA是一个非常成熟的方案,在大家的各种应用场景中发展壮大起来了。如果是早一些的版本使用MHA就是一个标准动作,大家知道MHA后期也有一些变化,一个是自0.56的版本开始引入了binlog server,在这个基础上有了0.57的版本,之后在github上就没有了版本更新。如果大家细细看看0.56和0.57的改进,主要的改动就是在数据完整性上的一个补充,当然这种架构方式对已有的快捷恢复来说会有一定的侵入性。所以我们很多公司用MHA,其实还是没有用binlog server的。MHA还有一个比较特别的地方就是对于网络异常的处理,其实0.56和0.57是有一些差别的,当然在细节测试的时候,其实碰到有些异常情况比较纠结,好像怎么解释都可以,所以以0.56和0.57为分水岭,对于网络的处理的差异来看,我是更倾向于0.56版本的,所以我们迭代测试了0.56,0.57然后又折回来补充了0.56的场景。

当然这个过程的收获是比较大的,也妆模作样的看了下MHA的一些代码,理了一下思路。但是我发现一个问题,相信很多朋友都有类似的感觉,那就是MHA是perl写的,实在是让很多人感到非常的陌生和别扭,因为perl语言本身的群体和易读性上是存在一些落差的,所以我们其实更倾向于用Python来实现这个事情,当然用其他的语言也可以,至少群体要大一些。

其实我在调研MHA的细节时,是打算在年后做MHA的代码python化工作的,但是我理了下自己的思路,发现这个事情其实做起来很有技术价值,但是投入和付出的成本落差是很大的,一来改造的难度很大,我得把Perl搞明白,然后用Python重写一遍或者理解了原来的逻辑,整理出缺点来,重新构建,我想了比较多的细节,对于MHA的缺点等等,这是技术上的投入,很大,而且很有难度,对个人成长是大有帮助的,但是从另外三个角度来说,我觉得可能实践意义不是很大了,第一是目前的技术方案MHA其实已经没有明显的优势了,第二我改造的版本如果足够好,公司内怎么推行,如果跑起来一直不出问题,那么实践意义其实不够大;第三我推广到社区里,大家是否能够接受,因为我面对的不是很多年前的一个状态,如何保证我写的足够好,或者说写正确了,这不是个拍脑袋的问题,一定是大量的细致测试才有说服力。

所以很多大公司其实在很早之前就把这个事情做了,当然可能只是不对外而已。当然对于MySQL的高可用,双活方案其实一直以来大家都有很多的解决方案,或者看起来行得通的经验。

比如双主,漏斗形的架构设计,其实在很多公司早期确实是这么干的,看起来这个方案没有特别的难点,但是处理这些临界点的问题的时候,还是要投入不小的功夫。这个方案我不打算多说,更多是在异常的处理上。

然后来说说MGR,其实完整说来,应该是InnoDB Cluster,我非常看好这个方案,可能很多人对此比较陌生,其实最先大家熟悉的是MGR, 如果把InnoDB Cluster比作三驾马车,那么是由MySQL Shell, MySQL Router,MySQL Group Replication三个组件共同组成,其中的核心组件就是MGR了。他的基因是真正的分布式,基于paxos协议。当然从数据架构的角度来说,基于复制的方案,可用性和完整性是有保证的,但是性能上是要衰减的,所以MGR干脆就限制了节点个数。这个和传统关系型数据库的节点的概念就不同了。

如果你留意下Windows安装版本的话,你会发现InnoDB Cluster已经打包成为了默认的安装服务了,里面提供了全面的安装配置过程,可以参考如下的链接:

一种快速安装InnoDB Cluster的方法

有很多人说InnoDB Cluster的方案要落入生产实践还有待考验,这个绝对没错,但是从方向上来说,他已经对早期的方案是一个很好的补充和改进了。他的三大组件,其实MySQL Router目前是一个短板,但是一旦这个短板不成为瓶颈,有了sharding等功能,那对于MySQL开源社区的影响是深远的。所以方案可以改进,就如同技术发展一样。我赞同那句话,没有最好的方案,只有最合适的方案。

阅读(1645) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册

/bosoo/513N.html /88410/787a.html /ymw/742w.html /pmw/781I.html /88410/246G.html /ggs/063m.html /boss/526c.html /3088/828C.html /bg88/063t.html /pmw/261I.html /bbs/130A.html /ks/227c.html /pmw/173t.html /gupiao/416J.html /888/371k.html /xyw/841u.html /bbs/441l.html /bbsy/100A.html /8888/315L.html /3088/401u.html /gpw/367h.html /888/587Q.html /123/126P.html /1088/560w.html