五餅二魚工作室

從 SQL Server 2016 開始，SQL Server Standard 版本提供了「基本可用性群組」，讓 AlwaysON 也可以搭配 Standard 版本來做使用，基本上這些說明可以參考「單一資料庫的基本 Always On 可用性群組」上面的詳細說明，理會會有針對一些限制和注意事項。而也因為 Standard 有提供這樣的功能，這一陣子也有些朋友開始來架設，但幾乎每隔幾天就有人問說為什麼架設不起來，而我就針對這幾次所發現的問題，來做個整理一下：

1. 防火牆的設定

基本上大家都知道防火牆要開通，才能允許 SQL Server 的服務能被使用，但往往大家都只開了 1433，卻遺漏了 AlwaysON 所需要使用的 5022，因此我一般會先整理一下批次指令，這樣會比較方便設定。否則有些時候遠端連線，為了要能看到畫面還要安裝有的沒有的軟體或者是 VPN，因此就整理成指令，這樣就直接開啟 DOS 視窗來執行就好了。此部分設定好之後，就確定一下在兩台 SQL Server 上使用 SSMS，看能不能相互連接，如果不行的話，則可能沒有正常執行以下的指令了。

netsh advfirewall firewall add rule name="SQL Server Endpoint(TCP-in)"	dir=in action=allow protocol=TCP Profile=domain localport=5022 	description="Allows inbound Microsoft SQL connections." 
netsh advfirewall firewall add rule name="SQL Server Data (TCP-in)" 	dir=in action=allow protocol=TCP Profile=domain localport=1433 	description="Allows inbound Microsoft SQL connections." 
netsh advfirewall firewall add rule name="SQL Server Browser (UDP-in)" 	dir=in action=allow protocol=UDP Profile=domain localport=1434 	description="Allows inbound Microsoft SQL browser connections."

 

2. 沒有注意到端點存取權限

而當上述防火牆設定完成之後，通常都可以很順利的透過「新增可用性組精靈 」來進行設定，但比較多人會遇到的是看起來設定都很正常沒有錯誤發生，但確會發生 Primary 上看起來都正常，但是在 Secondary 上面，卻沒有看到資料庫的狀況，此時您可以用 SSMS 來開啟 Secondard 的 Error Log，則會看到類似以下的錯誤，這個問題多半會發生在兩台 SQL Server 安裝的時候都採用預設的服務帳號進行安裝，但因為當要跨電腦存取的時候，則會使用電腦名稱的帳號來連接，下面的案例就是一個在 MyLab 網域下面的 SQLVM1 會去連接 SQLVM2 去進行處理，但因為 MyLab\SQLVM1$ 這個電腦帳號在 SQLVM2 下沒有 Connect 的權限，因此無法連線導致後續無法進行，因此只要透過安全性設定，將兩台電腦的帳號分別設定給兩台，並賦予 Connect 或 public 的權限，就可以順利的去串接了。

3. 遺漏仲裁設定

一般來說如果有注意到前兩項，應該都可以順利架設起來 AG 了，但是如果將 Primary 的 SQL 關閉，或者是兩台電腦都同時關閉在同起啟動之後，就會發現 AG 並沒有順利的移到另外一台接手，或者是發生異常的狀況。這個也是新手常遇到的問題，想說完成前面的步驟也順利架設起來，應該就沒有問題，但就沒有注意到仲裁的設定，導致當有異常發生的時候，沒有辦法自動決定誰成為 Primary ，導致架設之後無法正常使用。因為在 AG 的環境下，並沒有一定要用共用的 Storage，因此很多人會選用「檔案共用見證」的方式，但如果您的環境是使用 VM，或者是有可能提供共享目錄的電腦也會同時間一同關閉的話，就有可能兩台 SQL Server 啟動的時候，因為沒有辦法取得超過半數的票數，導致沒有辦法正常啟動起來。因此在這裡除了要設定之外，也要找一個比較合適的方式，這樣才不會無法仲裁造成異常。

4. 注意程式連線

一般來說對於安裝的人來說，通常都會注意到前面三項，但有些時候也會很傻眼的遇到一些環境，明明 AG 都已經設定好了，但應用程式的連線字串，卻不是連接到 AG 的 Listen IP ，而是連接到 Primary 的 IP。這樣雖然一開始是可以使用的，但是當發生容錯移轉之後， Primary 就會變成 Secondary，此時程式就會發生無法連線。也曾遇到有發生這樣的問題之後，該單位就把 SQL Server 再重新啟動，此時讓 Primary 回到原本的那一台，就可以繼續使用了。雖然有些時候我們都笑說重開治百病，但這真的不是一個很好的示範，您應該將應用程式的連接改成連接到 Listen ，再由 Listen 來看最後轉到哪一台電腦上去，這樣才會是比較正確的。

而如果您的 AG 有開放允許讀取副本的狀況下，則可以讓連接字串上加入「ApplicationIntent=ReadOnly」，此部分可以參考微軟的文件「連線到 Always On 可用性群組接聽程式」上面也有詳細說明。

 

5. 別忘了交易紀錄備份

因為當我們在使用 AlwaysON 的時候，資料庫的復原模式則必須要是 Full 的狀況，很多朋友沒有注意到這個部分，因此上線之後都只有針對資料庫做完整備份，還時常的去做重建索引之類的處理，導致上線沒有多久，就發現交易紀錄檔過大，占用很多磁碟空間。甚至有人的作法是先把 AG 砍掉，然後把資料庫復原模式設定為簡單，再去壓縮資料庫讓交易紀錄檔縮小之後，再重新把 AG 的設定起來，這實在是個很令人傻眼的作法。其實您只要利用維護計畫，放入備份資料庫的 Task ，讓他可以定時去備份交易紀錄檔出來，基本上交易紀錄檔就可以循環使用了，而這個部分 SQL Server 的維護計畫也很貼心，當你有在 AG 的環境下，他會自動幫你判斷要在哪一台做備份，因此一般我都會在兩台電腦上都去設定排程定時去備份交易紀錄檔，這樣就不用去管到底哪一台是 Primary 了。ㄧ

 

以上幾項是剛好最近一堆人再詢問 AlwaysON 所遇到的問題，有興趣的朋友也可以再參考一下微軟官方文件的「疑難排解 AlwaysOn 可用性群組組態 (SQL Server)」裡面也有些資料可以參考，只是我剛好遇到的都是前面這幾項為主，因此就先把這些整理一下了，讓遇到問題的朋友可以先自行查看一下，免得自己有些時候同時被好幾個人詢問，而忘記去做處理了。