針對 SQL Server Always On 問題進行疑難解答
本文可協助您解決在 SQL Server 上 Always On 組態的常見問題。
注意事項
如需本文經驗的引導式逐步解說,請參閱疑難解答 SQL Server Always On 問題。
原始產品版本:SQL Server 2012 Enterprise、SQL Server 2014 Enterprise、SQL Server 2016 Enterprise
原始 KB 編號: 10179
重要提示
Microsoft CSS 數據指出,先前在發行 CU 中通常會解決相當大百分比的客戶問題,但不會主動套用,因此建議在 CU 可供使用時進行主動安裝。 如需詳細資訊,請參閱 SQL Server 累加式服務模型 (ISM) 的更新。
若要檢查您版本可能可用的最新 RU,請參閱如何判斷 SQL Server 及其元件的版本、版本和更新層級。
您可以在 Always On 可用性群組疑難解答和監視指南中看到適用於疑難解答和監視 Always On 可用性群組的實用工具,以深入瞭解可用於診斷不同問題類型和監視可用性群組的工具。 本指南也提供本引導式逐步解說中可能未涵蓋的其他案例。
Always On 可用性群組檔的父節點,並提供各種問題的一站式參考,請參閱 Always On 可用性群組 (SQL Server) 。
我需要設定和設定可用性群組 Always On指標
如果您要尋找設定 Always On 設定的檔案,請參閱下列檔:
使用者入門 Always On 可用性群組 (SQL Server) - 本檔提供有關可用性群組和設定的許多問題解答。 遵循本文中的所有步驟,並檢閱 Always On 可用性群組的必要條件、限制和建議 (SQL Server) 可協助防止您在環境中設定和維護可用性群組時遇到的許多問題。
其他資源
如果這項資訊沒有説明,請參閱 Always On 可用性群組的詳細資訊。
我在設定可用性群組 Always On 時遇到問題
一般設定問題包括 Always On 可用性群組已停用、帳戶設定不正確、資料庫鏡像端點不存在、無法存取端點 (SQL Server 錯誤 1418) 、網路存取不存在,以及聯結資料庫命令失敗 (SQL Server 錯誤 35250) 。 請檢閱下列檔,以取得針對這些問題進行疑難解答的說明:
針對可用性群組設定 Always On (SQL Server) 進行疑難解答
其他連結: 修正:當您嘗試建立多個可用性群組時發生錯誤 41009
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
我在接聽程式設定 (19471、19476 和其他錯誤時遇到問題)
客戶遇到的最常見設定問題之一是建立可用性群組接聽程式。 錯誤如下所示:
-
Msg 19471,層級 16,狀態 0,第 2 行:WSFC 叢集無法讓 DNS 名稱為 '' 的網络名稱資源上線。 DNS 名稱可能已被採用或與現有的名稱服務發生衝突,或 WSFC 叢集服務可能無法執行或無法存取。 使用不同的 DNS 名稱來解決名稱衝突,或檢查 WSFC 叢集記錄檔以取得詳細資訊。
-
Msg 19476、Level 16、State 4、Line 2 嘗試建立接聽程式的網路名稱和IP位址失敗。 WSFC 服務可能無法執行或無法在其目前狀態中存取,或為網路名稱和 IP 位址提供的值可能不正確。 檢查 WSFC 叢集的狀態,並向網路管理員驗證網路名稱和 IP 位址。
大多數時候,接聽程式建立失敗導致先前的訊息,是因為 Active Directory 中的叢集名稱物件 (CNO) 缺少建立和讀取接聽程式計算機物件的許可權。 若要針對此問題進行疑難解答,請檢閱下列文章:
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
自動故障轉移未如預期般運作
如果您注意到在測試期間或生產環境中,自動故障轉移未如預期般運作,請參閱:針對 2012 SQL Server 2012 Always On 環境中的自動故障轉移問題進行疑難解答。
未正確設定 指定期間內的失敗次數上限 ,是主要未自動故障轉移至次要複本的前置原因之一。 此設定的預設值為 N-1,其中 N 是複本數目。 如需詳細資訊,請 參閱故障轉移叢集 (群組) 失敗上限。
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
我在連線到可用性群組 Always On 時遇到問題
在 2012 年 SQL Server 為 Always On 可用性群組設定可用性群組接聽程式之後,您可能無法偵測接聽程式或從應用程式連線到該接聽程式。 您可能會收到類似下列的錯誤:
Sqlcmd:錯誤:Microsoft SQL Native Client:登入逾時已過期。
若要對此和類似的錯誤進行疑難解答,請檢閱下列各項:
詳細資訊連結:
- 更新引進了對 SQL Server 2012 或更新版本中 Always On 功能的支援,以 the.NET Framework 3.5 SP1
- SQL Server 多重子網叢集 (SQL Server)
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
我在 Azure VM (IaaS) 中設定 Always On 可用性群組時遇到問題
由於接聽程式的設定不正確,因此會發生許多與 Always On 相關的問題。 如果您有接聽程式的連線問題,
請務必閱讀 ILB 接聽程式的所有限制,並遵循下列文章中所述的所有步驟,特別注意 PowerShell 腳本中的相依性設定、IP 位址和各種其他參數。
如果不確定,您可以根據上述文件刪除並重新建立接聽程式。
如果您最近將 VM 移至不同的服務,或 IP 位址變更,您需要更新 IP 位址資源的值以反映新的位址,而且您需要重新建立 AG 的負載平衡端點。 您可以使用 或
Set
命令來更新 IP 位址,Get
如下所示:Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"
建議的檔案:
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
從主要故障轉移至次要複本需要很長的時間,反之亦然
在可用性群組上自動故障轉移或計劃性手動故障轉移而不會遺失數據之後,您可能會發現故障轉移時間超過復原時間目標 (RTO) 。 若要針對原因和可能的解決方法進行疑難解答,請參閱 疑難解答:可用性群組已超過 RTO。
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
主要復本上的變更不會反映在次要複本上,或是復寫至次要複本的速度變慢
您可能會注意到,主要複本上的變更不會及時傳播至次要複本。 若要針對這些問題進行疑難解答並加以解決,請嘗試下列步驟:
如需 SQL Server 2012 和 SQL Server 2014 環境,請參閱修正:當磁碟在 SQL Server AG 和 Logshipping 環境中,主要和次要復本記錄檔的扇區大小不同時,同步處理速度變慢。
檢查叢集管理員中的次要節點是否處於暫停狀態。
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
如何管理 AG 資料庫的事務歷史記錄大小
您可以在主要或輔助伺服器上設定一般備份,以減少事務歷史記錄大小。
如需其他資訊,請檢閱下列主題:
如果這項資訊沒有説明,請參閱 Always On 可用性群組的詳細資訊。
主要或輔助伺服器處於解析狀態,或您遇到非預期的故障轉移
檢查系統和應用程式事件記錄檔中是否有硬體問題和其他錯誤,並與廠商合作修正。
如果您使用虛擬機,請檢查其 知識庫,以查看是否有任何最近回報的問題可能造成問題。 例如, 在ESXi (2039495) 中,VMXNET3 vNIC上客體作業系統層級發生大型封包遺失, 在某些情況下會導致AG設定發生問題。
詳細資訊:
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
無法讓資源上線
檢閱 SQL ErrorLog 中的訊息,檢查資料庫是否需要很長的時間才能復原。
如果問題仍然存在,請參閱 Always On 可用性群組的詳細資訊。
常見問題集
一個可用性群組是否可以有兩個接聽程式?
是,您可以為相同的可用性群組設定多個接聽程式。 請參閱 如何建立相同可用性群組的多個接聽程式 (Goden) 。
是否可以有個別的 NIC 記憶卡,以便隨時使用流量和用戶端連線?
是,您可以擁有專用的 NIC 卡來 Always On 流量。 請 參閱設定可用性群組以在專用網路上通訊。
哪些版本支援 Always On 故障轉移叢集實例?
《SQL Server 在線叢書》中的本主題有詳細資訊:2016 年 SQL Server 版和支援的功能。
如何在叢集的所有節點發生失敗時復原?
哪裡可以找到 AG 組態中分散式交易支援的相關信息?
請參閱 交易 - 可用性群組和資料庫鏡像。
如何更新 Always On 組態?
如何將 TDE (透明數據加密) 啟用的資料庫新增至 AG 組態?
若要將已啟用 TDE 的 DB 新增至 AG,請參閱如何設定 TDE 資料庫的 Always On。
如何設定警示以檢查次要複本是否落後主要複本?
您可以使用下列文稿:
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id AS database_id, is_ag_replica_local = CASE WHEN ar_state.is_local = 1 THEN N'LOCAL' ELSE 'REMOTE' END, ag_replica_role = CASE WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED' ELSE ar_state.role_desc END, dr_state.last_hardened_lsn, dr_state.last_hardened_time, datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary' FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id) JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id) JOIN sys.dm_hadr_database_replica_states dr_state ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
如果資料庫的狀態不是同步處理的,如何收到警示?
您可以使用下列文稿:
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id AS database_id, is_ag_replica_local = CASE WHEN ar_state.is_local = 1 THEN N'LOCAL' ELSE 'REMOTE' END, ag_replica_role = CASE WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED' ELSE ar_state.role_desc END, ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id ) JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id) JOIN sys.dm_hadr_database_replica_states dr_state ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
您也可以檢閱下列連結,以取得監視 Always On 群組的其他方法: