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