SQL数据库高可用 - 解决方案

SQL数据库高可用 - 是什么?

• 高可用性=可靠性
• 高可用的本质是通过技术和工具提高可靠性,尽可能长时间保持数据可用和系统运行(正常运行时间)。

实现高可用性的原则

• 消除单点故障
• 通过冗余机制实现快速恢复
• 实现容错

高可用性要求的实际上是对可靠性的要求，从本质上来说，是通过技术和工具来提高可靠性，尽可能长时间保持数据的可用和系统的正常运行时间。实现高可用性的原则为排除单点故障、通过冗余实现快速恢复，并且具有容错机制。

关于可靠性的关键词

恢复

• 实现可靠性的最简单的方法,从错误中恢复。

逻辑备份

• 逐行复制数据,通常将数据从二进制形式转换为sQL语句来复制。

物理备份

• 从磁盘存储层复制数据的二进制副本。

冗余

• 具有两个或多个在系统中扮演相同角色的组件。

可扩展性

• 缩短存储和检索数据的时间。

容错

• 发现错误,从事件中恢复。

MYSQL/SQL数据库高可用解决方案

数据库高可用性解决方案目前大致分为5种，按照高可用的级别（99.9999%为最高级）排序依次为，主从复制、具有自动故障转移功能的主从复制、利用共享存储、OS 或虚拟化软件实现主备架构、MySQL Group Replication 群组复制，以及 MySQL NDB Cluster。

• MySQL Replication：允许数据从一台实例上复制到一台或多台其它的实例上。
• MySQL Group Replication：群组复制提供更好的冗余性、自动恢复以及写入扩展。
• MySQL InnoDB Cluster：基于群组复制，提供了易于管理的 API、应用故障转移和路由、易于配置，提供比群组复制更高级别的可用性。
• MySQL NDB Cluster：容易与 MySQL InnoDB Cluster 混淆，是另外一款产品，提供更高级别的可用性和冗余性。适用于分布式计算环境，使用内存型的 NDB 存储引擎。关于这款产品的详细内容将不会在这里介绍。

SQL数据库高可用 - 基本原理

• 经典的主从复制是 MySQL 原生的复制功能，采用异步方式，如图片最上面显示的原理，主服务器执行更改数据的事务后，会产生 binlog，之后 binlog 会被发送到从服务器变成 relay log，与此同时，主服务器会对应用提交返回。从服务器接收到 relay log 后，会通过一个 applier 的线程对日志里面的内容进行施放，使产生的数据更改写入从服务器，之后产生自己的 binlog，进行提交。
• 采用异步的方式，在发生网络问题和服务器损坏的情况下（从服务器未接收到日志，主服务器已经提交，并且提交后主服务器彻底损坏）会丢失数据，为了防止数据丢失，半同步复制在异步的基础上增加了一个日志确认的环节，在从服务器接收到日志后，返回给主服务器一个应答，之后主服务器才能对应用提交返回。
• 作为 MySQL 目前最新的复制方式，群组复制 MGR 可以通过群组内任意服务器对数据进行更新，而不是像前面两种有主从之分。为此群组复制增加了一个验证步骤，通过验证的事务才能进行提交，提交后群组内其它成员同样对日志进行释放，提交。

依靠什么来决定使用哪一种高可用性技术？

很多企业都需要他们的全部或部分数据高可用，比如说在线购物网站，在线商品数据库必7*24小时在线，否则在竞争激烈的市场环境下，宕机时间就意味着流失客户和收入当然，在一个理想的世界中，所有的关键数据都会时刻在线，但在现实世界中，会存在各种各样的原因导致数据库不可用，由于无法预估灾难出现的时间和形式，需要提前采取措施来预防各种突发情况，因此SQL Server提供了多种高可用性技术，这些技术主要包括：集群、复制、镜像、日志传送、AlwaysOn可用性组以及其它诸如文件组备份还原、在线重建索引等单实例的高可用性技术。使用何种高可用性技术并不是随意挑一个熟悉技术直接使用，而是要基于业务和技术综合考虑。因为没有一项单独的技术可以实现所有的功能。如何根据具体的业务和预算采用这些技术，就是所谓的高可用性策略。

在设计高可用性策略时应该首先考虑下述因素：

