当用户需要实现同城机房级的数据库灾备方案时,可购置阿里云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库地址。