TDSQL-C MySQL 版集群实例形态为预置资源或者 Serverless，均支持多可用区部署，相比单可用区部署，多可用区部署的方式具备更高的容灾能力，可以保护数据库，以防数据库实例发生故障或可用区中断，可以抵御机房级别的故障。多可用区部署为数据库实例提供高可用性和故障转移支持。多可用区是在单可用区的级别上，将同一地域的多个单可用区组合成的物理区域。本文为您介绍实例形态为预置资源的集群的多可用区部署，如需了解实例形态为 Serverless 的多可用区部署，请参见 多可用区部署。
说明：
TDSQL-C MySQL 版的备可用区为容灾使用，不对外提供访问。
前提条件
集群所在的地域需要包含两个及以上的可用区。
目标可用区拥有足够计算资源。
数据库版本要求：
数据库版本5.7需满足内核小版本不低于2.0.15。
数据库版本8.0需满足内核小版本不低于3.0.1。
多可用区部署架构
支持的地域和可用区
目前此功能为公测期间，暂时仅支持如下表所示的地域和可用区。
此功能会逐渐扩充支持地域和可用区。
如因业务需要，您可 提交工单 反馈其他地域和可用区的部署需求。
支持地域 | 支持主可用区 | 支持备可用区 |
北京 | 北京三区 | 北京五区 |
| 北京五区 | 北京七区 |
| 北京六区 | 北京七区 |
| | 北京八区 |
| 北京七区 | 北京五区 |
广州 | 广州三区 | 广州四区 |
| 广州四区 | 广州六区 |
| 广州六区 | 广州四区 |
| | 广州七区 |
| 广州七区 | 广州四区 |
上海 | 上海二区 | 上海四区 |
| 上海四区 | 上海二区 |
| 上海五区 | 上海四区 |
中国香港 | 香港一区 | 香港二区 |
| 香港二区 | 香港三区 |
新加坡 | 新加坡二区 | 新加坡四区 |
| 新加坡三区 | 新加坡四区 |
| 新加坡四区 | 新加坡三区 |
硅谷 | 硅谷二区 | 硅谷一区 |
法兰克福 | 法兰克福一区 | 法兰克福二区 |
| 法兰克福二区 | 法兰克福一区 |
弗吉尼亚 | 弗吉尼亚一区 | 弗吉尼亚二区 |
| 弗吉尼亚二区 | 弗吉尼亚一区 |
东京 | 东京一区 | 东京二区 |
| 东京二区 | 东京一区 |
雅加达 | 雅加达二区 | 雅加达一区 |
如何实现多可用区架构
多可用区部署费用说明
多可用区部署功能暂时不需要支付额外费用。
说明：
当前单可用区集群也可免费升级为至多可用区集群。
多可用区信息展示
在集群列表页面，根据实际使用的视图模式进行展示：
TDSQL-C MySQL 版支持的数据复制方式
一、异步复制
应用发起数据更新（含 insert、update、delete 操作）请求，Master 在执行完更新操作后立即向应用程序返回响应，然后 Master 再向 Slave 复制数据。数据更新过程中 Master 不需要等待 Slave 的响应，因此异步复制的数据库实例通常具有较高的性能，且 Slave 不可用并不影响 Master 对外提供服务。但因数据并非实时同步到 Slave，而 Master 在 Slave 有延迟的情况下发生故障则有较小概率会引起数据不一致。
二、半同步复制
应用发起数据更新（含 insert、update、delete 操作）请求，Master 在执行完更新操作后立即向 Slave 复制数据，Slave 接收到数据并写到 relay log 中（无需执行）后才向 Master 返回成功信息，Master 必须在接受到 Slave 的成功信息后再向应用程序返回响应。
仅在数据复制发生异常（Slave 节点不可用或者数据复制所用网络发生异常）的情况下，Master 会暂停（默认10秒左右）对应用的响应，将复制方式降为异步复制。当数据复制恢复正常，将恢复为半同步复制。
三、强同步复制
应用发起数据更新（含 insert、update、delete 操作）请求，Master 在执行完更新操作后立即向 Slave 复制数据，Slave 接收到数据并写到 relay log 中（执行完成）后才向 Master 返回成功信息，Master 必须在接受到 Slave 的成功信息后再向应用程序返回响应。
在数据复制发生异常（Slave 节点不可用或者数据复制所用网络发生异常）的情况下，复制方式均不会发生降级，为保障数据一致性，此时 Master 会暂停对应用的响应，直至异常结束。
