跳到主要內容區塊

ntuccepaper2019

技術論壇

SQL Server 2017與Always on高可用性群組使用心得
  • 卷期:v0056
  • 出版日期:2021-03-20

作者:傅潔瑩 / 臺灣大學計算機及資訊網路中心程式設計組 / 幹事


 

網路上有許多資源解說SQL Server Always on 如何設定及使用,但鮮少分析Always on的特性及優缺點。今年適逢SQL Server 2008支援到期,必須升級資料庫伺服器,把這段時間跟同仁合作的過程摘要記錄下來,也供日後想選擇此解決方案的使用者一點參考。

 

先來看升級這件事

在談Alwawys on機制之前,先來說一下資料庫升級。早先SQL server2017發布之前,一直以為SQL Server按照慣例只能支援上下2個版本,因此同仁就非常認真積極尋求各種資料庫轉移方法,大家非常辛苦的多次進行轉移、測試、檢查各種資料一致性…等。
最後某次不經意在網路「巡田水」查資料發現,SQL Server 2008的資料可以「直升」到SQL Server 2017!經我們多次實驗,在此告訴大家結論:
1.SQL Server 2008的mdf檔、備份檔,都可以直接升到SQL Server 2017。
2.將SQL Server 2017的相容性調至2008即可。
3.上述升級不是用master資料庫。

Master資料還是需要辛苦轉移,還有必須另外把使用者帳號與uid完整複製到新資 料庫伺服器。

 

關於對Always on的心得

接下來就進入主題了,我用結論來說明比較快。如果你的資料庫具有下列特性,可以將Always on納入候選名單:

1. 資料庫伺服器的使用者不會經常異動:
 a. Always on不會同步Master DB,如果在系統有異動,全部必須人工進行資料同步。

 b.如果你的資料庫伺服器隔一段時間就會有其他單位來申請權限讀取,只要帳號有刪減,都要人工同步。

2. 不會有自動產生資料庫的系統:
因為Master DB不會同步,所以如果有系統會自動長出資料庫的,都不適合(例如:表單系統,流程引擎…具有較複雜功能的模組),記得要確認。

3. 沒有大量資料的異動程序:
Always on 靠log來同步資料,每個行為都會產生log。所以如果你有那種,定期刪掉原有資料,再去 同步其他資料庫資料的預存程序,每執行一次就會產生相當可觀的log紀錄檔,硬碟使用量會超乎想像。

4. 有餘裕的儲存空間:
承3,Always產生log速度非常驚人,壓縮手續繁複耗時,較適合有大容量儲存空間的伺服器使用。

如果你的資料伺服器不具上述狀況,請多慎重考慮,再決定是否採用Always on機制。

 

小結

其實Always on同步完整度與即時性令人欣賞,但這陣子試用下來,發現要進行log檔的壓縮,調整log的大小限制…等工作時,都必須將資料庫移出Always on可用性群組,進行完所有設定(或備份)才能再將資料庫加回。
移出期間若有資料寫入就無法同步,需負擔一定程度的風險,或是有較短周期的檢修機制搭配才較適合(例如:每天固定可以有一到兩小時停止服務,此時就可以進行上述調整)。
另外Always on權限控管,微軟建議綁在AD上,因此若像我們不是以AD帳號在管理資料庫的DBA,就無法直接進行相關管理工作,需要另外給予AD帳號,以往的管理方式都需配合調整。
以上簡單整理使用的心得,希望大家都能尋得最適合自己的解決方案。