資訊系統的高可用性 - 以資料庫為例

 

提高可用性的解決方法

知道造成生病的原因，接著就要針對這些問題去思考如何去解決。以下建議幾種思考模式以幫助DBA去選擇一些解決方法。

  因硬體問題產生資料庫異常

可依「硬體問題造成可用性障礙」及「使用者的需求」兩方面來看。

 

  硬體問題造成可用性障礙

● 安裝備援主機以預防正式主機發生硬體異常。

使用者的需求

●「可用性」要求較高：當時跟使用者簽定的S.L.A要求較高。例如：資料庫停止服務時間幾分鐘或者一分鐘內。

考慮選擇「熱待命（HOT STANDBY）」的備援等級，其備援特色如下： 

■備援伺服器擁有主要伺服器的資料

■提供與主要伺服器交易一致的資料。

■自動偵測主要伺服器的狀況與自動轉移服務。

Oracle : Dataguard / RAC

SQLServer : alwayson

PostgreSQL : streaming replication / repmgr

●「可用性」要求較低：當時跟使用者簽定的S.L.A要求不高。例如：資料庫停止服務時間為幾小時(注2) 。

考慮選擇「暖待命（WARM STANDBY）」或者「冷待命（COLD STANDBY）」的備援等級，各備援特色如下：

 

暖待命

■提供與主要伺服器交易一致的資料。

■自動偵測主要伺服器的狀況與自動轉移服務。

■可能需要手動偵測主要伺服器狀態與手動轉移服務。

Oracle : Dataguard

SQLServer : log shipping / replication

PostgreSQL : log shipping

冷待命

■還原資料的備份。

■有正確的作業系統和相關軟體等的備份。

■考慮是否接受恢復正常服務時的延遲狀態。

Oracle : cold backup / backup & restore 

SQLServer : backup & restore

PostgreSQL : backup & restore

注2：資料庫系統停止服務時間之長短，需要與相關使用者討論並抵定（甚至簽訂S.L.A），並且根據資料庫的大小狀態來判斷所選擇的方案是否符合需求。例如：資料庫大小各為200G與10M，其恢復的解決方式就相異，如果是200G，S.L.A簽定十五分鐘，則就不能使用「冷待命」（COLD STANDBY），就需考慮「熱待命」（HOT STANDY）或「暖待命」（WARM STANDY）；反之10M資料庫大小，S.L.A條件一樣，或者可選擇「冷待命」（COLD STANDBY）來做備援的方案，這些狀況都是要被考慮的。

參考：

資訊系統的可用性－以資料庫為例