采用开源软件Keepalived和MySQL构 建高可用系统的研究与 …

采用开源软件Keepalived和MySQL构

建高可用系统的研究与测试

林丽丽，蒋锐权，武剑锋

上海证券交易所 技术开发部，上海 200120

E-mail ：lililin@sse.com.cn

摘 要：无论是在研究领域还是项目工程中，如何确保计算机系统的高可用一直是个热点问题。本文提出一个基于Web应用的简单高可用软硬件部署方案：它采用开源软件Keepalived实现服务器的自动切换，采用开源数据库MySQL进行数据的主备机复制。这个方案有提升Web应用的高可用性、采用开源软件降低运维成本以及部署简单维护方便等优点。

关键词：开源软件；高可用性；Keepalived；MySQL

1 引言

可用性（Availability）一般用于评价某个计算机业务系统或某台服务器的持续服务能力。无论是在研究领域还是项目工程中，如何确保计算机系统的高可用（High Availability）一直是个热点问题。当系统发生故障时，计算机系统能够快速切换，不中断对外服务，或在服务水平协议要求的时间范围内恢复对外服务，才能够确保安全运行。

不同运行安全级别的系统，对高可用的要求是不同的。而不同高可用的要求，会直接影响到计算机系统的软硬件部署，以及相应的IT开发和维护成本。许多企业不得不面对这样的决策：如何选择一个好的计算机系统高可用方案，既能给予系统有效保障，使其在故障后对外服务不受影响，又能将该保障的花费降至最低。

其实对于高可用要求略低的系统，有些简单的高可用方案可以即简化系统架构又降低运维成本。例如，在硬件冗余方面可以简单采用主备服务器，而不是多节点集群系统,来降低软硬件复杂度和花费；在软件方面，则可以使用开源软件。

本文提出了这样一个基于Web应用的简单高可用软硬件部署方案：它采用开源软件Keepalived实现服务器的自动切换，采用开源数据库MySQL进行数据的主备机复制。为了说明它的高可用性，本文对该方案所使用的软件技术进行了研究分析，并据此对相应的软件配置进行了筛选和调整；同时，本文又对该方案进行了专项测试，从而验证了它的正确性和可行性。

2 高可用技术方案

计算机系统的可靠性用平均无故障时间（MTTF）来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。可维护性用平均维修时间（MTTR）来度量，即系统发生故障后维修和重新恢复正常运行平均花费的时间。系统的可维护性越好，平均维修时间越短。计算机系统的可用性定义为：MTTF/(MTTF+MTTR) * 100%。由此可见，计算机系统的可用性定义为系统保持正常运行时间的百分比。

根据可用性的取值， 我们可以将信息系统分为多个可用性等级， 分别为：较可用(Available)、高可用(Highly Available)、极可用(Extremely Available)、最可用(Most

13

本期热点Focus

Available)。表1对这些等级进行了简要的描述。

本文讨论的就是具有高可用等级的系统。除了允许该等级系统在主备机切换时有少量数据丢失外，为了提高可用性，我们还希望降低单点故障风险，缩短主备机切换时间，并降低运维成本。

本文主要基于两个方面讨论计算机系统的高可用性。一，服务器的高可用性。即当主服务器发生故障时，备服务器是否能够自动接管，并对外提供服务。二，数据库的高可用性。当主数据库切换到备数据库时，数据的丢失情况；当原主数据库恢复运行时，恢复数据的方法。

一般来说，服务器的高可用技术主要包括冷备服务器技术、服务器集群的热备技术和服务器虚拟化技

等级较可用术等。它们有各自的优缺点，详见表2。

考虑到降低单点风险，并缩短主备机切换时间，三类方案中，服务器集群的热备技术最为合适。由于希望降低运维成本，我们选择使用开源软件。目前比较主流的开源软件有Keepalived、heartbeat、piranha和UltraMonkey等。这些软件都是基于Linux系统的开源软件，在高可用的功能上不相伯仲。但相比之下，Keepalived的开发团队比较活跃，使用面广，配置灵活，具有一定的优势。因此，我们选择使用Keepalived来保证服务器的高可用性。

