SQL Server的日誌傳送（log shipping）技術一直比較雞肋，尤其當SQL Server 推出了Always On技術以後，估計使用日誌傳送（log shipping）這種技術方案的企業越來越少，但是日誌傳送也有自己的一些優點，有些特殊場景或業務背景下也有其存在的價值。最近由於特殊業務... ...
SQL Server的日誌傳送（log shipping）技術一直比較雞肋，尤其當SQL Server 推出了Always On技術以後，估計使用日誌傳送（log shipping）這種技術方案的企業越來越少，但是日誌傳送也有自己的一些優點，有些特殊場景或業務背景下也有其存在的價值。最近由於特殊業務場景可能需要用到這個技術，所以做了一些測試和驗證，比對一些知識做了一下總結、歸納。下麵有部分內容從官方文檔摘抄。此篇是總結性內容。如有不足，敬請指點！
日誌傳送（Log Shipping）介紹
SQL Server使用日誌傳送，可以自動將“主伺服器”實例上“主資料庫”上的事務日誌備份發送到“輔助伺服器”實例上的一個或多個“輔助資料庫”。
事務日誌備份分別應用於每個輔助資料庫。 可選第三個伺服器實例（稱為“監視伺服器 ”）記錄備份和還原操作的歷史記錄及狀態，還可以在無法按計劃
執行這些操作時引發警報。
事務日誌傳送提供了資料庫級別的高可用性保護。日誌傳送可用來維護相應生產資料庫（稱為“主資料庫”）的一個或多個備用資料庫（稱為“輔助資料庫”）。發生故障轉移之前，必須通過手動應用全部未還原的日誌備份來完全更新輔助資料庫。日誌傳送具有支持多個備用資料庫的靈活性。如果需要多個備用資料庫，可以單獨使用日誌傳送或將其作為資料庫鏡像的補充。當這些解決方案一起使用時，當前資料庫鏡像配置的主體資料庫同時也是當前日誌傳送配置的主資料庫。
日誌傳送的拓撲結構圖如下所示：
優點：
可以為單個主資料庫配置一個或多個輔助資料庫（每個資料庫都位於單獨的SQL Server實例上），提供災難恢復解決方案。
支持對輔助資料庫的受限的只讀訪問許可權（在還原作業之間的間隔期間）。可做簡單的讀寫分離。
允許用戶將延遲時間定義為：從主伺服器備份主資料庫日誌到輔助伺服器必須還原（應用）日誌備份之間的時間。 例如，如果主資料庫上的數據被意外更改，則較長的延遲會很有用。 如果很快發現意外更改，則通過延遲，您可以在輔助資料庫反映此更改之前從其中檢索仍未更改的數據
缺點：
容易出現異常，導致數據不一致。而且出現異常後基本無法補救，需要重新初始化。
日誌傳送配置不會自動從主伺服器故障轉移到輔助伺服器。 如果主資料庫變為不可用，需要手動將輔助資料庫聯機。
沒有自我糾錯、自我驗證的處理機制。
數據同步有延遲。
相關術語（摘自官方文檔）
主伺服器 (primary server)
位於生產伺服器上的SQL Server實例。
主資料庫 (primary database)
希望備份到其他伺服器的主伺服器上的資料庫。 通過SQL Server Management Studio進行的所有日誌傳送配置管理都是在主資料庫中執行的。
輔助伺服器 (secondary server)
想要在其上保留主資料庫的熱備副本的SQL Server實例。
輔助資料庫 (secondary database)
主資料庫的熱備用副本。 輔助資料庫可以處於 RECOVERING 狀態或 STANDBY 狀態，這將使資料庫可用於受限的只讀訪問。
監視伺服器 (monitor server)
跟蹤日誌傳送的所有詳細信息的SQL Server的可選實例，包括：
主資料庫中事務日誌最近一次備份的時間。
輔助伺服器最近一次複製和還原備份文件的時間。
有關任何備份失敗警報的信息。
備份作業
一種SQL Server代理作業，它執行備份操作，將歷史記錄信息記錄到本地伺服器和監視伺服器上，並刪除舊的備份文件和歷史記錄信息。
啟用日誌傳送後，將在主伺服器實例上創建作業類別“日誌傳送備份”。
