数据库灾备解决方案

文章目录

- 行业背景
- 解决方案优势
- 核心产品灾备设计及技术指标
- DBS
- 冷备
- 热备份
- 同城容灾
- 同城容灾——复制加高可用
- 同城容灾——A-S
- 同城容灾——A-A
- 更多信息

行业背景

数据是企业重要的生产资料，关键数据的丢失可能会给企业致命一击，因为数据是计算机系统存在的原因和基础。数据往往是不可再生的，一旦发生数据丢失，企业就会陷入困境：客户资料、技术文件、财务账目等客户、交易、生产数据可能被破坏得面目全非。概括起来，数据丢失分三个层次：

逻辑错误：包括软件bug、病毒攻击、数据块被破坏等。
物理损坏：包括服务器、磁盘损坏等。
自然灾害：火灾、地震等自然灾害对数据中心的摧毁等。

为了应对数据丢失造成的损失，必须对数据进行灾备保护，并且企业信息化程度越高，相关的数据灾备恢复措施就越重要。

说明灾备是指容灾+备份：

备份的定义：指用户为应用系统产生的重要数据（或者原有的重要数据信息）制作一份或者多份拷贝，以增强数据的安全
容灾的定义：指在相隔较远的两地（同城或者异地）建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换。当一处系统因意外（天灾、人祸）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。

一般数据从生产到存储，主要经过应用、中间件、数据库、操作系统、存储或者磁盘驱动、网络、存储交换机等。其中数据库的灾备设计尤为重要。数据库的灾备主要技术流派包括备份、容灾等。

备份：
- 逻辑备份：利用数据库的重做日志、归档日志，将主本所在站点的日志传输到副本所在站点，通过重做SQL的方式实现数据复制。逻辑复制只提供异步复制，主副本数据的最终一致性，无法保证实时一致性。
- 物理备份：通过Redo日志或者归档日志在副本站点的同步或者异步持久化写、Redo Apply来实现复制功能，同时副本站点的数据可以提供只读功能。物理备份又可进一步细分为冷备与热备。
容灾：数据容灾是在备份的基础上，建立一个异地的数据系统，该系统是本地关键应用数据的一个实时复制。根据应对故障场景不同，容灾可分为同城容灾、异地容灾。

说明进行灾备解决方案设计时，需关注灾备的两个关键技术指标：
- RTO：RecoveryTime Object，恢复时间目标。指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为RTO。RTO是反映业务恢复及时性的指标，体现了企业能容忍的IT系统最长恢复时间。RTO值越小，代表容灾系统的恢复能力越强，但企业投资也越高。
- RPO：Recovery Point Object，恢复点目标。指灾难发生后，容灾系统进行数据恢复，恢复得来的数据所对应的时间点称为RPO。RPO是反映数据丢失量的指标，体现了企业能容忍的最大数据丢失量的指标。RPO值越小，代表企业数据丢失越少，企业损失越小。

解决方案优势

阿里云针对企业对数据库灾备的需求，构建阿里云数据库灾备解决方案，为企业用户提供：

多数据中心：阿里云在全球分布有多个数据中心，用户可在就近、合适区域选购、部署阿里云产品。
稳定：每个区域及产品比较稳定，阿里云关键部件（SLB、ECS、RDS等）经多轮迭代具备比较完善的灾备能力，可以实现更细粒度的控制，可以通过更多已经产品化的功能模块实现容灾。
弹性：用户可根据业务需求横向、纵向扩缩容，按需购买使用的服务。

核心产品灾备设计及技术指标

阿里云产品经多轮迭代具备比较完善的灾备能力，使用以下核心产品可帮助企业应对不同场景及需求的数据库灾备方案设计。

DTS：Data Transmission Service，是阿里云提供的一种支持多种数据源之间数据交互的数据流服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。在数据库灾备解决方案中，使用阿里云DTS可实现各数据库间的数据迁移与实时同步，从而为数据库灾备打好最重要的基础。DTS的数据迁移、数据同步详细架构设计及原理请参见产品架构章节。
DBS：Database Backup Service，是为数据库提供连续数据保护、低成本的备份服务。它可以为多种环境的数据提供强有力的保护，包括企业数据中心、其他云厂商。DBS提供数据备份和操作恢复的整体方案，具备实时增量备份、精确到秒级的数据恢复能力。在数据库灾备解决方案中可使用阿里云DBS实现各数据库间的数据备份。DBS的灾备设计及技术指标见 DBS 章节。
HDM：Hybrid Cloud Database Management，是混合云数据库管理平台，帮助企业打通混合云数据库架构，提供多环境统一管理、快速弹性、容灾切换的能力。对于混合云灾备场景下，使用阿里云HDM可便捷、快速的将本地IDC的数据同步至云上，并进行容灾切换演练，故障发生时可通过HDM进行容灾切换，保障数据库的可用性。目前HDM计划2018年4月底在阿里云公共云上正式上线。

