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