数据库高可用综述

62 阅读 0 评论 41 点赞

我是靠谱客的博主安详书本，最近开发中收集的这篇文章主要介绍数据库高可用综述，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

数据库高可用综述

一、发展前景以及需求分析

伴随着计算机和因特网的快速发展,数据库成了计算机信息系统的核心基础部分,广泛应用于金融、企业、能源、电信、政府等重点行业,随着数据量和业务量的不断高速增长，以及高并发访问等问题的出现，使得传统的单机数据库已经难以满足需求，提高数据库系统性能和可用性已成为亟待解决的问题，高可用性数据库也因此受到人们的广泛关注。在这个信息爆炸的时代,互联网得到了迅速地普及,尤其是互联网上的商业服务的迅猛发展,许多行业对计算机服务系统的高可用性的要求日益增高。如果服务器很长一段时间停止工作将会导致许多用户需求转向企业的竞争对手,这不仅仅会给企业带来资产损失,还可能会让企业失去了客户的信任,进而可能失去大量的潜在客户,继而承担巨大的经济损失。
许多人认为,当前的数据库技术已经非常的成熟安全,及时做好备份,发生故障时可以保证万无一失,可是,实际上并没有那么简单,几乎所有的数据库系统故障解决方案,都达不到集群系统这样具有良好的高可用性。
总的来说,对于目前的数据库而言,提高处理速度、数据高可用性、安全性和扩展性,都是急于要解决的问题。数据库的高可用性已经成为判断数据库系统性能高低的最重要的标准,数据库是用来存储最终应用的结果,因此数据库是整个商业智能解决方案中最重要的组成部分。现如今,计算机被应用到各行各业,使得数据库技术得到了高速发展。日常生活中的一些信息,企业生产销售信息都保存在计算机的数据库里,这些数据一旦由于系统损坏,造成大量丢失,将会给企业带来重大的经济损失。

二、数据库高可用原理

高可用是一种系统，在经过专门的设计之后，可以让系统的可用性从99.9%上升至99.999%，从而减少了系统停机的时间。一般可用性系统每年停机时间为8.8小时，而高可用性系统每年停机时间仅5.3分钟，相较而言，系统服务的高度可用性得到了保证。与此同时，高可用性系统尽可能的缩短了因日常维护、突发情况所导致的停机时间。实现高可用主要通过以下三种方式：
    1.双机热备方式
    工作原理：该方式需要主机和备用机，称为“双机”，其中的一台主机处于工作状态，备用机处于监控准备状态。当主机出现宕机的情况时，备用机便接管主机的工作，等到主机维修至正常状态时，备用机再将工作传递回主机。主机与备用机间交接工作时所用的切换方式由使用者设定，交接的数据通过共享存储的方式保证其完整性和一致性。但是，由于主机一般不存在经常性宕机的情况，因此备用机长期处于监控准备状态，也就是不工作的状态，就导致了资源的浪费。
    2.双机双工方式
    工作原理：该方式需要两台主机，二者同时运行着各自的工作，与此同时，随时监控着对方的工作状态。当其中一台主机出现宕机的情况，另一台主机则直接接管出现宕机情况的主机的工作，并且要保证工作的质量。因此，该方式对两台主机的性能要求较高，要有一定的性能冗余，才不会在接管另一台主机的工作时也出现宕机的情况。两台主机接管工作时的数据都存放在共享存储中。
    3.集群系统方式
    工作原理：该方式有多台主机同时工作，当其中一台主机出现宕机情况时，其他的主机则直接接管它的工作，在该主机修复完成后，系统会自动给它分配新的任务。相较于以上两种方式，该方式的不同之处就在于，交接出去的工作不会再传递回来，该主机将接收新的工作。

三、数据库高可用功能