对于数据库的高可用性，各商业软件的厂商都有各自的解决方案，比如Oracle OPS server和IBM DB2 (share-nothing architecture)。和这些商用软件相比，

描述可用性取值为99％以下的信息系统， 此种系统基本不具备容灾能力， 在灾难袭击下通常会瘫痪或崩溃。因此， 它们只能用来处理一般性业务， 诸如办公文档编写、 程序编写、 个人事务管理等可用性达到99.9％等级的信息系统， 此种信息系统可应对微小的、 局部的异常或灾难， 如应用失效、 硬件老化等。在发高可用生这些微小灾难时， 此种系统通常能够自动重启应用或将应用转移到另外一个硬件上。此种系统可用来进行敏感性业务处理， 诸如网络路由、 应用服务器、 中间件服务器、 邮件服务器等。极可用可用性取值达到99.99％等级的信息系统。此种信息系统具备较强的容灾能力， 能够应对区域性的或小规模的灾难。此种系统通常用于重要业务活动， 如程控交换、 交通控制、 薪酬发放系统等。可用性取值达到99.999％等级的信息系统。这是目前信息系统能够达到的最高等级。此种信息系统具备目前最强的容灾能力。此种系统通常用于关键业务活动， 如证券交易、 武器控制、 航空航天等。最可用表1 可用性的等级

技术方案描述优点缺点1，无法确保备用服务器上的数据与主服务器一致。冷备服务器技术主服务器提供服务时，备用服务器不开启。最简单、最直接2，服务器切换时间长。3，需要人工干预。4，需要硬件冗余。主服务器对外提供服务，备份服务器处于活服务器集群的热备技术动的监控状态。主备服务器之间通过心跳线1，服务器切换时间短。1，一般采用共享磁盘。2，需要硬件冗余。来探测对方的状态，主服务器发生故障时，2，服务器可以自动切换。通过一系列脚本程序切换到备用服务器。通过虚拟化可以让多套OS 运行在同一台服1，服务器切换时间短。2，服务器可以自动切换。3，硬件共享程度高。服务器虚拟化技术务器上，共享宝贵的CPU、内存、总线、IO接口等资源。物理服务器存在单点风险。表2 服务器高可用技术的比较

14

Focus本期热点

开源数据库软件在功能和性能上并没有明显优势。但是，考虑到运维成本和计算机系统的可用性等级，开源数据库是可以满足“高可用”的需求的。现在主流的开源数据库包括MySQL,MySQL的分支，PostgreSQL, PostgreSQL的分支，Firebird和各类内存数据库等。从数据库高可用的支持上讲，MySQL是最好的。表3展示了MySQL高可用的一些方案。

对以上高可用技术的优缺点进行分析后，我们做出如下决定：在服务器高可用上采用“服务器集群的热备技术”，集群只有双节点，即俗称的热备技术。在

数据库高可用上采用MySQL复制。值得注意的是，虽然MySQL复制存在如下缺点：主备数据库切换时由于需要更改IP而无法自动进行，但当MySQL复制技术和热备技术组合后，该缺点就消失了。

确定服务器和数据库高可用方案后，具体的部署如图1所示。

3 高可用方案设计

为了实现上节所提到的高可用方案的部署，我们需要使用一些软件。

3.1 服务器高可用的软件选择及配置

技术方案描述优点容易实施、成本低、实现方便、维护方便。安全稳定、自动切换，保证主备数据一致性。缺点1，主数据发生故障后，需要人工干涉更改被数据库IP。2，切换后，数据可能会丢失。1，物理上，有单点故障的风险。2，需要共享存储设备。MySQL复制将数据从主服务器数据库复制到备数据库中。MySQL+共享存储主备数据库指向同一个物理存储介质。DRBD(Distributed Replicated Block Device)，是一种块设备的实现。数据写入本地的DRBDMySQL+Linux DRBD设备上的文件系统时,数据会同时被发送到网络中的另外一台主机之上， 并以完全相同的形式记录在一个文件系统中。在无共享的相关系统中部署数据库的 Cluster。MySQL集群每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。可用性非常高，性能非常好1，硬件冗余量大。2，维护复杂，成本高。安全稳定、自动切换，保证主备数据一致性。维护成本高于MySQL复制。表3 MySQL数据库高可用性方案

