设计一个高可用的数据库系统，首先需要明确的就是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
构造如下表格进行统计即可
标签：MTTF,--,恢复,RTO,可用性,系统,RPO 来源： https://www.cnblogs.com/mingfan/p/15465402.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。