什么是高可用架构

我们经常听到有人会提到高可用,那么什么是高可用呢,我们先来看百度百科中对高可用的定义,高可用是通过尽量缩短

应用日常操作,和突发的系统奔溃,所导致的停机时间,以提高系统的可用性,所以说,所谓的高可用,实际上,是以系统的不可用

时间长短来衡量的,我们当然希望我们的系统可以一年365天,不间断的为用户提供服务,但是绝对的百分之百的高可用呢,是不可能

达到的,那么有很多原因,都会造成系统实际上的不可用,比如严重的主从延迟,或者是主从复制中断,再比如说由于锁引起的大量的

阻塞,在这些情况下,虽然MYSQL服务器没有奔溃,但实际上,对于应用来说,已经不能正常的使用数据库了,更不要说由于软硬件故障,

服务器宕机的这种情况了,所以我们会以服务器正常可用的时间,和全年时间的百分比来表示高可用的程度,比如5个9表示全年99.999%

正常是可以使用的,那么换句话说,如果要保证一年有5个9的可用性,差不多就是每年5.25分钟的不可用时间,这个数字其实是很容易

计算得到的,其中365*24*60就是我们一年所计的分钟数,那么对于大多数应用来说,这个数字已经是很不错了,相对于5个9的可用性,

4个9的可用性,3个9的可用性,52分钟,529分钟的不可用时间,所以相对于5个9的可用性来说,4个9和3个9的可用性呢,更容易实现,

可用性的要求越高,实现的成本也就越大,所以我们在现实中,一定要结合业务和成本来选择,我们可用性的这种级别,对于没有必要

实现5个9的可用性,如果我们硬要配置5个9的架构,带来大量的成本浪费

那么如何来实现可用性呢,知道了什么是高可用,那么下面我们来看看如何来实现高可用,从高可用的定义,

我们知道,要实现高可用呢,我们主要可以从两个方面来入手,第一我们要避免导致系统不可用的原因,来减少系统

不可用的时间,系统不可用的时间减少了,那么可用的时间就增加了,那么导致系统不可用的因素呢有很多,最常见的

有服务器磁盘空间的耗尽,或者性能糟糕的SQL,以及表结构和索引没有优化,主从数据不一致,以及认为的操作失误等等,

这些都可以造成服务的不可用,那么不要小看这些问题

就拿磁盘服务器空间耗尽来说,目前的磁盘存储已经足够大了,很少会发生这样的问题,但是坦白的说,我们每年会

遇到磁盘空间不足,这样的问题而导致了MYSQL服务不可用的故障,最常见的情况呢,是由于备份或者各种查询日志

突增而导致的磁盘空间被占满,MYSQL由于无法记录二进制日志,所以无法处理新的请求,这样就会产生系统不可用故障

特别是在一些虚拟机环境中,所部属的MYSQL,很容易产生这样的问题,要避免这些问题所产生的故障呢,我们可以从以下

几个方法来入手,首先是建立完善的监控及报警系统,完善的监控及报警呢,对于任何情况来说,都是非常重要的,对于监控及

报警来说,最重要的是要避免错报和漏报,太多的错误呢,容易使人忽略这种报警消息,就像狼来了这个故事一样,错报会引起

人们失去对监控系统的信任,从而在系统真正出现问题时呢,也没有人关注并及时处理故障,漏报的问题呢,则更为严重,是指在

出现问题时呢,没有被监控到,从而没有通知相关的人员来处理,关于监控的问题呢,我们在本课程的最后呢,会有详细的讨论,

这里只是强调一下其重要性,是不能忽视的,第二点就是对备份数据进行恢复测试,备份恢复测试呢,是经常会忽略的一个问题,

我们知道,备份的重要性,所以往往不会忘记对重要的数据进行备份,但是对已经备份的数据进行测试,同样的重要,有很多原因会

造成数据的损坏,比如在远程传输过程中,网络的原因所造成的文件损坏,这样会导致我们在使用备份文件进行数据库还原时,造成无法

还原数据库的问题,从而造成大量系统不可用的时间,所以我们很有必要定时的对备份的文件恢复测试,特别是这种远程保存的数据库

备份,以保证数据库备份的文件是可用的,第三点就是正确的对数据库进行配置,关于如何的配置数据库,你前面已经进行详细的讲解了,

主要有一点大家要记住,对主从环境中呢,从服务器一定要配置成只读的,这样就可以减少很多由于数据不一致而导致不可用的故障,

最后一个就是对不需要的数据进行归档和清理,对不需要的数据进行归档和清理呢,也可以减少数据库中数据量的大小,来增加查询

的性能,还能减少磁盘空间的消耗,比如把存储到innodb表中的历史数据,归档到ftp表中,就可以节约大量的存储空间,而前提条件呢,

一定要对innodb表的独立表空间,否则就算清理了不可用数据,也很难对系统表空间进行收缩,这一点在我们讲解innodb存储引擎的

时候,已经详细的讨论过了

高可用性的第二个方法,增加系统的冗余,保证发生系统不可用时可以尽快的恢复,要增加系统的冗余呢,

最根本的一点就是,要避免存在单点故障,但是如何增加系统的冗余,避免单点故障呢,并不是一个很简单的问题,

特别是对数据库系统来说,单纯的增加从服务器的数量,并不能达到增加系统冗余的目的,因为在主从架构中,增加从

服务器,只能避免从数据库出现单点故障,但是对于主数据库,还是存在单点故障,所以单纯的主从架构,不能解决我们的

问题,所以为了使主从数据库,有冗余,我们还必须解决下面的问题,一个是主从切换及故障转移,这包括如何在多个从库中