图1 高可用部署方案

15

本期热点Focus

在服务器高可用方面，我们采用开源软件Keepalived来实现在主服务故障后自动切换到备服务器。

Keepalived是一个基于VRRP协议来实现的WEB 服务高可用方案，可以利用其来避免单点故障。一个WEB服务会有至少2台服务器运行Keepalived，一台为主服务器，一台为备份服务器，但是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，本要写明当9秒收不到数据回复，就杀死Keepalived进程。

3.2 数据库高可用的软件选择及配置

选定了MySQL复制技术作为数据库的高可用方案后，需要进一步对其中的配置进行选择。MySQL复制可以分为两个维度，一个是主从/主主复制的维度，另一个是异步/半同步复制的维度。（1）主从复制和主主复制。

当备份服务器收不到这个消息的时候，即主服务器故障的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。

从图一可见，应用服务器和MySQL服务器都使用了Keepalived。主备MySQL服务器通过Keepalived绑定相同的虚拟IP （IP2），主应用服务器通过IP1同主MySQL服务器进行交互。当主MySQL服务器发生故障时，Keepalived自动切换到备MySQL服务器，主应用服务器继续通过IP1同备MySQL服务器进行交互。同样，用户通过虚拟IP（IP1）访问应用服务器，主备应用服务器的切换也是由Keepalived自动控制。

为了使用Keepalived，必须明确两项配置。一，主备机的配置。若Keepalived要指定主机，则在配置文件中必须指定该机器为MASTER。这样，无论何时，只要这台机器启动，就会自动成为主机。当然，Keepalived也可以不明确指定主机。这样，所有的机器都为备机，即配置文件中都写为BACKUP。如此，哪台机器先启动，哪台机器就自动成为了主机，而当它发生故障，服务切换到备机后，只要备机运行正常，即使它重新启动，也不会再成为主机。二，监控切换脚本。当备机接收不到主机上Keepalived心跳时，就会发生主备切换。只要主机上Keepalived进程终止，则备机就接收不到心跳。因此，明确主机故障的场景后，就可以写监控切换脚本，只要达到这些场景，脚本就杀死Keepalived进程，从而达到主备切换的目的。

这两项Keepalived的配置都根据计算机系统的实际需求而定。假设我们Web应用的高可用需求是：（1）只要机器能正常提供服务，就不发生自动切换。（2）当用户请求数据，9秒没有回复，则表示主机故障。根据以上需求，我们可以选择出：Keepalived的主备机配置为全部指定BACKUP，Keepalived的监控切换脚

MySQL的主从复制指的是：在复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器，数据从主机向备机单向复制的过程。它的优点在于：

1) 使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。

2) 对于读数据库要求很高，但对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的PC服务器来扩展从数据库的数量，将读压力分散到多台从数据库上面，即可解决数据库端的读压力瓶颈。

MySQL的主主复制指的是：在复制过程中，两台服务器的任何一台上面的数据库存发生了改变都会同步到另一台服务器上，这样两台服务器互为主从，并且都能向外提供服务。它的优点在于：

1) 快速切换。若是MySQL主从复制，在数据库发生切换时，备数据库需要手动提升为主数据库，并且手动更改一些数据库配置。而对于主主复制，由于数据库服务器上的配置完全一致，并不需要手动介入。

2) 快速恢复。若是MySQL主从复制，当故障的数据库服务器修复后，恢复数据时一定需要手工介入。而对于主主复制，由于数据库服务器上的配置完全一致，只要恢复时复制程序没有异常，恢复数据可以自动进行。

（2）异步复制和半同步复制。