• RTO（Recovery Time Objective）也就是恢复时间目标，意味着允许多少宕机时间，通常用几个9表示，比如说99.999%的可用性意味着每年的宕机时间不超过5分钟、99.99%的可用性意味着每年的宕机时间不超过52.5分钟、99.9%的可用性意味着每年的宕机时间不超过8.75小时。值得注意的是，RTO的计算方法要考虑系统是24*365，还是仅仅是上午6点到下午9点等。您还需要注意是否维护窗口的时间在算在宕机时间之内，如果允许在维护窗口时间进行数据库维护和打补丁，则更容易实现更高的可用性。
• RPO（Recovery Point Objective）-也就是恢复点目标，意味着允许多少数据损失。通常只要做好备份，可以比较容易的实现零数据损失。但当灾难发生时，取决于数据库损坏的程度，从备份恢复数据所需要的时间会导致数据库不可用，这会影响RTO的实现。一个早期比较著名的例子是某欧美的银行系统，只考虑的RPO，系统里只存在了完整备份和日志备份，每3个月一次完整备份，每15分钟一次日志备份，当灾难发生时，只能够通过完整备份和日志备份来恢复数据，因此虽然没有数据丢失，但由于恢复数据花了整整两天时间，造成银行系统2天时间不可用，因此流失了大量客户。另外一个相反的例子是国内某在线视频网站，使用SQL Server作为后端关系数据库，前端使用了No-SQL，定期将No-SQL的数据导入关系数据库作为备份，当灾难发生时最多允许丢失一天的数据，但是要保证高可用性。
• 预算 –RTO和RPO统称为SLA（服务水平协议），设计高可用性策略时，要根据业务来衡量满足何种程度的SLA，这要取决于预算以及衡量不同SLA在故障时所造成的损失。SLA并不是越高越好，而是要基于业务需求，通常来说，在有限的预算之下很难实现很高的SLA，并且即使通过复杂的架构实现较高的SLA，复杂的架构也意味着高运维成本，因此需要在预算范围之内选择合适的技术来满足SLA。

SQL Server中所支持的高可用特性

SQL Server中所支持的高可用性功能与版本息息相关，企业版支持所有的高可用性功能，这些功能包括：

• 故障转移集群
• 数据库镜像
• 事务日志传送
• 数据库快照
• AlwaysOn可用性组
• 热加载内存
• 在线索引操作
• 数据库部分在线（只还原了主文件组或主文件组和额外的NDF文件）

事务日志传送

• 事务日志传送提供了数据库级别的高可用性保护。日志传送可用来维护相应生产数据库（称为“主数据库”）的一个或多个备用数据库（称为“辅助数据库”）。发生故障转移之前，必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。日志传送具有支持多个备用数据库的灵活性。如果需要多个备用数据库，可以单独使用日志传送或将其作为数据库镜像的补充。当这些解决方案一起使用时，当前数据库镜像配置的主体数据库同时也是当前日志传送配置的主数据库。
• 事务日志传送可用于做冷备份和暖备份的方式。

常见备份方式
根据主机和备机之间同步数据的程度，备份可以分为三种情况，分别为冷备份、暖备份和热备份。

冷备份

• 冷备份也就是所谓的备份，备用服务器被配置用于接受主服务器的数据，当出故障时，手动将数据还原到主数据库，或是重新配置程序的连接字符串或权限来使得备份数据库上线。

暖备份

• 暖备份也就是主服务器数据会不停的将日志传送到备用服务器（间隔不定，可以是15分钟，30分钟，1分钟等等），在这方式下，主服务器到备份服务器通常是异步更新，所以不能保证主服务器和备份服务器数据一致。此外，该方案通常不会实现自动故障监测和故障转移。

热备份

• 热备份也就是主服务器的数据自动在备份服务器上进行同步，大多数情况下都会包含自动的故障监测和故障转移，并且能够保证主服务器和备份服务器的数据一致性。提示：随着冷备份到暖备份到热备份，成本会直线上升。

SQL数据库高可用 - 镜像概述