高可用性是系统的一个特性，保证系统能在足够长的时间内提供指定程度的服务等级。再细化一下，可以说是在有限的故障条件下，提供一定等级的稳定服务.。对于应用层来说，根据业务特点可以很方便地设计成无状态的服务，在大多数互联网公司中，在业务层的最上层使用动态DNS、LVS、HAProxy等负载均衡组件，配合Docker和Kubernetes实现弹性伸缩，能够很容易实现应用服务的高可用。而数据库能能够做到高可用性的关键就在其有着消除单点问题、自动故障恢复、在线扩容、在线表结构变更、数据量大的解决方案等几个特殊性的功能，拿在线扩容举例，随着数据库的数据量越来越大，Scale是不可避免的问题。对于数据库来说，技术层面最大的追求就在于如何不停服务地对数据库节点进行Scale操作，这是非常有挑战性的事情。以中间件/Proxy方案来说，很多时候不得不提前对数据量进行规划，把扩容作为重要的计划来做，从DBA到运维到测试到开发人员，很早之前就要做相关的准备工作，真正扩容时为了保证数据安全，经常会选择停服务来保证没有新的数据写入，新的实例数据同步后还要做数据的一致性校验。当然业界大公司有足够雄厚的技术实力，可以采用更自动化的方案，将扩容停机时间尽量缩短（但很难缩减到0），但大部分中小互联网公司和传统企业依然无法避免较长时间的停服务问题。TiDB完全实现了在线的弹性扩容，主要基于Placement Driver的调度和Raft算法。

四、主要技术以及适应场景

数据库高可用是一个复杂的系统工程，其基本技术主要有： HADR、 HACMP、 数据复制，存储层容灾和DPF高可用。在不同场景，不同的业务连续性级别下，可以组合使用这几种技术，以实现从存储，网络，系统，数据库到应用的高可用技术。

（一）SQL复制和Q复制

技术简介
SQL 复制捕获源表的更改并使用 CD 表来存储已经提交的事务性数据，然后从 CD 表中读取这些更改并将它们复制到相应的目标表。 SQL 复制可以应用在各种需要的环境，包括容量补偿，给数据仓库输送数据以及审计更改历史记录。用户可以选择相隔一段时间或仅在一段时间内复制。通过连续时间内的复制，应用程序可以捕捉到实时的数据。Q 复制可以在很短的时间内复制大量的数据。 Q 复制将捕获源表的更改并将已提交的事务转化为消息。Q 复制不使用 CD 表，当 Q 复制读取到数据后，将消息通过 MQ 消息队列发送到目标。目标系统将会从队列中读取消息并将消息转化为相应的事务提交到目标表。目前 SQL 复制支持非 DB2 数据源到 DB2 以及 DB2 到非 DB2 数据源的复制，而 Q 复制只支持 DB2 到非 DB2 数据源的复制。

适用场景
SQL复制主要应用于相同局域网内。Q复制远程好一点，因为在网络比较差的时候，WebSphere MQ可以缓存一段时间数据。Q复制一般结合HADR比较多，用于实现数据远程异地复制（比如中国烟草总公司容灾中心）。

（二） HACMP

技术简介
Hacmp(High Availability Cluster Multi-Processing)双机热备份软件的主要功能是提高客户计算机系统及其应用的可靠性，而不是单台主机的可靠性。HACMP群集可以按几种方式配置以满足不同类型的处理要求。并行访问模式适合于所有处理器多必须在相同工作负载下运行并共享相同数据的环境。在交互备份模式中，处理器共享工作负载并互相备份。闲置备用设备允许用一个节点备份群集器中的其他节点

适用场景
Cascading用于主备机硬件性能有较大差别的环境，节约成本，这个对于不差钱的运营商、航空、银行、政府绝对不会采用。Rotating适用于对可用性要求较高的场景，电信行业的数据业务，增值业务，彩铃等产品多采用这种方式。

（三）DB2 HADR

