SQL Server中的高可用特性工作中使用SQL Server高可用特性的場景也就是資料庫主從複製，可以用的特性有三個：複製、映象、日誌傳送。複製（釋出-訂閱模式）：

複製嚴格來說並不算是一個為高可用性設計的功能，但的確可以被應用於高可用性。複製提供了資料庫物件級別的保護。複製使用的是釋出-訂閱模式，即由主伺服器（稱為釋出伺服器）向一個或多個輔助伺服器或訂閱伺服器釋出資料。複製可在這些伺服器間提供實時的可用性和可伸縮性。它支援篩選，以便為訂閱伺服器提供資料子集，同時還支援分割槽更新。訂閱伺服器處於聯機狀態，並且可用於報表或其他功能，而無需進行查詢恢復。

SQL Server 提供四種複製型別：快照複製、事務複製、對等複製以及合併複製。

我們一般選擇快照複製或事務複製，兩者概念介紹如下：

快照複製

1、概念 快照複製是完全按照資料和資料庫物件出現時的狀態來複制和分發它們的過程。快照複製不需要連續地監控資料變化，因為已釋出資料的變化不被增量地傳播到訂閱伺服器，而是週期性的被一次複製。

2、 適用情況 資料主要是靜態的，比如將資料倉庫複製到資料集市中 一段時間內允許有已過時的資料複製的情況 小批次資料 站點經常脫離連線，並且可接受高延遲

事務複製

1、概念 使用事務複製，初始快照資料將被傳播到訂閱伺服器，因此該訂閱伺服器就具有了一個所謂的初始負載，這是可以開始工作的內容。當出版伺服器上發生資料修改時，這些單獨的事務會被及時捕獲並複製到訂閱伺服器。並保留事務邊界，當所有的改變都被傳播後，所有訂閱伺服器將具有與傳播伺服器相同的值。

2、適用情況 需要資料修改經常在其發生的幾秒鐘內被傳播到訂閱伺服器 需要事務是原子性的 訂閱伺服器在通常是連線到出版伺服器上的 應用程式不能忍受訂閱伺服器接收改變的高延遲 建立釋出-訂閱的資料庫伺服器名不能是IP，只能是具體的伺服器名稱，如：可以執行以下SQL檢視：

結果：

如果上下一致，則說明沒有問題，否則就需要改成一致的。如果右鍵點選建立釋出或訂閱都不報錯，那麼可以進行下一步。根據具體情況使用不同的複製型別，這裡我使用了事務複製：具體建立過程參考https://www.cnblogs.com/zhaow/articles/8275064.html，這裡我們建立個名叫DBPublishZW20180815的釋出。並且成功地在訂閱資料庫中建立了訂閱，如：建立釋出-訂閱後，我們可以監測釋出和訂閱狀態，如：還可以監測釋出JOB和Agent的執行狀態：

複製中釋出伺服器和訂閱伺服器內容不一致的解決辦法在事務複製的過程中，有時候會由於各種各樣的原因導致釋出伺服器和訂閱伺服器的資料不一致，造成這種情況往往是由於以下幾種原因之一：①某個Agent執行出現錯誤或者Agent程序崩潰②比較大型的釋出是使用了備份還原，而不是快照複製初始化，而備份後釋出端修改了資料③非Distribution Agent執行緒修改了訂閱伺服器的資料上面三種情況是最常見的導致釋出端和訂閱端資料不一致的原因，其中第三種原因往往出現的最多，在這種情況下，通常來說，可以透過重新初始化訂閱來解決該問題，但對於比較大的訂閱來說，或者釋出和訂閱之間相隔太遠而造成網路寬頻的問題，則重新初始化訂閱就不是那麼吸引人的提案了。因此透過資料對比分析工具來比對有差異的資料，並僅僅更新那些和源不同步的資料則是更好的選擇。這類工具包括類似Redgate和xSql的資料對比工具，也可以使用Visual Studio自帶的資料對比工具。首先，我刪除訂閱庫中表中的一條資料（其實訂閱庫應該是隻讀的），此時訂閱庫就與釋出庫資料不一致了。我們來看下監測結果：

可以看到，這裡已經有了資料不同步的Log了，還可以看到釋出-訂閱的整個過程Log：

使用Visual Studio自帶的資料對比工具關於Visual Studio的SQL SERVER資料庫專案介紹：1、開啟VS，點選檔案-新建專案-SQL SERVER 資料庫專案（tips:安裝vs時需要新增資料庫管理外掛）2、建立專案後，在建立的解決方案下右鍵點選匯入-資料庫-選擇資料庫所在連線，匯入設定預設就好，如果你們的資料庫許可權範圍較高的話，根據自身情況設定3、啟動成功後，會自動掃描資料庫的相關配置載入到VS列表當中，這樣對系統的資料庫架構就一覽無遺了4、開啟某個表的結構檔案，可以看到我們表結構設計，相關的索引、主鍵、觸發器等，當然都只是結構，並且我們在介面上修改後，同時會生成對應的SQL語句，我們可以直接到資料庫中F5執行 以下即可由於我本機Visual Studio沒裝這個專案型別，所以參考https://www.cnblogs.com/CareySon/p/3302369.html吧！1、找出被刪除的資料2、然後我們點選"更新目標"，則被刪除的資料會由釋出端同步到訂閱端。如：我們再次進行驗證訂閱，顯示已經透過訂閱。

如果採用 alwayson 模式， 從資料庫副本可以用非同步模式進行同步，能解決主資料庫的時延等待過長的問題。

如果採用replication 複製，則可以考慮提升主 從庫之間的網路連結質量，比如說使用專線， 或者加速器之類的！

你需要在主機寫入之後，保證在備機一定能夠讀取到已經寫入的資料，也就是說，你需要主從架構下的強一致性。

主機與備機之間的物理延遲是不可控的，也是無法避免的。但是如果僅僅需要滿足這種強一致性，是相對簡單的事：只需要在主機寫入時，確認更新已經同步到備機之後，再返回寫操作成功即可。