注意：说明：
注意：TDSQL-C MySQL 版的备可用区为容灾使用，不对外提供访问。
一、前提条件
·集群所在的地域需要包含两个及以上的可用区。
·目标可用区拥有足够计算资源。
·数据库版本要求：
·数据库版本5.7需满足内核小版本不低于2.0.15。
·数据库版本8.0需满足内核小版本不低于3.0.1。
二、支持的地域和可用区
·目前此功能为公测期间，暂时仅支持如下表所示的地域和可用区。
·此功能会逐渐扩充支持地域和可用区。
·如因业务需要，你可 提交工单 反馈其他地域和可用区的部署需求。
| 支持地域 | 支持主可用区 | 支持备可用区 |
| 北京 | 北京三区 | 北京五区 |
| | 北京五区 | 北京七区 |
| | 北京六区 | 北京七区 |
| | | 北京八区 |
| | 北京七区 | 北京五区 |
| 广州 | 广州三区 | 广州四区 |
| | 广州四区 | 广州六区 |
| | 广州六区 | 广州四区 |
| | | 广州七区 |
| | 广州七区 | 广州四区 |
| 上海 | 上海二区 | 上海四区 |
| | 上海四区 | 上海二区 |
| | 上海五区 | 上海四区 |
| 中国香港 | 香港一区 | 香港三区 |
| | 香港二区 | 香港三区 |
| 新加坡 | 新加坡二区 | 新加坡四区 |
| | 新加坡三区 | 新加坡四区 |
| | 新加坡四区 | 新加坡三区 |
| 硅谷 | 硅谷二区 | 硅谷一区 |
| 法兰克福 | 法兰克福一区 | 法兰克福二区 |
| | 法兰克福二区 | 法兰克福一区 |
| 弗吉尼亚 | 弗吉尼亚一区 | 弗吉尼亚二区 |
| | 弗吉尼亚二区 | 弗吉尼亚一区 |
| 东京 | 东京一区 | 东京二区 |
| | 东京二区 | 东京一区 |
| 雅加达 | 雅加达二区 | 雅加达一区 |
| 新山 | 新山一区 | 新山二区 |
| | | 新山三区 |
| | 新山二区 | 新山一区 |
| | | 新山三区 |
| | 新山三区 | 新山一区 |
| | | 新山二区 |
三、如何实现多可用区架构
关于多可用区架构，可通过控制台新建集群实现，存量的单可用区集群也会升级至多可用区集群，该升级通过在线迁移数据的方式自动完成，对你的业务无任何影响。详情请参见 设置多可用区部署。
四、多可用区部署费用说明
详情请参见 计费说明。
五、多可用区信息展示
在集群列表页面，根据实际使用的视图模式进行展示：
页签视图列表视图1. 在 集群列表 页左侧单击集群，进入集群管理页。2. 在集群管理页部署方式处，以及集群详情的拓扑图里可以分别看到该集群的部署方式以及主备可用区。1. 集群列表 页展示集群可用区信息（展示主可用区）。2. 在集群详情页的基本信息和可用性信息处可查看集群部署分布的可用区。
六、一、异步复制
应用发起数据更新（含 insert、update、delete 操作）请求，主节点在执行完更新操作后立即向应用程序返回响应，然后主节点再向备节点复制数据。数据更新过程中主节点不需要等待备节点的响应，因此异步复制的数据库实例通常具有较高的性能，且备节点不可用并不影响主节点对外提供服务。但因数据并非实时同步到备节点，而主节点在备节点有延迟的情况下发生故障则有较小概率会引起数据不一致。
七、二、半同步复制
应用发起数据更新（含 insert、update、delete 操作）请求，主节点在执行完更新操作后立即向备节点复制数据，备节点接收到数据并写到 relay log 中（无需执行）后才向主节点返回成功信息，主节点必须在接收到备节点的成功信息后再向应用程序返回响应。
仅在数据复制发生异常（备节点不可用或者数据复制所用网络发生异常）的情况下，主节点会暂停（默认10秒左右）对应用的响应，将复制方式降为异步复制。当数据复制恢复正常，将恢复为半同步复制。
八、三、强同步复制
应用发起数据更新（含 insert、update、delete 操作）请求，主节点在执行完更新操作后立即向备节点复制数据，备节点接收到数据并写到 relay log 中（执行完成）后才向主节点返回成功信息，主节点必须在接收到备节点的成功信息后再向应用程序返回响应。
在数据复制发生异常（备节点不可用或者数据复制所用网络发生异常）的情况下，复制方式均不会发生降级，为保障数据一致性，此时主节点会暂停对应用的响应，直至异常结束。