技术简介
HADR全称为High Availability Disaster Recovery ，一个HADR环境需要两台数据库服务器：主数据库服务器（primary）和备用数据库服务器（standby）。当主数据库中发生事务操作时，会同时将日志文件通过TCP/IP协议传送到备用数据库服务器，然后备用数据库对接受到的日志文件进行重放（Replay），从而保持与主数据库的一致性。当主数据库发生故障时，备用数据库服务器可以接管主数据库服务器的事务处理。此时，备用数据库服务器作为新的主数据库服务器进行数据库的读写操作，而客户端应用程序的数据库连接可以通过自动客户端重新路由（Automatic Client Reroute）机制转移到新的主服务器。当原来的主数据库服务器被修复后，又可以作为新的备用数据库服务器加入HADR。通过这种机制，DB2 UDB实现了数据库的灾难恢复和高可用性，最大限度的避免了数据丢失。

适用场景
HADR，是IBM DB2数据库上的数据库级别的高可用性数据复制机制，最初被应用于Informix数据库系统中，IBM收购Informix之后，这项技术就应用到了新的DB2发行版中。HADR有一主一备数据库，在9.7之前备机不可读，9.7之后备机可读可以降低主数据库的负担。
在数据专线带宽足且稳定的情况下，在要求主备完全数据无损的时候，推荐用同步方式传送，或者能容忍一定少量的损失，可以用准同步，但是推荐在在生产中心和同城的灾备中心之间（LAN或者MAN），如果在1000公里以上带宽和时延都没什么保障的话，最好还是用异步的方式，如果更差或者对OLTP的实时性要求较高还可以用超级异步，当然这对流水的损失要有一定的容忍度。HADR有一个弱点就是不能进行数据压缩和加密，如果没有VPN就麻烦了，但是HADR可以集成第三方的SSH软件。而DG本身就集成了SSH进行压缩和加密功能。HADR最要命的是不能支持异构数据库的复制，当然这个也不是他的主要场景。

五、高可用架构

（一）共享储存方案
在共享储存架构当中若干个数据库共享一个存储，其中一个数据库为主，其它的为备用数据库，当主数据库宕机，系统会切换从数据库接管业务，成为新的主数据库。这个架构不存在数据同步的问题，但是对存储和网络有较高的要求。

（二）操作系统实时数据块复制
这里有一个明显的缺点，就是系统只允许一个副本提供服务，无法实现读写分离。此外，当系统宕机，主数据库的进程被中断，切换后需要对宕机的数据库进行数据恢复，需要的时间较长。

（三）数据库级别的主从复制
通过一个主数据库和若干个从数据库，实现主数据库将操作日志发送给各个从数据库，从数据库依据接收到的日志进行数据备份。这样有利于读写分离，同时从数据库当中的热数据能够实现容灾切换及时性。但是还是得注意，在从数据库升级为主数据库之前，一定要完成最新数据同步，否则容易导致数据丢失。

（四）数据库高可用集群
前三种方式是通过数据库日志复制来实现高可用，高可用集群则是通过一致性算法来实现数据的同步，通过数据库多节点一致性同步机制实现多节点同步集群的构建。该方案每个节点都能够进行读写操作，当用户读取其中任一节点数据时，其它节点能够进行数据同步。通过这种方式实现数据容灾也很简单，当其中一节点发生故障，只需断开对该节点的访问，其他节点照常即可。
高可用数据库的优势在于能够实现读写分离，在主数据节点上进行写操作，从数据库分担读操作，从而提升读操作吞吐量和写操作的效率。其次高可用数据库能够有效避免系统升级或者变更时带来的对业务的影响。另外，高可用数据库包含多个从库，在保障主节点性能的情况下，能够有效实现数据的容灾备份要求。不同架构的数据库，其容灾切换的难易程度也不一样。为了保障切换主从数据库后数据的一致性，需要在架构设计前期就考虑到容灾切换的优化。
数据存储高可用的方案本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用。常见的高可用架构有主备、主从、主从切换、主主等接下来我们聊聊每种架构的优缺点。

