Sql-Server
推薦的鏡像替代方案？
設置
- 2 個位於不同可用區域的 Amazon EC2 SQL 2014 伺服器。
- 同步鏡像
- S3 用於在夜間歸檔完整備份和日誌
- 現在為簡單起見，每晚進行完整壓縮備份
- Tran Logs 每 15 分鐘（如果可以減少執行時間會做更多）
- 在主體伺服器和鏡像伺服器上執行的 Ola Hallengren 備份
生菜
我要滿足的 SLA 條款在這一點上沒有嚴格的限制，所以（奇怪的是我知道！）：
- “Opps Deleted Something”恢復將是一個不錯的選擇，但我現在對此沒有硬性傳遞要求。我現在每 15 分鐘進行一次日誌備份。
- 高可用性：不完全需要，如果需要，一個小時的停機時間是可以接受的
- 時間點恢復：由於事務日誌每 15 分鐘備份一次，我能夠提供，但現在 2 小時是可以接受的。
網路瓶頸
看起來最大的瓶頸之一是大約 300mb 的網路管道，它似乎因需要同步鏡像到另一個 EC2 實例而超載。我可以在同一個實例上維護更多的數據庫，如果我刪除鏡像，可能會降低成本。
鏡像或替代方法 具有合理可用性的性能
我正在尋找最佳價值，同時仍能提供合理的正常執行時間。由於我使用的是 SQL 標準，這意味著非同步鏡像不是一個選項（我們正在執行 sql 2014）。
當我評估選項時，我會欣賞有關基本災難恢復的另一種觀點。鏡像的成本似乎是一個很大的瓶頸，但如果我刪除它，那麼我會擔心如何提供更好的可用性。理想情況下，我會非同步執行鏡像，但我們需要在 sql server 版本中向後移動，並且不確定這是否是最好的方法
始終在高可用性組上
由於此時復雜性和許可成本增加，因此不繼續此操作。對未來的探索持開放態度，但目前希望避免企業許可成本。
如果您正在尋找的只是可用性，那麼聽起來您可能會從故障轉移群集中受益。您可以在標準版上執行它們，如果您採用 N+1 路由，則可以有兩個節點用於 HA，並在 DR 站點中準備一個接管。您需要處理 DR 端的儲存可用性，但這是另一回事。
另一個選項可能是日誌傳送，因為您已經每分鐘都在進行日誌備份。您可以將日誌發送到您的 HA/DR 伺服器。
您可以在此處獲取有關如何執行此操作以及對 AWS 的影響的更多資訊：
在 AWS 雲中實施 Microsoft Windows Server 故障轉移集群和 SQL Server AlwaysOn 可用性組