事務複製作為 DR 解決方案
我設置了生產數據庫伺服器和故障轉移數據庫伺服器。來自主生產數據庫伺服器的所有事務都被複製（從備份初始化的事務複製）到故障轉移數據庫伺服器，並且工作正常。
故障轉移伺服器中沒有進行任何活動（沒有報告），它只是從主生產數據庫中獲取所有更改。甚至報告（報告最少）也是從主生產數據庫伺服器完成的。
目標是將其用作故障轉移伺服器，我知道事務複製對於 DR 來說不是一個好主意，還有其他推薦的解決方案。但這是前任 DBA 設置的方式，我聽說在那段時間聽起來還不錯。因此，如果我必須進行故障轉移，我必須通過研究這個主題來手動完成。
使用負載均衡器管理 3 個應用程序伺服器（app1、app2、app3）。一台數據庫伺服器（目前主要生產伺服器）
通過自己的研究，我只是對如何進行故障轉移有一個模糊的想法。我有以下兩個問題：
- 有人可以慷慨地指導我如何對複制的數據庫伺服器進行故障轉移。
- 故障轉移後，如何將新事務/更改管理回主生產數據庫伺服器。
事務複製不是“DR 解決方案”，您可能會面臨很多問題，（並非所有表都被複製，每個數據庫中的數據不同）即使它在過去有效，但不能保證它現在會有效。該建議將使用一些受支持的工具，例如日誌傳送或始終開啟。
即使這樣，如果您決定這樣做，正如@Queue Mann 所說，您需要將所有內容都指向新伺服器，這沒有自動選項，（但始終開啟）對於您的問題：A）有沒有“官方”故障轉移，您只需使用複制的數據庫並將所有應用程序指向數據庫。
B）在故障轉移的情況下，您將需要重新設置所有內容（在 Always on 中，只要它是在同步模式下完成的，您就不會）。
老實說，我不知道為什麼繼續使用複製而不是官方的 DR 解決方案，以正確的方式您將節省大量配置（和麻煩）。
要回答您的問題：
有人可以慷慨地指導我如何對複制的數據庫伺服器進行故障轉移。
複製不存在“故障轉移”，因為它不是 DR 技術。您必須重定向您的應用程序以指向您的副本伺服器以“故障轉移”。您也可以使用 CNAME。將您的伺服器指向 DNS 中指向您的主伺服器的 CNAME，然後為了進行故障轉移，您將 CNAME 更改為指向您的副本伺服器。
您需要為 CNAME 設置較低的 TTL，以便客戶端電腦盡快選擇此更改。此外，您需要停止和禁用複制代理作業，以防止在另一端執行時出現數據錯誤。
故障轉移後，如何將新事務/更改管理回主生產數據庫伺服器。
你不能。SQL 事務複製中沒有“逆轉”，因此您必須中斷、備份數據庫、恢復主數據庫並將您的應用程序重定向回主數據庫。
現在澄清一些事情：
我提供的這些建議都不好。複製不是 DR 技術，它不是為 DR 設計的，也不適合 DR，您需要放棄它作為解決方案。如果您擔心複雜性，複製比簡單的 DR 選項（如日誌傳送）更複雜。如果您擔心成本，更高版本的 SQL Server 在標準版中提供基本可用性組，在 2016 年之前，您在標準版中擁有數據庫鏡像 - 當然，在所有版本中使用代理進行日誌傳送。
查看有關日誌傳送的這篇文件文章。它是您最好的低成本、低複雜性解決方案，並為您提供 Replication 所沒有的東西，例如事務一致性。
相對於複製的優勢：
- 事務一致。
- 自動包含整個數據庫、所有表、視圖、過程等。
- 成本低，易於實施。
- 提供標準版
查看有關Always On 可用性組的這篇文件文章，它是 SQL Server 的更好的 HADR 解決方案之一，以及有關基本 AG的一些附加資訊。
相對於複製的優勢：
- 事務一致
- 自動包含整個數據庫、所有表、視圖、過程等。
- 通過使用偵聽器自動重定向客戶端。
- 根據 version\edition\licensing，可以實現多個副本來實現 HADR 解決方案。
- 標準版中提供的基本 AG。
- 故障轉移後自動反轉數據
- 執行數據移動不需要代理作業
最後，如果您正在執行不支持 AG 或基本 AG 的版本或版本，請查看有關數據庫鏡像的這篇文件文章。
相對於複製的優勢：
- 事務一致
- 自動包含整個數據庫、所有表、視圖、過程等。
- 提供標準版
- 故障轉移後自動反轉數據
- 執行數據移動不需要代理作業