將數據庫遷移到新數據中心
我的公司正在將我們的基礎架構遷移到新的數據中心，我正在嘗試找出使新伺服器上的數據庫與目前生產數據庫保持同步的最佳方法，直到新環境準備好上線。作為一名全職 DBA，我做了一些研究，從我所閱讀的內容來看，跨國複製設置似乎最適合我們的需求。
一些細節：生產數據庫的大小約為 90 GB，使用 Robocopy 大約需要 9 個小時才能將其副本移動到其中一台新伺服器上。目前的生產數據庫需要在整個遷移過程中保持線上並可訪問。它處於簡單恢復中，因此數據庫鏡像不可用。
事務複製是保持數據庫同步的最佳方法嗎？
我的計劃：
- (Done) 將目前數據庫和日誌傳輸到新伺服器並附加到新的 SQL Server 實例
- 在我們的開發數據庫機器上設置一個分發器並從生產數據庫發佈到它
- 在新的數據庫機器上創建一個訂閱者，它將接受從分發伺服器推出的更新，每晚一次
我心裡有兩件事。事務複製要求每個發布的表都有一個主鍵，而生產數據庫中的很多表都沒有定義主鍵。我不認為這將是一個太大的問題，因為我主要關心的是讓數據庫同步。我們將在稍後的數據中測試使用數據庫的不同應用程序，但我想確保這不是一個嚴重的問題。其次，我是否還需要從原始實例中移動任何關聯的系統數據庫，例如主實例？我們正在新環境中遷移到 Active Directory 設置，所以我不關心使用者等，但我不確定係統 DB 的必要性。
總的來說，我是否正確掌握了這些概念？
你現在的情況：
- 要移動到新數據中心的 90 GB 數據庫。
- 數據庫處於簡單恢復中。
- 您正在考慮使用 T-Rep 來保持數據同步。
- 數據庫中有許多表沒有主鍵 - 這是發布任何表的要求。
- 您已經將備份複製到目標數據中心。
我看到你的方法有很多缺點：
- 與其他技術相比，T-Rep 不容易設置。如果有任何架構更改，則需要一個新的快照。
- 如果您要使用 T-REP，那麼您必須更改架構 - 將主鍵添加到沒有的表中。
- 對現有數據庫進行任何更改時，必須對應用程序進行全面測試以避免任何意外行為。
- 如果您的數據庫有大量事務並且取決於 2 個數據中心之間的網路頻寬，那麼也會存在複製延遲。
根據我的經驗，以下是我的建議：
- 將您的數據庫更改為完全恢復。與創建 PK 相比，這不是主要影響。
- 發送源數據庫的完整備份 - 進行壓縮備份並啟用即時文件初始化。這將幫助您減少目標數據中心的恢復時間。
- 還原目標伺服器上的數據庫
WITH NORECOVERY。- 實施Logshipping並從備份中對其進行初始化。
- 讓 logshipping 每 1 分鐘發送一次日誌。
- 在故障轉移當天，在源上進行最後一個尾日誌備份，並在目標上使用
WITH RECOVERY. 這將使目標數據庫聯機。- 目標數據庫線上後，您必須同步 users。
- 您應該更改 web.config 以將其指向新伺服器。
您不必移動任何系統數據庫。確保您事先完成所有準備工作 - 編寫登錄、作業、ssis 包等腳本並在目標伺服器上創建它們。
有關恢復後步驟和其他最佳實踐的資訊，請參閱此答案。
注意：您也可以實現數據庫鏡像（SYNC 或 ASYNC，具體取決於您使用的 sql server 的版本），但是 logshipping 實現起來很簡單，如果您對其進行測試，它不會讓您失望。我已經使用上述技術成功地將 TB 級數據庫從一個數據中心移動到另一個數據中心，並且執行良好。
目前的生產數據庫需要在整個遷移過程中保持線上並可訪問。
總會有停機時間，你必須安排它。即使您在集群等解決方案上投入了大量資金，當您進行故障轉移時，也會有一些停機時間。您必須權衡您的公司可以投資多少以實現接近零的停機時間與可接受的停機時間。
我自己沒有機會使用它，我認為它仍處於預覽階段，但 Azure 平台上的 SQL 數據同步可能是一個潛在的選擇：
https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/
它適用於本地數據庫和 Azure SQL 數據庫，並且似乎是保持數據庫同步的有用工具。