网易MySQL数据库工程师微专业学习笔记（十一）

一、高可用概念

高可用是互联网行业中一个常用的概念，简单来说就是一个网站如果能在很长的一段时间里能够让用户进行访问和使用，那么就可以说这个网站是高可用的。同样对于数据库而言，如果数据库在很长的一段时间内都可以正常工作，那么就可以说这个数据库是高可用的。系统的高可用性的评价一般使用可用率来表示，可用率的计算方法很简单，就是100%-全年不可用时间/全年的总时间。下面是一些常用的可用率和对应的不可用时间长度表。

从上面的表中可以看出，以一年来衡量，即便可用率到了99%，依然会有87.6个小时的不可用时间，这对于一般的线上网站明显是不能接受的。对于一般的系统，至少要能够提供99.9%的可用率，而如果是重要的系统则可用率要更高。

而造成不可用的原因一般有以下这些：

1. 硬件故障，这个是造成不可用的最常见的原因，例如磁盘的损坏、网络的故障等。

2. 预期中的系统软硬件维护，这个也是造成不可用的一个比较常见的原因，例如linux有时候会有一些安全漏洞需要修复，这就造成了系统的不可用。

3. 软件缺陷，应用代码和mysql服务程序都有可能存在bug。

4. 遭到恶意的攻击、数据泄露或人为操作失误也会造成不可用。

要提高系统的可用率手段只有一个，就是冗余，已数据库为例就是将数据库中的数据和数据库服务进行冗余，当一个数据库服务器挂掉的时候可以有其他的数据库服务器顶上，同理对于应用服务器、网线、交换机都可以进行冗余，从而来提高系统的可用率。

二、数据库冗余与高可用

数据库的冗余相对于其他设备如应用服务器的冗余更为困难，因为数据库中的数据是随着时间变化的，而应用服务器中的程序代码是写死。举例来说，如果应用服务器宕机只要有一台内部有相同代码的应用服务器作为冗余自动顶上就可以了。但是如果数据库服务器宕机那么不仅要用一台冗余数据库服务器顶上，还要保证顶上的这台冗余服务器中的数据和宕机的服务器宕机前内部的数据相同才可以，这个就是数据库冗余的主要难点。因此数据库的可用性除了数据库服务的可用性，还要实现数据库内部数据的可用性。对于服务可用性可以通过冗余数据库服务器实现，而数据的冗余可以通过备份恢复、主从复制等方法来实现，当然如果只是用数据备份恢复那么数据恢复的时间就会比较长，这样系统可用率就会下降。所以数据库的高可用可以通过两步来实现，第一步就是保证数据绝对不会丢失，第二步让数据库出现异常时能够快速的恢复，通过这两步渐进就可以实现数据库的高可用。下面介绍一下目前比较常用的数据库高可用方案。

1. 基于共享存储的单活方案

基于共享存储的单活方案的整体架构如下图所示。该架构中底层数据都会被保存在SAN共享存储中，而数据库服务器本地并不存储数据，而是通过加载SAN上的数据来使用。SAN中会通过RAID整列等方式来保证数据的可靠性，一般SAN都是又一些专门的存储设备公司提供，如IBM因此在数据的可靠性上无需担心。然后当数据库服务器宕机时只要通过一个备用的数据库服务器去重新加载SAN上的数据就可以恢复数据库服务了。但是这个方案有一个致命的问题就是硬件成本非常高，SAN的成本很高，数据库服务器连接SAN一般通过光纤网络，光纤交换机、光纤线成本也很高。另外SAN一般是不允许两台数据库服务器同时访问SAN的，因此同一时间内只用一台数据库服务器能够使用，另一台就只能空跑。虽然成本较高，但是从技术角度讲这个方案还是是分的可靠的。

2. 基于存储复制的数据冗余单活

基于存储复制的数据冗余单活是对基于共享存储的单活方案的改进，其架构如下图所示。在该方案中不需要昂贵的SAN共享存储，只要将数据保存在数据库服务器本地，然后通过网络将数据库服务器中的文件系统数据块复制到备用数据库服务器上，一般在linux中就是通过BRBD来实现的。这样当数据库服务器宕机时，因为备份数据库服务器上的数据是通过BRBD复制的，所以可以认为备份数据库上的数据和主库上的数据是一致的，这样只要直接使用备份数据库来顶上就可以了。这样就不用使用昂贵的SAN了，但是这种方案通用存在一定的资源浪费，就是当主库正常运行时从库还是只能空跑的。而且BRBD也不能绝对保证数据的一致性，因此现在的大型网络系统是不会用这种方案的，但是在一些小型的系统中还是可以使用的，因为成本低、架设方便、而且比较可靠。

3. 基于mysql主从复制

基于mysql主从复制的高可用方案是目前比较常用的方案。mysql本身提供基于binlog的主从复制，这样基本保证了主库与从库的数据一致性，因此当主库服务器宕机时可以通过切换从库来继续提供访问。同时数据的写入操作需要都放在主库上，但是一部分的读操作可以放在从库上，这样就避免了之前两个方案中存在的数据库服务器资源浪费的情况。一般线上的主从复制的架构如下图所示，一般有一台主库，而从库可以有多个，每个从库都有不同的用处，可以是分担查询压力，可以是用于数据备份和离线的大数据的计算等。

