高可用的恢复点目标(RPO)和恢复时间目标(RTO)
设计一个高可用的数据库系统,首先需要明确的就是RPO和RTO
关于RPO
RPO是业务连续性中的一个常用术语,称为恢复点目标。
在数据库系统中,它描述的是数据库在一次故障停机恢复后可能丢失的数据量。
在数据库系统架构设计中,这是需要优先考虑的,假定数据库每天会做1次全量数据备份,那么在最坏情况下,用户可能会丢失24小时数据。对于某些应用来讲,这是可以接受的。当然,较多应用是不能接受数据丢失的风险的,比如金融业务,数据丢失带来的损失可能会相当的大,所以,RPO为0是才我们的目标。
用户对于RPO的要求决定了数据库架构的技术选型,包括集群节点数量、数据同步方案以及备份技术等等。
关于RTO
与RPO一样,RTO是指一个通用的业务连续性术语,称为恢复
时间目标。
如果系统一直能不间断提供服务,我们可以说系统的可用性是100%;
如果系统在时间单位内有1%的时间不能提供服务,我们可以说系统的可用性是99%。
如何量化RTO
业内通常使用MTTF和MTTR来量化一个模块的可用性。
-
平均无故障时间(MTTF)
MTTF(mean time to failure),指模块处在正常服务状态的平均时间。
-
平均修复时间(MTTR)
MTTR(mean time to repair),指模块处在服务中断状态的平均时间。
系统可用性的定义是MTTF/(MTTF + MTTR),一个大于等于0,小于等于1的数值。且该数值越大,系统可用性越高。业界最常用的方法是用9的个数来描述系统可用性,比如3个9的可用性,指系统在99.9%的时间里可用,而5个9的可用性意味着系统在99.999%的时间里都是可用的。下表展示了基于9的个数描述系统可用性而计算得出的,不同可用性的情况下,服务的不可用时间。
集群设计之初如何量化RTO,
平均修复时间通常包括以下场景:
-
小型升级--Minor Upgrade
-
重大升级--Major Upgrade
-
重新启动--Reboot
-
切换--Switchover
-
故障转移--Failover
-
操作系统升级--OS Upgrade
构造如下表格进行统计即可
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· 2 本地部署DeepSeek模型构建本地知识库+联网搜索详细步骤