MySQL的异步复制的基本原理如下：当主数据库有更新的时候，主数据库会把更新操作的SQL写入二进制日志(Binlog)，并维护一个二进制日志文件的索引，以便于日志文件轮回（Rotate）。在从数据库启动异步复制的时候，从数据库会开启两个线程，其中一个线程I/O连 接主库，要求主数据库把二进制日志的变化部分传给从数据库，并把传回的日志写入本地磁盘。另一

16

Focus本期热点

个线程SQL则负责读取本地写入的二进制日志，并在本地执行，以反映出这种变化。值得注意的是，主数据库上所有的更新操作写入Binlog之后并不确保所有的更新都被复制到从数据库之上，因此复制时存在数据丢失的情况。

MySQL的半同步复制是对异步复制的改进。主数据库将BinLog更新部分发送给备数据库后，会等待备数据库的收到确认。它的原理是：主数据库先提交事务，然后将二进制日志的变化部分传给从数据库并等待它的确认。从数据库将日志变化部分缓存到本地并发送收到确认。主数据库收到确认后告诉应用可以继续。值得一提的是，若主数据库在一段时间内未收到从数据库的确认，它会自动转入异步复制模式，直到收到确认后再转入半同步复制模式。主数据库等待从数据库的确认时，可以继续其他的事务。MySQL复制时会统计出半同步复制下的事务数和异步复制下的事务数。半同步复制仍可能产生数据丢失，但与同异步复制比较，半同步时，若主数据库在规定时间内未收到从数据库的确认，应用是可知的。

经过对以上两个维度的研究分析，主主半同步复制从理论上说是MySQL复制最优的高可用方案，因此我们选用MySQL主主半同步复制。

Server1(作为主机)CPU内存操作系统IPKeepalived数据库虚拟IPIntel(R) Xeon(R) CPU E7- 4820 @ 2.00GHz×4120GRHEL6196.123.131. 高可用方案测试

为了验证已选的高可用方案是否可行，我们进行了专项测试。测试的内容主要包括两个方面：

1. 服务器的高可用测试(Keepalived)。2. 数据库的高可用测试(MySQL)。

测试的目的是通过以下指标来验证既定高可用方案的正确性：

1. 主机故障时能否自动切换到备机。2. 主机故障时主备机的数据丢失情况。3. 主机恢复后主备数据能否自动同步。

测试时，我们将应用和数据库合并到一台物理服务器上。这样的合并对测试目的和结果没有影响。测试的环境如表4所示：

4.1 服务器的高可用测试（Keepalived）

为了模拟主服务器发生故障，我们设计了以下三种场景。

1. 大量数据插入时主机断电。

2. 大量数据插入时杀死主机的数据库复制进程。3. 大量数据插入时拔掉主机网线。

针对上一章提到的Web应用的高可用需求，使用以上三个场景进行测试，得出如下结果，如表5所示。

测试结果表明，使用Keepalived软件，主机故障

Server2(作为从机)Intel(R) Xeon(R) CPU E7- 4820 @ 2.00GHz×4120GRHEL6196.123.131.10keepalived 1.2.2mysql 5.5.17196.123.131.50表4 测试环境

Web应用的高可用需求只要机器能正常提供服务，就不发生自动切换。当用户请求数据，9秒没有回复，就需要切换。切换后，使用原来IP，仍可访问服务器。结果√√√表5 服务器高可用测试结果

17

本期热点Focus

时能自动切换到备机，并且备机继续对外提供服务。4.2 数据库的高可用测试（MySQL）

首先，需要回答这个问题：主机故障时主备机的数据丢失情况如何？

鉴于MySQL复制的两大维度，即主从/主主复制和异步/半同步复制，本文设计以下四项测试内容：

1. 数据库主从异步下的可靠性测试。2. 数据库主从半同步下的可靠性测试。3. 数据库主主异步下的可靠性测试。4. 数据库主主半同步下的可靠性测试。