一、主备架构
1、基本架构拓扑图如下
在这里插入图片描述
整体架构简单，几乎所有的数据库都提供了主备复制的功能，例如Mysql、Oracle、MongoDB等。在这种架构中备库主要承担数据备份的作用，不参与实际业务读写操作，如果把备机改成主机需要人工操作。

2、优缺点分析主备架构的优点就是简单，具体表现有：
对于客户端来说，不需要感知备机的存在，即使灾难恢复后，原来的备机被人工干预修改为主机，客户端只需要简单修改连接地址即可，应用架构不需要做任何改动；主机和备机只需要进行数据复制，不需要进行状态判断和主备切换这类复杂操作。这种架构的缺点也比较明显：备机主要是用于数据备份，如果应用架构没有读写分离设计时会造成成本浪费故障后需要人工干预，无法自动恢复，而人工处理效率又比较低，恢复过程也容易出错。

二、主从架构
主从架构与主备架构只有一字之差，但是对于实际应用架构差距却很大。在主备架构中备库不参与业务操作，而在主从架构中从库是需要参与业务操作的，应用架构需要做读写分离，将写操作写入主库，而读操作从从库读。
1、主从基本架构拓扑图如下
在这里插入图片描述
2、优缺点分析这种架构在少量写和大量读时非常有用。可以把读分摊到多个备库上，减少主库的压力，直到从库给主库造成了太大的负担，或者主从之间的带宽成为瓶颈为止。
相比于主备架构，
它有如下优点：
（1）在主库故障时，读操作相关业务可以继续运行
（2）从库对外提供读能力，发挥了硬件的性能
（3）可以为不同的角色提供不同的从库
缺点：
（1）主从架构中从库需要提供读业务，如果主从复制延迟大，数据会出现不一致情况；
（2）应用架构需要做修改，一般会加入读写分离，复杂度比主备高；
（3）故障后需要人工干预，无法自动恢复，而人工处理效率又比较低，恢复过程也容易出错。

三、主从切换
上面两种架构都存在两个共同问题：
(1)主库故障后，无法进行写操作
(2)主库出了问题后需要人工干预才能将从库切换到主库，而人工切换又可能出现不及时或者切换故障的问题。

基于以上两个问题我们需要一个能自动切换的架构，当主库出了故障后能自动将从库切换成主库，无需运维人员干预。要实现主从切换架构必须要考虑一个关键点：必须要有一个机制能监测到数据库节点的运行状态，以此来决定是否切换。这种架构我们一般会引入一个第三方中介，数据库节点定时向第三方中介汇报自己的状态信息；或者第三方中介定时去数据库节点拉取数据库状态；
在这里插入图片描述
优点：解决了人工干预的问题，大大减少了故障时间，一定程度上保护了运维人员的人生安全
缺点：架构复杂，引入了第三方中介后又需要保证第三方中介的高可用。这里推荐大家了解一下mysql的MHA架构，或者使用ZK、Keepalived自己搭建主从切换架构。

四、主主架构
主主架构又叫主主复制，两台数据库都是主库，互相将数据复制给对方，客户端可以挑选任意一台数据库进行读写操作。
在这里插入图片描述相比于主从切换，主主架构有如下优点：
（1）两台数据库都是主库，不存在切换的概念
（2）客户端无需区分不同角色的主机，随便将读写操作发给哪台数据库。
（3）架构简单

但是允许向两台主数据库写入是一件很危险的事：

AB两台数据库采用自增长主键，A库插入用户后id是1，B库插入用户后id也是1，数据冲突

同时对数据库数据进行更新会出现大问题，加入AB库的表tb都有1个字段col，数值为1。如A库执行 update tb set col = col +1,B库执行update tb set col = col * 2,最终执行完一台数据的值变成了4，另一台数据库的值变成了3，而且没有任何复制错误，一旦出了问题需要好久才能定位。所以主主架构必须要保证数据能够双向复制，对数据的设计有严格的要求，一般适用于那些临时性，可丢失、可覆盖的数据场景。