在灾备场景下，建议可搭配阿里云其他产品，例如DRDS、OSS，这些产品经阿里内外部验证，均具有较高可靠性并可在灾备场景下灵活应用。

DBS

灾备设计

数据库备份DBS使用了数据传输DTS的增量数据流技术，可以实现实时的数据备份。在线数据发生变化，数据库备份会获得变更的数据，并将数据实时写入云端OSS，帮助用户实现秒级RPO的数据备份。
技术指标
- 秒级RPO
  
  DBS通过使用数据传输DTS的实时数据流技术，可以读取数据库日志并进行实时解析，然后存储到云端存储上，实现对数据库的增量备份。通常，DBS可以将增量备份的延迟控制在秒级别以内，根据实际的网络环境不同，延迟的可能会有不同。在进行数据恢复时，可以使用存储的增量备份实现精确到秒的数据库恢复。最大限度保障数据安全。
- 多环境支持
  
  DBS支持多种网络环境的数据库备份。通过专线接入、VPN网关等接入技术，DBS可以实现用户本地IDC数据库备份、ECS自建数据库的备份、RDS数据库的异地备份、其他云环境的数据库备份。无论哪个环境的数据库，DBS通过自身的安全机制和实时数据库流技术，都可以向用户提供安全、秒级RPO的数据库备份解决方案。

冷备