这里同样采用上面提到的三个场景模拟主数据库故障。在主数据库发生故障时，它正以每秒3800条记录的速度向从数据库复制。数据按事务提交，每个事务有1000条记录。表6显示了测试的结果：

从表6可知，在大量数据插入时拔掉主机网线，主从异步和主从半同步复制都发生了数据丢失。表7和表8分别显示了数据丢失的详细信息。

由表7和表8可见：在主数据库以每秒3800条

记录的速度向从数据库复制数据时，拔掉主数据库服务器网线，MySQL复制配置若为主从异步复制，则有20%的概率发生数据丢失，每次均丢失一个事务的数据，即1000条记录；MySQL复制配置若为主从半同步复制，则有10%的概率发生数据丢失，每次均丢失一个事务的数据，即1000条记录。

通过测试，可以发现MySQL复制无论是异步复制还是半同步复制，都可能发生数据丢失，但半同步复制的数据丢失概率比异步的要低，这个结果同理论分析是一致的。

其次，需要回答这个问题：主机恢复后主备数据能否自动同步？

测试中，MySQL复制的配置若为主主复制，当主数据库恢复时，数据是自动同步的。具体结论如表9所示。

但是，MySQL主主复制有主键冲突（Primary Key Collision）的风险。所谓主键冲突，即两个互为主备的数据库中的某一张表里，数据不同但主键相同，因此

　大量数据插入时主机断电大量数据插入时杀死主机MySQL进程大量数据插入时拔掉主机网线主从异步一致一致有不一致主从半同步一致一致有不一致主主异步一致一致一致主主半同步一致一致一致执行次数2510表6 主机故障时主备机的数据丢失情况

次数123456710断网时主机数据库记录数680,000687,000699,000704,000692,0007,000594,000594,000596,000607,000断网时备机数据库记录数680,000686,000699,000704,000692,0007,000594,000593,000596,000607,000表7 主从异步部署下大量数据插入时拔掉主机网线

18

Focus本期热点

次数123456710断网时主机数据库记录数680,000687,000699,000704,000692,0007,000594,000594,000596,000607,000断网时备机数据库记录数680,000686,000699,000704,000692,0007,000594,000593,000596,000607,000表8 主从半同步部署下大量数据插入时拔掉主机网线

复制方案主从复制主主复制主机恢复后主备数据能否自动同步否是原因需要手动修改主备数据库的配置。数据库服务器互为主备，自动同步表9 主机恢复后主备数据自动同步情况

在数据相互复制时发生了冲突。它是主主复制的一个常见问题。在本文提出的高可用方案中，由于使用了Keepalived软件，因此保证了在正常情况下，只存在单向复制，主从数据库不会有主键冲突。但由于在主数据库故障时可能有数据丢失，因此在恢复主数据库时，可能产生主键冲突。主键冲突属于复制异常，需要人工处理。

综上所述，主机恢复后，MySQL主主复制可以自动同步数据库，但在发生复制异常时，需要人工应急。5 结论

若某些Web应用在高可用上要求降低单点故障风险，缩短主备机切换时间，降低运维成本，但又同时允许在主机宕机时有少量数据丢失，那么可以采用这样一套高可用方案：在服务器高可用方面采用开源软件Keepalived,它使得服务器只有在指定条件下才自动切换，并且服务器对外IP不变；在数据库高可用方面

采用MySQL主主半同步复制，它能有效缩短数据库切换和恢复的时间，并在一定程度上降低主数据库宕机时数据的丢失率。

与昂贵的商业软件相比，开源软件Keepalived和MySQL节约了软件购买和服务的成本。在实验过程中，我们发现Keepalived和MySQL的安装、部署以及配置脚本的维护都十分便利。而实验结果更是说明了当允许少量数据丢失时，Keepalived加MySQL是不错的高可用方案。

经过理论研究分析和专项测试，表明本文所提出的采用开源软件Keepalived和MySQL构建的高可用系统有如下优点：

a) 提升系统的高可用性。

b) 采用开源软件，降低运维成本。部署简单，维护方便。

19