五餅二魚工作室

前一陣子接到一個需求，要架設一套高可用性的 SQL Server，因為是搭配 Windows Server 2012 R2 & SQL Server 2014，原本想建議直接安裝 SQL Server AlwaysON 的 Database 模式，但因為對方要求帳號也要即時同步，而且增加資料庫的時候又不希望人為介入就可以有高可用性的狀況下，因此就更改 Storage 的連線方式，改成可共用磁碟之後，再來安裝 SQL Server Cluster。

基本上安裝 SQL Server Cluster 並沒有甚麼太大的難度，只要預先把 Windows AD 預備好，共用 Storage 可以支援，那麼安裝應該也只是一塊小蛋糕，因為安裝過程多半都是下一步、下一步、下一步下去，只要環境是 Ready 的狀況，應該一個小時就可以搞定了。

但在這樣的架構下原本都是正常的，但既然是高可用性，就會有人想來測試看看是否真的是高可用性，原本是 PRIDBSVR 是主要服務伺服器，在容錯移轉叢集管理員上去模擬失效，或者是手動移轉主要伺服器都沒有問題。但不知道是測試過程拔錯的線路還是其他原因，在最後一次測試過程中，當把 PRIDBSVR 的線路都拔除之後，SQL Server 主要服務會自動移轉到 SECDBSVR 上正常運作，但當把第一台線路恢復正常重新啟動之後，卻發現沒有辦法移轉回到 PRIDBSVR 了。

看起來不知道怎麼了，於是查看 Windows 的事件檢視器內「系統」的訊息，找到罪魁禍首 "叢集共用磁碟區根目錄 'C:\ClusterStorage' 已經存在。目錄 'C:\ClusterStorage' 已重新命名為 'C:\ClusterStorage.000'。請確定已依需要更新此位置中的應用程式存取資料。"

這個是 Windows 的事件檢視器內「應用程式」的訊息

所以從上面兩個的訊息中我們可以得知，原來是叢集服務把 「CSV ( Cluster Shared Volume )」 的根結點的路徑給改了，造成 SQL Server 要移轉到另外一台去的時候，就無法連上對應的目錄，導致 SQL Server 無法移轉。而正在服務的主機則還可以存取原本連接的 CSV ，因此雖然根結點的目錄名稱改了，但仍然可以運作。

既然知道問題的原因了，那麼要怎麼來修正了，或許會覺得最簡單就是手動更改根結點名稱，但這樣是不行的，因此叢集中有結點還在使用中，因此不能更改。或者是想說那就把兩台 SQL Server 給都退出 Cluster，並且先取消共用磁碟之後再重新加入，但此舉勢必影響現在正在服務的 SQL Server 必須停機維護，影響的層面也太大了。因此上述兩個方式都先不考慮，而要找一個可以不影響目前正在運作的 SQL Server 下，如果讓另外一個節點可以順利被移轉。因此我們會用以下的方式來進行：

1. 調整起動參數：因為 SQL Server 的 master 存放路徑和 errorlog 的路徑都已經不同了，因此需要手動調整兩台 SQL Server Cluster 上的 SQL Server 組態管理員內， SQL Server 服務的「啟動參數」，這個步驟我傻傻的作了快 5 次，後來才發現要記得先去改目前是 Active 那台主機上的啟動參數，而不是先改 Passive 的，因為當 Passive 要啟動的時候會先去取得 Active 那台的啟動參數，這點一開始我沒有注意到，一值更改 Passive 上面的設定，想說怎麼更改了都沒有用，後來才想到要去改 Active 那台的才對，因此這個部分要注意一下。

2. 手動更改「系統資料庫」的路徑，這個要在目前 Active 那台上面去執行，讓這些設定去更改到 master 資料庫裡面的設定。

-- 更改 tempdb

ALTER DATABASE tempdb 

MODIFY FILE (NAME = tempdev, FILENAME = 'C:\ClusterStorage.000\Volume1\MSSQL12.MSSQLSERVER\MSSQL\DATA\tempdb.mdf');

GO

ALTER DATABASE tempdb 

MODIFY FILE (NAME = templog, FILENAME = 'C:\ClusterStorage.000\Volume1\MSSQL12.MSSQLSERVER\MSSQL\DATA\templog.ldf');

GO

-- 更改 model

ALTER DATABASE model 

MODIFY FILE (NAME = modeldev, FILENAME = 'C:\ClusterStorage.000\Volume1\MSSQL12.MSSQLSERVER\MSSQL\DATA\model.mdf');

GO

ALTER DATABASE model 

MODIFY FILE (NAME = modellog, FILENAME = 'C:\ClusterStorage.000\Volume1\MSSQL12.MSSQLSERVER\MSSQL\DATA\modellog.ldf');

GO

-- 更改 msdb

ALTER DATABASE msdb 

MODIFY FILE (NAME = MSDBData, FILENAME = 'C:\ClusterStorage.000\Volume1\MSSQL12.MSSQLSERVER\MSSQL\DATA\MSDBData.mdf');

GO

ALTER DATABASE msdb 

MODIFY FILE (NAME = MSDBLog, FILENAME = 'C:\ClusterStorage.000\Volume1\MSSQL12.MSSQLSERVER\MSSQL\DATA\MSDBLog.ldf');

GO

3. 手動更改「使用者資料庫」的路徑：基本上參考類似上面的指令，針對已經在 Cluster 上面建立好的資料庫一個一個去更改對映的路徑。

4. 手動更改 SQL Agent 的 Error Log 存放目錄：原本以為作完前面幾項就可以順利容錯移轉了，但測試一兩次都不成功，後來發現是因為 SQL Agent 不能啟動，而不能啟動的原因也是無法順利寫入 Error Log。SQL Server 的 Error Log 路徑是放在啟動參數內，但 SQL Agent 的則是存放在 msdb 的資料庫內，因此這個部份我們需要借用兩個 msdb 內的預存程序「sp_get_sqlagent_properties」和 「sp_set_sqlagent_properties」，分別用來取得和設定參數。

-- 取得 SQL Agent 的參數

EXEC msdb..sp_get_sqlagent_properties

GO

-- 設定 SQL Agent Log File 路徑 

EXEC msdb.dbo.sp_set_sqlagent_properties 

@errorlog_file=N'C:\ClusterStorage.000\Volume1\MSSQL12.MSSQLSERVER\MSSQL\Log\SQLAGENT.OUT'

GO

完成上述步驟之後，也讓我在心驚膽跳之中，將 SQL Server 順利容錯移轉了，算是完成一件「簡單任務」了。

PS. 後續花了不少時間再查倒是為什麼會讓 CSV 根結點變更，詢問一下常在維護 Cluster 的朋友，有些人是有遇到過，多半的解決方式都是移除再重裝，但不清楚真正的原因是甚麼。也有朋友說是因為我只有兩台作叢集，又沒有設定仲裁磁碟才會有這樣的狀況，但我查一下叢集的設定，是有設定仲裁磁碟，似乎也不是這個原因。因此目前只能先知道怎麼樣來解決這樣的問題，但還需要再去找看看發生的原因為何。