当用户本地已部署有数据库及存储设备，可通过云上存储做本地数据库的数据备份，当本地数据库发生故障时可通过云上存储将数据恢复到本地。解决方案架构示例如下：[
架构设计说明：

关键部件部署：
- 在用户本地部署有两套数据库：生产数据库和恢复库，分别用于生产数据的存储、故障后数据恢复。
- 在阿里云的两个区域（例如：华南1、华北1）分别购置存储服务，例如OSS对象存储或者NAS文件存储。
云下生产数据备份至云上：（可通过以下两种方案中的任意一种将云下生产数据备份至云上）
- 用户可在本地再部署一套存储，将生产数据先备份至本地IDC的存储，再通过本地IDC存储容灾拷贝至云上存储。
- 用户本地的生产数据库与云上存储之间通过数据备份技术（例如Shutdown & copy技术），将生产数据库中的数据定期备份至云上两个区域的存储中。
数据恢复：
- 如果用户本地IDC的生产数据库发生故障，但本地IDC的存储运行正常，可通过本地IDC的存储将数据恢复至本地IDC的恢复库。
- 如果用户本地IDC的生产数据库和存储均发生故障，或没有部署本地存储，则可通过云上存储将数据恢复至本地恢复库。
架构特点：
- 优点：技术要求中、一致性好。
- 缺点：影响稳定性，需要停机，恢复成本高。
- 适用场景：数据一致性要求高，稳定性需求不强烈。

热备份

当用户对数据备份要求较高时，比如需要连续实时备份，且备份过程中不影响业务运行，此时可购置阿里云DBS服务，实现数据库的热备份，DBS可实现数据实时增量备份、精确到秒级的数据恢复能力。解决方案架构示例如下：[
架构设计说明：

关键部件部署：
- 在用户本地部署有两套数据库：生产数据库和恢复库，分别用于生产数据的存储、故障后数据恢复。
- 在阿里云的两个区域（例如：华南1、华北1）分别购置存储服务，例如OSS对象存储或者NAS文件存储。
- 购置阿里云的DBS服务，用于用户本地数据库实时热备份至云上存储。
云下生产数据备份至云上：（可通过以下两种方案中的任意一种将云下生产数据备份至云上）
- 用户可在本地再部署一套存储，将生产数据先备份至本地IDC的存储，再通过本地IDC存储容灾拷贝至云上存储。
- 用户本地的生产数据库与云上存储之间通过阿里云DBS，将生产数据库中的数据直接热备份至云上两个区域的存储中。
数据恢复：
- 如果用户本地IDC的生产数据库发生故障，但本地IDC的存储运行正常，可通过本地IDC的存储将数据恢复至本地IDC的恢复库。
- 如果用户本地IDC的生产数据库和存储均发生故障，或没有部署本地存储，则可通过DBS将云上存储将数据恢复至本地恢复库。
架构特点：
- 优点：技术要求高、一致性好，恢复时间短。
- 缺点：因为是完全重新构造数据库实例，RTO不可控，随着数据库是来大小而变化。
- 应用场景：比较成熟的备份手段，适用于大部分的关系型数据库。

同城容灾

当用户需要实现同城机房级的数据库灾备方案时，可购置阿里云DTS服务，阿里云DTS可实现数据迁移、数据实时同步等功能。同城容灾时用户可选择复制加高可用、A-S（Active-Standby）模式或A-A（Active-Active）模式：

复制加高可用：同城两机房中均部署数据库，通过复制从主用机房的数据库将数据复制备份至备机房的数据库中。当主用机房的数据库发生故障时，业务切换至备用机房的数据库。
A-S模式：同城两机房中部署完全一致的系统，其中一个机房（Standby）的资源完全用于备份，不对外提供业务。当主用机房（Active）发生故障时，业务切换至备用机房。
A-A模式：同城两机房中部署完全一致的系统，两个机房均对外提供业务，但在两个机房中均预留一部分资源作为备份。当其中一个机房发生故障时，业务会切换到另一个机房，占用另一个机房预留的资源。如果用户资源充足且对同城容灾要求较高时，建议采用A-S模式；如果用户资源紧张，建议采用A-A模式。

同城容灾——复制加高可用

以用户使用阿里云数据库RDS为例，复制加高可用的架构如下：[
架构说明：

关键部件部署：
- 在机房A和机房B机房分别部署RDS数据库集群。
- SLB、ECS、HA均可跨机房对接应用，两个机房部署一套即可，通过HA管控两个机房的数据库。
数据备份与恢复：
- 正常情况下，机房A的数据库通过复制的方式将数据备份至机房B的数据库。
- 机房A数据库故障时，可通过HA将流量直接转移到机房B访问，暂时抛弃机房A的资源，等机房A恢复后重新配置为备选可用区。
架构特点：
- 优点：轻量级切换成本低。
- 缺点：可能存在少量数据不一致的风险，比如丢失一个事务。

同城容灾——A-S

以用户在阿里云的一个Region购置了两套最简IT系统为例，数据库的A-S同城容灾解决方案架构示意如下：架构说明：

关键部件部署：
- 在机房A和机房B机房分别部署对等的DRDS+RDS数据库集群。
- 购置阿里云DTS服务，RDS之间通过DTS进行数据的实时同步和一致性校验，保证两个机房RDS数据的一致性。
数据备份与恢复：
- 正常情况下，保证DTS实时同步的稳定运行，如果出现异常，需要处理保证DTS同步的稳定性和准确性。
- 如果机房A数据库故障或者机房整体故障，流量直接转移到机房B访问，暂时抛弃机房A的资源，等机房A恢复后重新配置为备选可用区。
- 如果只是应用端故障则将流量转移至机房B访问，同时需要对数据段做一致性校验，校验完成后，机房B成为主数据库，机房作为备数据库，数据同步的流向发生变化，由机房B同步到机房 A 。
- 需要配置RDS-DTS-RDS之间的同步链路。
架构特点：
- 优点：性能最好，Zone A 故障时可以自动切换，人为干预程度低。
- 缺点：资源利用率50%。

同城容灾——A-A

以用户在阿里云的一个Region购置了两套最简IT系统为例，数据库的A-A同城容灾解决方案架构示例如下：架构设计说明：

关键部件部署：
- 在阿里云的同一个Region的两个可用区（机房A与机房B）部署两套最简IT系统。其中机房A与机房B均为Active状态。
- 前端接入可部署DNS解析与SLB负载均衡，计算可使用阿里云ECS弹性计算服务。数据库可使用阿里云DRDS、RDS。
- 数据库间使用阿里云DTS服务实现数据迁移、数据的实时增量同步。
同城灾备流程：
- 在机房A正常运行状态下，用户生产数据从机房A的数据库，通过DTS实时同步至机房B的数据库，且通过DTS来校验两个机房数据库中数据的一致性。
- 当机房A发生故障，整个机房无法工作时，前端DNS将流量解析至机房B，用户生产数据存储至机房B的数据库中。
架构特点：
- 优点：资源利用率较方案一高。
- 缺点：应用需要接受使用机房B应用服务带来的跨区访问延迟，机房A故障时切换需要人工修改机房B应用服务上应用配置的数据库连接地址为机房B的DRDS库地址。