設計一個高可用的數據庫系統，首先需要明確的就是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
構造如下表格進行統計即可
