異地複制的 SQL Server 複製
我們內部有我們的主 SQL 伺服器（目前有 15 台主伺服器（總共大約 500 個數據庫），大多數伺服器都有六核處理器）。
這些鏡像到附近建築物中的其他備份伺服器（通過專用的 0ms 光纖鏈路）。
我們想做的是在數英里外的異地數據中心維護我們數據的實時副本（作為更大的災難恢復項目的一部分——即，如果我們所在地區存在通信問題）。
目前我們使用 SQL Server 2008 R2 - 標準版。
顯然，使用 SQL Server 2008 R2 的“標準版”將我們限制為同步鏡像，因為非同步是“企業版”功能。
我們已經完成了異地同步鏡像的測試，但延遲只是讓它無法進行。
我很想升級到 SQL Server 2012 Enterprise 並實施 AlwaysOn 可用性組，但該公司不願意花費 100,000 英鎊以上來升級 SQL 許可（2012 年的每核許可 + 我們的六核處理器 = 史詩般的失敗） -他們甚至不願意花錢升級到 2008 企業版，所以非同步鏡像也在窗外。
因此，由於這些財務限制，我只能堅持使用 2008 R2 標準版。
對我開放的唯一選項是日誌傳送和複製（如果我遺漏了任何內容，請糾正我） - 日誌傳送很粗糙 - 但是如果管理得當是可行的 - 所以我們現在把它放在次要位置。
我的問題：
- SQL Server 2008 R2 Standard 是否具有我們進行異地複制所需的所有複製功能？
- 在不以任何方式影響主伺服器性能的情況下，將內部伺服器複製到異地數據中心（20-30 毫秒延遲）是否可行（我們是否可以在“原理”伺服器上設置複製分發器）？
- 鑑於複製不是實例級別的複制解決方案 - 對此的管理是否超過 1 個 DBA 可以處理？（鑑於我已經在管理 15 台 Principle 伺服器及其 Mirror 對應伺服器 - 誠然有很多自動化）
- 在不影響現有鏡像配置的情況下，是否可以從我們的主伺服器進行複制——據我了解，最佳實踐是鏡像訂閱伺服器而不是發布伺服器——這是否正確？
- 還有什麼複製處女忘記了你需要提請我注意的嗎？
根據您所描述的，日誌傳送將是可行的方法。原木運輸是老派，久經考驗。
複製非常脆弱，為失敗提供了大量空間，尤其是在添加新表並將這些表放入複製拓撲時。
至於 2012 年的升級成本，它們可能沒有您想像的那麼糟糕。如果您有軟體保障和企業協議，可以為您節省一大筆許可費用。
日誌傳送可能是“粗魯的”（我更喜歡直截了當），但複製很複雜，而且根據我的經驗，它很脆弱。如果可以避免，您不想增加複雜性。您不想通過某種英雄事蹟來修復損壞的複制設置。
管理所有這些數據庫的複製配置將是一個問題。您不能使用會更改數據庫表的複制形式，因為我懷疑在 500 個數據庫上測試這些更改本身就是一個非常大的項目，如果不是職業的話。您可能會開始在訂閱者方面遇到性能問題，這需要您開始查看填充因子、維護計劃和其他類似的複雜情況。如果您需要從主伺服器切換到“本地”輔助伺服器，會發生什麼情況？你要重新做所有的複製配置嗎？這可能是一項艱鉅的任務。如果您將其自動化，那就是創建和測試自動化所花費的時間，然後在您更改這 500 個數據庫時需要查看它。
回想一下，直到 SQL Server 2005 為止，我們為 DR 所擁有的只是日誌傳送。它並不吸引人，但它確實有效。
TL;DR- 越簡單越好。使用日誌傳送。