如何在日誌傳送中進行故障轉移？
我正在閱讀 Carter 的《Pro SQL Server 2019 Administration》一書，他在日誌傳送部分中提到：
“與其他高可用性和災難恢復技術不同，大量的管理工作與日誌傳送故障轉移有關。要故障轉移日誌傳送，您必須備份事務日誌的尾部，並複制它以及任何其他未複製的備份文件，到輔助伺服器。”
他之前指出，日誌傳送主要用於 DR 場景……我的問題是，如果 DR 擊中主數據中心，應該如何“向上事務日誌的尾部，並複制它，以及任何其他未複製的備份文件”？！
如果 DR 命中，並且我們已經設置了日誌傳送，我的猜測是我們只剩下輔助副本擁有的任何東西……也就是說，如果我能夠“備份尾部”，那麼伺服器必須啟動並執行…
如果 DR 命中，並且我們已經設置了日誌傳送，我的猜測是我們只剩下輔助副本擁有的任何東西……也就是說，如果我能夠“備份尾部”，那麼伺服器必須啟動並執行…
當日誌恢復到輔助節點時，通過“with norecovery”選項恢復日誌，數據庫將處於“恢復”（或備用為只讀）狀態：
RESTORE LOG [YourDB] FROM DISK = 'R:\YourDBLogBackup.TRN' WITH NORECOVERY如果主要不可用
您始終可以通過執行“恢復”命令使其聯機：
RESTORE DATABASE [YourDB] WITH RECOVERY因此，如果您失去了主節點，則輔助節點 (DR) 將與複製的最新日誌一樣是最新的。但是，當您手動執行此操作時，您將無法恢復到主節點，因此只有在主節點失去時才執行此操作。
編輯：
實際上，我將對此進行擴展。日誌傳送可以與任何其他 DR 方法一樣好，但它取決於您使用的 RTO（恢復時間目標）和 RPO（恢復點目標）方法。
如果您關心每一個事務，您將使用可用性組同步送出，它本質上是先將數據寫入 DR，然後再寫入主節點。
但是，如果您有能力損失幾分鐘甚至 1 小時的數據，那麼日誌傳送可能就足夠了。只要確保你經常備份你的日誌。
日誌傳送的美妙之處在於您甚至可以通過 FTP 來完成。SQL Server 不需要互相看到就可以正常工作。
編輯2：
如果主要可用
只有在主數據中心沒有失去的情況下，才需要進行尾部備份來進行手動故障轉移。您在主數據庫上進行尾部備份，將數據庫置於“恢復”模式：
BACKUP LOG [YourDB] TO 'R:\YourDBLogBackup.TRN' WITH NORECOVERY;然後，您複製最後一個備份文件（因此稱為尾部）並在輔助中恢復，使輔助聯機並重複該操作以故障恢復到主。您可以根據需要來回執行（故障轉移和故障恢復）多次。
我懷疑他在談論手動進行故障轉移。
如您所說，如果您的數據中心被完全佔用，那麼您將無法從舊的主伺服器中取回*任何東西。*是吐司。
這可能就是他領導的原因：
與其他高可用性和災難恢復技術不同…
這些其他技術可以更快地傳送日誌，因此無需擔心“後沿”。