数据库镜像维护一个数据库的两个副本，这两个副本必须驻留在不同的 SQL Server 数据库引擎服务器实例上。 通常，这些服务器实例驻留在不同位置的计算机上。 启动数据库上的数据库镜像操作时，在这些服务器实例之间形成一种关系，称为“数据库镜像会话”。
其中一个服务器实例使数据库服务于客户端（“主体服务器”）， 另一个服务器实例则根据镜像会话的配置和状态，充当热备用或温备用服务器（“镜像服务器”）。 同步数据库镜像会话时，数据库镜像提供热备用服务器，可支持在已提交事务不丢失数据的情况下进行快速故障转移。 未同步会话时，镜像服务器通常用作热备用服务器（可能造成数据丢失）。
在“数据库镜像会话”中，主体服务器和镜像服务器作为“伙伴”进行通信和协作。 两个伙伴在会话中扮演互补的角色：“主体角色”和“镜像角色”。 在任何给定的时间，都是一个伙伴扮演主体角色，另一个伙伴扮演镜像角色。 每个伙伴拥有其当前角色。 拥有主体角色的伙伴称为“主体服务器”，其数据库副本为当前的主体数据库。 拥有镜像角色的伙伴称为“镜像服务器”，其数据库副本为当前的镜像数据库。 如果数据库镜像部署在生产环境中，则主体数据库即为“生产数据库”。
数据库镜像涉及尽快将对主体数据库执行的每项插入、更新和删除操作“重做”到镜像数据库中。 重做通过将活动事务日志记录的流发送到镜像服务器来完成，这会尽快将日志记录按顺序应用到镜像数据库中。 与逻辑级别执行的复制不同，数据库镜像在物理日志记录级别执行。 从 SQL Server 2008 开始，在事务日志记录的流发送到镜像服务器之前，主体服务器会先将其压缩。 在所有镜像会话中都会进行这种日志压缩。

 数据库镜像的优点

数据库镜像是一种简单的策略，具有下列优点：

• 提高数据库的可用性

发生灾难时，在具有自动故障转移功能的高安全性模式下，自动故障转移可快速使数据库的备用副本联机（而不会丢失数据）。 在其他运行模式下，数据库管理员可以选择强制服务（可能丢失数据），以替代数据库的备用副本。 有关详细信息，请参阅本主题后面的角色切换。

• 增强数据保护功能

在 SQL Server 2008 Enterprise 或更高版本上运行的数据库镜像伙伴会自动尝试解决某些阻止读取数据页的错误。 无法读取页的伙伴会向其他伙伴请求新副本。 如果此请求成功，则将以新副本替换不可读的页，这通常会解决该错误。

• 提高生产数据库在升级期间的可用性

为了尽量减少镜像服务器的停机时间，您可以按顺序升级承载故障转移伙伴的 SQL Server 实例。 这样只会导致一个故障转移的停机时间。 这种形式的升级称为“滚动升级”。数据库镜像实际上是个软件解决方案，同样提供了数据库级别的保护，可提供几乎是瞬时的故障转移，以提高数据库的可用性。数据库镜像可以用来维护相应生产数据库（称为“主体数据库”）的单个备用数据库（或“镜像数据库”）。因为镜像数据库一直处于还原状态，但并不会恢复数据库，因此无法直接访问镜像数据库。但是，为了用于报表等只读的负载，可创建镜像数据库的数据库快照来间接地使用镜像数据库。数据库快照为客户端提供了快照创建时对数据库中数据的只读访问。每个数据库镜像配置都涉及包含主体数据库的“主体服务器”，并且还涉及包含镜像数据库的镜像服务器。镜像服务器不断地使镜像数据库随主体数据库一起更新。数据库镜像在高安全性模式下以同步操作运行，或在高性能模式下以异步操作运行。在高性能模式下，事务不需要等待镜像服务器将日志写入磁盘便可提交，这样可较大程度地提高性能。在高安全性模式下，已提交的事务将由伙伴双方提交，但会延长事务滞后时间。数据库镜像的最简单配置仅涉及主体服务器和镜像服务器。在该配置中，如果主体服务器丢失，则该镜像服务器可以用作备用服务器，但可能会造成数据丢失。高安全性模式支持具有自动故障转移功能的备用配置高安全性模式。这种配置涉及到称为“见证服务器”的第三方服务器实例，它能够使镜像服务器用作热备份服务器。从主体数据库至镜像数据库的故障转移通常要用几秒钟的时间。数据库镜像可用于做暖备份和热备份。

 数据库镜像术语和定义

