高可用服务

高可用服务由 Detection、Repair、Notice 等模块组成，主要保障数据链路服务的可用性，除此之外还负责处理数据库内部的异常。
另外，RDS 还通过迁移到支持多可用区的地域和采用适当的高可用策略，提升 RDS 的高可用服务。

Detection


Detection 模块负责检测 DB Engine 的主节点和备节点是否提供了正常的服务。通过间隔为 8~10 秒的心跳信息，HA 节点可以轻易获得主节点的健康情况，结合备节点的健康情况和其它 HA 节点的心跳信息，Detection 模块可以排除网络抖动等异常引入的误判风险，在 30 秒内完成异常切换操作。

Repair


Repair 模块负责维护 DB Engine 的主节点和备节点之间的复制关系，还会修复主节点或者备节点在日常运行中出现的错误。
例如：

• 主备复制异常断开的自动修复
• 主备节点表级别损坏的自动修复
• 主备节点 Crash 的现场保存和自动修复

Notice


Notice 模块负责将主备节点的状态变动通知到 负载均衡 或者 Proxy，保证用户访问正确的节点。
例如：Detection 模块发现主节点异常，并通知 Repair 模块进行修复。Repair 模块进行了尝试后无法修复主节点，通知 Notice 进行流量切换。Notice 模块将切换请求转发至 负载均衡 或者Proxy，此时用户流量全部指向备节点。与此同时，Repair 在别的物理服务器上重建了新的备节点，并将变动同步给 Detection 模块。Detection 模块开始重新检测实例的健康状态。

多可用区


多可用区是在单可用区的级别上，将同一地域的多个单可用区组合成的物理区域。相对于单可用区 RDS 实例，多可用区 RDS 实例可以承受更高级别的灾难。
例如，单可用区 RDS 实例可以承受服务器和机架级别的故障，而多可用区 RDS 实例可以承受机房级别的故障。
目前多可用区 RDS 不额外收取任何费用，在已开通多可用区地域的用户可以直接购买多可用区 RDS 实例，也可以通过跨可用区迁移将单可用区 RDS 实例转化成多可用区 RDS 实例。
[backcolor=transparent]注意： 因为多可用区之间存在一定的网络延迟，因此多可用区 RDS 实例在采用半同步数据复制方案的时候，对于单个更新的响应时间会比单可用区实例长。这种情况最好通过提高并发量的方式来实现整体吞吐量的提高。

高可用策略


高可用策略是根据用户自身业务的特点，采用服务优先级和数据复制方式之间的不同组合，以组合出适合自身业务特点的高可用策略。
服务优先级有以下两个级别：

• RTO（Recovery Time Objective）优先：数据库应该尽快恢复服务，即可用时间最长。对于数据库在线时间要求比较高的用户应该使用 RTO 优先策略。
• RPO（Recovery Point Objective）优先：数据库应该尽可能保障数据的可靠性，即数据丢失量最少。对于数据一致性要求比较高的用户应该使用 RPO 优先策略。

数据复制方式有以下三种方式：

• 异步复制（Async）：应用发起更新（含增加、删除、修改操作）请求，Master 完成相应操作后立即响应应用，Master 向 Slave 异步复制数据。因此异步复制方式下，Slave 不可用不影响主库上的操作，而 Master 不可用有较小概率会引起数据不一致。
• 强同步复制（Sync）：应用发起更新（含增加、删除、修改操作）请求，Master 完成操作后向 Slave 复制数据，Slave 接收到数据后向 Master 返回成功信息，Master 接到 Slave 的反馈后再响应应用。Master 向 Slave 复制数据是同步进行的，因此 Slave 不可用会影响 Master 上的操作，而 Master 不可用不会引起数据不一致。
• 半同步复制（Semi-Sync）：正常情况下数据复制方式采用强同步复制方式，当 Master 向 Slave 复制数据出现异常的时候（Slave 不可用或者双节点间的网络异常），Master 会暂停对应用的响应，直到复制方式超时退化成异步复制。如果允许应用在此时更新数据，则 Master 不可用会引起数据不一致。当双节点间的数据复制恢复正常（Slave 恢复或者网络恢复），异步复制会恢复成强同步复制。恢复成强同步复制的时间取决于半同步复制的实现方式，阿里云数据库 MySQL 5.5 版和 MySQL 5.6 版有所不同。

用户可以根据自身业务特点，选择服务优先级和数据复制方式的不同组合方式，提高可用性。

云数据引擎	服务优先级	数据复制方式	组合特点
MySQL 5.1	RPO	Async	在 Master 发生故障的情况下，切换会发生在 Slave 应用完所有的 Relay Log 之后。在 Slave 发生故障的情况下，应用操作 Master 不受影响。在 Slave 恢复之后再同步 Master 上面的数据。
MySQL 5.5	RPO	Async	在 Master 发生故障的情况下，切换会发生在 Slave 应用完所有的 Relay Log 之后。在 Slave 发生故障的情况下，应用操作 Master 不受影响。在 Slave 恢复之后再同步 Master 上面的数据。
MySQL 5.5	RTO	Semi-Sync	在 Master 发生故障且数据复制未退化的情况下，因为数据一致性已经得到保障，RDS 将立即触发切换操作把流量导向 Slave。在 Slave 发生故障的情况下，应用操作 Master 将会出现超时，而后数据复制方式退化为异步复制方式；在 Slave 恢复并同步完 Master 上的数据之后，数据复制方式恢复为强同步。在双节点数据不一致且数据复制方式已经退化为异步复制方式的情况下，如果 Master 发生了故障，则切换会发生在 Slave 应用完所有的 Relay Log 之后。
MySQL 5.6	RPO	ASync	在 Master 发生故障的情况下，切换会发生在 Slave 应用完所有的 Relay Log 之后。在 Slave 发生故障的情况下，应用操作 Master 不受影响。在 Slave 恢复之后再同步 Master 上面的数据。
MySQL 5.6	RTO	Semi-Sync	在 Master 发生故障且数据复制未退化的情况下，因为数据一致性已经得到保障，RDS 将立即触发切换操作把流量导向 Slave。在 Slave 发生故障的情况下，应用操作 Master 将会出现超时，而后数据复制方式退化为异步复制方式；在 Slave 恢复并同步完 Master 上的数据之后，数据复制方式恢复为强同步。在双节点数据不一致且数据复制方式已经退化为异步复制方式的情况下，如果 Master 发生了故障，则切换会发生在 Slave 应用完所有的 Relay Log之后。
MySQL 5.6	RPO	Semi-Sync	在 Master 发生故障且数据复制未退化的情况下，因为数据一致性已经得到保障，RDS 将立即触发切换操作把流量导向 Slave。在 Slave 发生故障的情况下，应用操作 Master 将会出现超时，而后数据复制方式退化为异步复制方式；在 Slave 重新获取到 Master 信息时（Slave 恢复或者网络故障恢复），数据复制方式恢复为强同步方式。在双节点数据不一致且 Slave 上的数据差异无法补全的情况下，如果 Master 发生了故障，则用户可以通过 API 获取 Slave 的时间点并决定何时切换以及补全数据的方法。
MySQL 5.7	X	X	目前不支持调整
SQL Server 2008 R2	X	X	目前不支持调整
SQL Server 2012	X	X	目前不支持调整
PostgreSQL	X	X	目前不支持调整

[tr=rgb(239, 251, 255)][td]PPAS XX目前不支持调整