云数据库 TiDB 版基于原生分布式架构与 Raft 一致性算法,多节点实时同步数据变更,依托多副本机制实现强数据持久与故障容错,抵御单点故障,各类故障中断场景下均可持续对外提供服务;同时内置丰富云原生能力,全面适配云上运维场景。
高可用是指将节点分布在多个可用区,实现最大程度的基础设施隔离和冗余。它提供最高级别的可用性,但需要应用层实现跨区冗余。
当您创建启用高可用的 Essential 集群时,关键 OLTP(联机事务处理)工作负载组件(如 PD 和 TiKV)会跨多个可用区部署,以确保冗余复制并最大化可用性。在正常运行期间,Gateway、TiDB 和 TiFlash 计算/写节点等组件会部署在主可用区。这些数据面组件通过虚拟机池提供基础设施冗余,从而最大程度减少故障转移时间和因同区部署带来的网络延时。
在高可用架构下:
- Placement Driver(PD)和 TiKV 跨多个可用区部署,数据始终在各区冗余复制,以确保最高级别的可用性。
- 数据在主可用区内的 TiKV 节点之间完成副本复制。
- TiDB Server 计算节点向 TiKV 存储节点写入数据,并可读取 TiKV、TiFlash 存储节点的数据,存储层依靠副本复制机制保障数据安全。
在极少数情况下,主可用区发生故障(如自然灾害、配置变更、软件问题或硬件故障),关键 OLTP 工作负载组件(包括 Gateway 和 TiDB)会自动在备用可用区启动。流量会自动重定向到备用区,以确保快速恢复并保持业务可持续性。
云数据库 TiDB 版通过以下措施,最大程度减少主可用区故障期间的服务中断并保障业务可持续性:
- 在备用可用区自动创建 Gateway 和 TiDB 的新副本。
- 通过弹性负载均衡器检测备用可用区的活跃 Gateway 副本,并将 OLTP 流量从故障主区重定向到备用区。
除了通过 TiKV 复制提供高可用外,TiKV 实例会将每个数据副本部署在不同的可用区。只要有两个可用区正常运行,系统就能保持可用。为实现高持久性,数据会定期备份到对象存储。即使两个可用区同时故障,对象存储中的数据依然可访问和恢复。
应用不会受到非主可用区故障的影响,也不会感知到此类事件。在主可用区故障期间,Gateway 和 TiDB 会在备用可用区启动以处理工作负载。请确保业务应用具备重试逻辑,将新请求转发至备用可用区的正常服务节点。
数据库备份对于业务可持续性和容灾至关重要,有助于防止数据损坏或误删。通过备份,您可以在保留时间内将数据库恢复到指定时间点,最大程度减少数据丢失和停机时间。
云数据库 TiDB 版提供了强大的自动备份机制,确保持续的数据保护:
- 每日全量备份:每天会创建一次数据库的全量备份,捕获整个数据库的状态。
- 持续事务日志备份:事务日志会持续备份,大约每 5 分钟一次,具体频率取决于数据库活动量。
这些自动备份使您可以通过全量备份或结合全量备份与持续事务日志,将数据库恢复到任意指定时间点。这种灵活性确保您可以将数据库恢复到事故发生前的精确时刻。
说明
云数据库 TiDB 版会自动备份(包括基于快照的备份和用于时间点恢复(PITR)的持续备份),可跨多个可用区冗余保存,具备高持久性。
在故障发生时,正在故障 server 上运行的事务可能会被中断。虽然故障转移对应用是透明的,但您必须实现相应的 logic 来处理活跃事务期间可恢复的故障。不同故障场景的处理方式如下:
- TiDB 故障:如果 TiDB node 故障,client 连接不会受到影响,因为云数据库 TiDB 版会自动通过 Gateway 重路由流量。虽然故障 TiDB node 上的事务可能会被中断,但系统会确保已提交的数据被保留,新事务会由其他可用的 TiDB node 处理。
- Gateway 故障:如果 Gateway 故障,client 连接会被中断。但云数据库 TiDB 版的 Gateway 为无状态的,可以立即在新的可用区或 server 上重启。流量会自动重定向到新的 Gateway,最大程度减少停机时间。
建议您在应用中实现重试 logic,以处理可恢复的故障。具体实现方式请参考您的驱动或 ORM 文档(例如 JDBC)。 在制定业务可持续性计划时,请考虑以下两个关键指标:
- 恢复时间目标(RTO):应用在发生中断事件后完全恢复所能容忍的最长时间。
- 恢复点目标(RPO):应用在从非计划中断事件恢复时所能容忍的最近数据更新的最长时间间隔。
依托区域高可用架构,可实现 RTO 通常小于 600 秒、RPO 为 0 的容灾能力。