4. 基于集群提交通信协议的多主复制

这是一种比较先进的高可用方案，可能是未来数据库高可用的方向，但是当前还不是非常成熟，在吞吐量和性能方面还有待提高，因此只有在一定的情况下才适合使用。在这种架构中所有的数据库服务器都是主库，都可以同时提供读写服务器，而数据库服务器间的数据同步不再是通过binlog传递，而是通过GROUP COMMUNICATION(集群提交通信协议)来实现的，如下图所示。目前percona公司提供的Percona XtraDB Cluster就是基于此的一个高可用方案。

三、mysql主从复制高可用需要解决的问题

上面介绍了基于mysql主从复制高可用方案是目前比较靠谱也是比较常用的一种方案，但是简单的主从复制并不能真正满足线上高可用的要求，这是因为有以下三个主要问题。

1. 主从服务器有各自的IP，当发生主从切换时应用服务器需要修改数据库连接的配置并重启。

2. 人工判断主库是否故障再发起切换需要较长的时间。

3. 主从复制存在客观的同步延迟，切换后可能造成事务数据的丢失。

下面介绍一下这三个问题的解决方案。

首先针对数据库切换时的ip切换的问题常用的是通过绑定virtual IP(虚拟IP)来解决的。IP是网络中的一种逻辑资源，一个网卡上其实可以绑定多个IP，当然其中一个IP是用于寻址用的，而其他的IP就是虚拟IP，虚拟IP是可以随时注册并取消的。应用服务器就不需要通过实际IP连接数据库了，而是通过虚拟IP连接，如下图所示。

而当数据库主库宕机时，只要将虚拟IP在主库上解绑（当然如果主库彻底挂掉就不用解绑了），然后再在从库上将虚拟IP绑定上，这样服务器不需要修改数据库连接信息中配置的IP就可以实现数据库的切换了，如下图所示。

当然除了虚拟IP也可以通过DNS绑定域名的方法来实现数据库的漂移。通过DNS来实现就是应用服务器连接数据库时通过的不是IP而是域名，而当主库宕机时通过将域名与主库IP解绑并绑定从库的方式就可以实现数据库的漂移了。在具体项目中可以根据硬件和系统的情况来选择是用哪个方案，选择的原则就是配置方便并且可靠。

解决因为人工判断并切换数据库时间比较长的问题的方法就是安装一个监控服务器，在监控服务器中实现DBA检查数据库是否正常运行的检查逻辑，当数据库宕机是监控程序能够及时发现并自动实现数据库的主从切换并完成虚拟IP的漂移，如下图所示。

虚拟IP管理加上数据库的监控和自动切换就组从了数据库的高可用中间层，目前对于mysql而言有很多比较靠谱的高可用中间层，下面简单介绍两个。

1. MHA

MHA在切换数控库时会自动选择复制延迟最小的从库来切换，并且会尝试不全缺失的binlog日志（但是如果主库服务器彻底宕机是无法恢复的）。但是MHA自身并不提供VIP（虚拟IP）管理方案，需要用户自己写好VIP切换的脚本然后提供给MHA。此外MHA部署时通常需要两个或以上的从库。

2. MMM

MMM相对于MHA最大的好处就是提供了VIP的管理功能，但是不支持主从数据延迟的判断和不全，因此数据丢失的风险高于MHA。

一般线上推荐使用的MHA。如果一个系统的数据库上加载了一个高可用中间层，那么就可以认为这个数据库的可用性是比较高的了。

而对于mysql主从复制中会产生的同步延时导致的数据丢失一般采用半同步复制来解决。首先一般正常的主从负责的流程时主库commit操作成功，数据写入并产生binlog文件，然后从库同步binlog并执行binlog中的内容。但是因为网络传输是有延时的，所以从主库上commit成功到从库同步完成是有一定的延时的，如下图所示。

这样当主库出现问题就可能造成主从间一定的数据丢失的，因为可能在主库宕机前有些commit成功的数据的binlog还没来得及传给从库。甚至可能在主库宕机前主从间的网络断掉了，然后几分钟后主库有宕机了，这样就可能造成几分钟的数据丢失。而半同步复制就是将commit操作和binlog向从库的传输和执行串行化，以此来保证数据不丢失，如下图所示。

但是半同步复制也是存在问题的，首先半同步复制速度会慢，因为多了一个binlog传输和执行的过程，同时binlog传输速度依赖于网络有很大的不确定性。此外当网络异常导致主从断开时还是无法自动的让主从数据一致的。

关于MHA的实际部署因为需要几台电脑来进行硬件环境的配置暂时无法实现，虽然用微专业课件中的虚拟机已经成功配置了，但是根据以往经验在虚拟机上配置和实际机子上配置还是有点不同的，因此这里就不介绍MHA的配置了。等我硬件到位后在实际环境中配置成果后会单独记录配置的步骤。