首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 數據庫知識 >  >> SQL Server 資料庫 >> 關於SqlServer

SQL Server 日志傳送(Log Shipping)入門指南:低成本高可用方案

     編輯:關於SqlServer

SQL Server 日志傳送是一種將主數據庫的事務日志備份自動複製並應用到一台或多台備份服務器的技術,實現「近乎實時」的熱備份。相比昂貴的故障轉移叢集,日志傳送無特殊硬件要求,成本極低,且支持異地容災、報表卸載等場景,是中小企業高可用架構的首選方案。

為什麼選擇日志傳送?

  • 成本低:無需共享存儲、心跳網絡等叢集硬件,普通標準版即可部署。
  • 異地容災:備份服務器可部署在不同數據中心,叢集通常限於同一機房。
  • 報表卸載:備份庫可設為 STANDBY 唯讀模式,供報表查詢分流主庫壓力(注意:日志應用期間查詢會被阻塞)。
  • 部署簡單:SSMS 內建向導,幾分鐘完成配置。
  • 版本廣泛:SQL Server 2000/2005/2008/2012/2014/2016/2017/2019 全支持。

核心架構三角色

  1. 主服務器:執行日志備份作業,產生 .trn 文件。
  2. 備份服務器:執行複製、還原作業,保持恢復中狀態(NORECOVERY 或 STANDBY)。
  3. 監視服務器(可選):記錄作業歷史、閾值告警,可部署在任意實例上。

關鍵配置參數

參數建議值說明
備份頻率1-15 分鐘決定 RPO(數據丟失容忍度),業務核心庫建議 1-5 分鐘。
複製/還原頻率同備份頻率保持同步,避免積壓。
保留天數2-7 天防止備份文件佔滿磁盤,配合清理作業。
備份壓縮啟用SQL Server 2008+ 支持,大幅減少網絡傳輸與磁盤佔用。
網絡路徑UNC 共享主備之間需互通,建議專用備份網段。

故障切換流程(手動)

日志傳送不支持自動故障轉移,主庫故障時需人工介入:

  1. 停止主庫日志備份作業(防止產生新備份)。
  2. 在備份庫執行最終日志還原:RESTORE DATABASE dbname WITH RECOVERY。
  3. 修改應用連接字串指向備份服務器(或更新 DNS / VIP)。
  4. 驗證業務可用性,通知相關方。
  5. 原主庫修復後,重新配置為新備份庫(角色互換)。

常見坑與避坑指南

  • 日志鏈斷裂:切勿在主庫執行非日志備份(如完整備份)時中斷日志備份鏈;若需補全,需重新建立完整備份基準。
  • 備份文件鎖定:複製作業失敗時常因文件被備份進程佔用,調整作業間隔錯峰執行。
  • 備份服務器磁盤爆滿:務必配置清理作業,並設置磁盤告警。
  • STANDBY 模式查詢阻塞:日志還原期間(RESTORE LOG)會獲取排他鎖,導致報表查詢卡死。解決:RESTORE LOG ... WITH STANDBY = 'undo_file' 並在還原間隙查詢,或採用 READ_COMMITTED_SNAPSHOT 隔離級別。
  • 版本不匹配:主備服務器主版本號必須一致(如均為 2019),補丁版本建議一致。

監控與告警

  • SSMS「查看日志傳送報表」查看延遲、最後備份/還原時間。
  • 監視服務器設置閾值告警(如「最後還原超過 30 分鐘」發送郵件)。
  • 自定義作業檢查 msdb.dbo.log_shipping_monitor_secondary 表,集成到 Zabbix/Prometheus/Grafana。

總結

日志傳送以「低成本、異地容災、報表卸載」三大優勢,成為標準版部署高可用的最佳選擇。關鍵在於:合理設置 RPO/RTO、嚴格監控延遲、演練故障切換流程。配合備份壓縮、專用網絡、自動化告警,可構建企業級穩健的災備體系。

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved