設計一個高可用的資料庫系統，首先需要明確的就是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

構造如下表格進行統計即可