选择新的主,并把其他的从对新的主进行同步,和如何通知应用服务器新主的IP地址

那么下面我们来看看如何解决这两个问题,来构建MYSQL数据库的高可用架构,首先我们来看看如何来解决

单点故障,所谓的单点故障呢,就是指在一个系统中,提供相同功能的组件呢,只有一个,如果这个组件失效了,

就会影响整个系统功能的正常使用,组成应用的各个组件呢,都有可能成为单点,比如我们的单独ICD房,我们把所有的

服务器都放在一个机房中,这个机房ICD房就是一个单点,那么单独的网络交换机,单独的网卡,或者说是单独的服务器,

这些都是有可能成为单点的,不过这些都不是关注的重点

在这里我们主要是解决MYSQL服务的单点问题,为了解决MYSQL服务的单点呢,通常可以使用以下方法,第一个是利用

SUN这样的共享存储,或者DRDB磁盘复制方案来解决MYSQL的单点故障,在使用共享存储时,两台服务器呢,能够正常的

挂载相同的文件系统,但是只有一台服务器能对其进行操作,如果当前进行处理的服务器,宕机了,那么备用的服务器,

继续挂载文件系统,执行需要的恢复操作,并在失效的服务器使用MYSQL服务,这个过程在逻辑上,跟宕机的服务器呢没有

什么两样,但是恢复会更加的快速,因为备用服务器呢,启动并且随时都可以运行,使用共享存储的方式,解决单点问题呢,

是有其优势的,首先避免除存储以外的其他任何组件,失效所引起的数据丢失,同时呢也可以解决,非存储主键的单点问题,

但是使用共享存储呢,也有一个最大的缺点,就通常来说,共享本身会存在一个单点,前面在介绍存储数据库性能影响的时候呢,

我们说过,如果共享存储出现问题,想要恢复呢,可能需要更长的时间,并且共享存储对随机IO的性能呢,也并不影响

所以共享存储并不是一种好的解决单点故障的方式,除了使用共享存储外呢,还可以使用磁盘镜像的方式,

来解决MYSQL的单点问题,最常见的就是DRDB这种方式了,这也是在MYSQL中所推荐的方式,DRDR是一个linux

内核模块方式来实现的同步复制技术,他通过网卡,讲主服务器的每一个块,复制到另一个服务器的块设备上,

而且在主设备提交前会被记录下来,当主失效时呢,称之为主设备,单点故障解决的方式,那么从这个方向来看呢,

DRDB和共享存储是很相似的,都有一个热备的机器,开始提供服务时呢,会使用和故障机器相同的数据,最大的不同

就是DRDB对存储进行了镜像,而不是共享存储,所以当使用DRDB时,会获得一份相同的数据,也就是说使用DRDB时,

数据是由冗余的,所以存储和数据本身,不会存在单点的问题,但是DRDB也有其本身的一些问题,如故障转移时所需的

时间比较长,利用服务器处理被动模式,而不能对外提供任何的服务,包括读服务,所以成本比较高,另外由于磁盘本身的

bug问题,造成了磁盘的损坏,同时DRDB主备设备上的文件呢,都会被损坏,所以DRDB也不是一种理想的解决方案

另外一种解决MYSQL故障的解决方案呢,使用多写集群,或者NDB集群这样的架构,目前最常见的多写集群呢,就是

Percona公司所提供的pxc集群,在pxc集群中呢,对于一个事务,所有服务器的事务全部提交后,事务才能被提交,如果

有一台服务器不能提交事务,那么我在的服务器上呢,都会对这个事务来进行回滚操作,从这点上可以看出,性能是取决

于集群中,性能最差的那台服务器的性能,pxc集群有很多的优点,比如所有的服务器上的数据都是同步的,不存在数据的

延迟问题,集群中的任意一台服务器呢,损坏都不会造成单点的问题,但是pxc集群同样有非常明显的缺点,比如前面说过的,

整个集群的性能,取决于集群中最差的那台服务器的性能,使用pxc集群时,MYSQL的写入性能呢,也比单台的MYSQL性能要差,

另外pxc集群只支持innodb存储引擎,如果我们的数据库中还使用了其他的存储引擎,就不能使用pxc这种集群方式了

另外一种MYSQL集群技术呢就是NDB集群,在NDB集群中,所有的节点呢,都会同步的进行复制,也就是说,

可以在任何节点上写入,在NDB集群中,所有的节点都会有相同的读写能力,并且每一行数据都是冗余读写的,

因此就算一个节点损坏,也不会丢失数据,NDB集群呢是一种非常完美的解决方案,不过目前的NDB集群中,所有的

数据都要求存储在内存中,如果内存不足,存放所有的数据,则NDB集群的性能都会非常的差,另外呢使用NDB集群呢,

还有其他的限制,所以目前来说,NDB也很少会使用在生产环境中,那么最后一种解决方案呢,是我们已经介绍过的,

利用MYSQL的主从复制,来解决MYSQL的单点故障了,关于MYSQL的复制呢我们前面已经讲了很多了,这里要说的就是,

想要用MYSQL复制来解决这个单点问题,实际上最重要的一点是解决主服务器的问题

要解决这个问题呢,就必须解决以下三个问题,一是主服务器切换后,如何通知应用新的主服务器的IP地址,

但是如何检查MYSQL主服务器是否可用,如何处理从服务器和主服务器之间的那种复制关系,解决了这些问题呢,

我们可以自己编写程序来实现,也可以使用第三方的复制管理主键,目前最常用的管理主键呢,有两种,一种是MMM,

另外一种就是MMHA,我们下面就看看这种组件是如何工作的