• 自动故障转移 (automatic failover)   一种过程，当主体服务器不可用时，该过程将导致镜像服务器接管主体服务器的角色，并使其数据库的副本联机以作为主体数据库。
• 故障转移伙伴 (failover partners)     充当镜像数据库的角色切换伙伴的两个服务器实例（主体服务器或镜像服务器）。是指在负责将服务传输到镜像数据库（但它处于未知状态）的主体服务器出现故障时数据库所有者启动的故障转移。
• 高性能模式 (High-performance mode)  数据库镜像会话异步运行并仅使用主体服务器和镜像服务器。 唯一的角色切换形式是强制服务（可能造成数据丢失）。

• 高安全性模式 (High-safety mode)

数据库镜像会话同步运行并可以选择使用见证服务器、主体服务器和镜像服务器。

• 手动故障转移 (manual failover)

是指在负责将服务从主体数据库传输到镜像数据库（处于同步状态）的主体服务器仍在运行时数据库所有者启动的故障转移。

• 镜像数据库 (mirror database)

通常与主体数据库完全同步的数据库副本。

• 镜像服务器 (mirror server)

在数据库镜像配置中，镜像数据库所在的服务器实例。

• 镜像服务器 (mirror server)

在数据库镜像配置中，镜像数据库所在的服务器实例。

• 主体数据库 (principal database)

数据库镜像中的一种读写数据库，其事务日志记录将应用到数据库的只读副本（镜像数据库）。

• 主体服务器 (principal server)

在数据库镜像中，是指当前作为主体数据库的数据库所属于的伙伴。

• 重做队列 (redo queue)

收到的等待镜像服务器磁盘的事务日志记录。

• 角色 (role)

主体服务器和镜像服务器担任互补的主体角色和镜像角色。 也可以由第三个服务器实例来担任见证服务器角色。

• 角色切换 (role switching)

镜像接管主体角色。

• 发送队列 (send queue)

在主体服务器的日志磁盘累积的未发送的事务日志记录。

• 会话 (session)

是指主体服务器、镜像服务器和见证服务器（如果存在）之间进行数据库镜像期间形成的关系。

镜像会话启动或继续后，将累积在主体服务器上的主体数据库日志记录发送给镜像服务器的过程，此过程将这些日志记录尽快写入磁盘，以便与主体服务器保持同步。

• 事务安全 (Transaction safety)

一种镜像特定的数据库属性，用于确定数据库镜像会话是同步运行还是异步运行。 有两种安全级别：FULL 和 OFF。

• 见证服务器 (Witness)

仅用于高安全性模式，SQL Server 的一个可选实例，它能使镜像服务器识别何时要启动自动故障转移。 与这两个故障转移伙伴不同的是，见证服务器并不能用于数据库。 见证服务器的唯一角色是支持自动故障转移。

复制严格来说并不算是一个为高可用性设计的功能，但的确可以被应用于高可用性。复制提供了数据库对象级别的保护。复制使用的是发布-订阅模式，即由主服务器（称为发布服务器）向一个或多个辅助服务器或订阅服务器发布数据。复制可在这些服务器间提供实时的可用性和可伸缩性。它支持筛选，以便为订阅服务器提供数据子集，同时还支持分区更新。订阅服务器处于联机状态，并且可用于报表或其他功能，而无需进行查询恢复。SQL Server 提供四种复制类型：快照复制、事务复制、对等复制以及合并复制。

AlwaysOn可用性组

AlwaysOn可用性组是SQL Server 2012推出的新功能。同样提供了数据库级别的保护。它取数据库镜像和故障转移集群之长，使得业务上有关联的数据库作为一个可用性组共同故障转移，该功能还拓展了数据库镜像只能1对1的限制，使得1个主副本可以对应最多4个辅助副本（在SQL Server 2014中，该限制被拓展到8个），其中2个辅助副本可以被作为热备份和主副本实时同步，而另外两个异步辅助副本可以作为暖备份。此外，辅助副本还可以被配置为只读，并可用于承担备份的负载。

相关案例：

VMware vSAN 存储虚拟化

IT系统集成 & 弱电系统

容灾备份解决方案

企业服务

VMware服务器虚拟化 & 解决方案

煜企智能在网络安全和虚拟化、系统集成、弱电系统、系统集成、机房建设中拥有丰富的案例，您有任何想法和需求，随时致电煜企智能获得咨询和支持。

微信扫码 | 加入我们