資料一致性

Cache引起的資料一致性問題

引起資料一致性問題的一個主要原因是位於資料I/O路徑上的各種Cache或Buffer（包括資料庫Cache、檔案系統Cache、儲存控制器Cache、磁碟Cache等）。由於不同系統模組處理資料IO的速度是存在差異的，所以就需要新增Cache來快取IO操作，適配不同模組的處理速度。這些Cache在提高系統處理效能的同時，也可能會“滯留”IO操作，帶來一些負面影響。如果在系統發生故障時，仍有部分IO“滯留”在IO操作中，真正寫到磁碟中的資料就會少於應用程式實際寫出的資料，造成資料的不一致。當系統恢復時，直接從硬碟中讀出的資料可能存在邏輯錯誤，導致應用無法啟動。儘管一些資料庫系統（如Oracle、DB2）可以根據redo日誌重新生成資料，修復邏輯錯誤，但這個過程是非常耗時的，而且也不一定每次都能成功。對於一些功能相對較弱的資料庫（如SQL Server），這個問題就更加嚴重了。

解決此類檔案的方法有兩個，關閉Cache或建立快照（Snapshot）。儘管關閉Cache會導致系統處理效能的下降，但在有些應用中，這卻是唯一的選擇。比如一些高等級的容災方案中（RPO為0），都是利用同步映象技術在生產中心和災備中心之間實時同步複製資料。由於資料是實時複製的，所以就必須要關閉Cache。

快照的目的是為資料卷建立一個在特定時間點的狀態檢視，通過這個檢視只可以看到資料卷在建立時刻的資料，在此時間點之後源資料卷的更新（有新的資料寫入），不會反映在快照檢視中。利用這個快照檢視，就可以做資料的備份或複製。那麼快照檢視的資料一致性是如何保證的呢？這涉及到多個實體（儲存控制器和安裝在主機上的快照代理）和一系列的動作。典型的操作流程是：儲存控制器要為某個資料卷建立快照時，通知快照代理；快照代理收到通知後，通知應用程式暫停IO操作（進入backup模式），並flush資料庫和檔案系統中的Cache，之後給儲存控制器返回訊息，指示已可以建立快照；儲存控制器收到快照代理返回的指示訊息後，立即建立快照檢視，並通知快照代理快照建立完畢；快照代理通知應用程式正常執行。由於應用程式暫停了IO操作，並且flush了主機中的Cache，所以也就保證了資料的一致性。

建立快照是對應用效能是有一定的影響的（以Oracle資料庫為例，進入Backup模式大約需要2分鐘，退出Backup模式需要1分鐘，再加上通訊所需時間，一次快照需要約4分鐘的時間），所以快照的建立不能太頻繁。

時間不同步引起的資料一致性問題

引起資料不一致性的另外一個主要原因是對相關聯的多個資料捲進行操作（如備份、複製）時，在時間上不同步。比如一個Oracle資料庫的資料庫檔案、Redo日誌檔案、歸檔日誌檔案分別儲存在不同的捲上，如果在備份或複製的時候未考慮幾個卷之間的關聯，分別對一個個捲進行操作，那麼備份或複製生成的卷就一定存在資料不一致問題。

此類問題的解決方法就是建立“卷組（Volume Group）”，把多個關聯資料卷組成一個組，在建立快照時同時為組內多個卷建立快照，保證這些快照在時間上的同步。之後再利用卷的快照檢視進行復制或備份等操作，由此產生的資料副本就嚴格保證了資料的一致性。

檔案共享中的資料一致性問題

通常所採用的雙機或叢集方式實現同構和異構伺服器、工作站與儲存裝置間的資料共享，主要應用在非線性編輯等需要多臺主機同時對一個磁碟分割槽進行讀寫。

在NAS環境中，可以通過網路共享協議N FS或CIFS來做到資料的共享。但是如果不在NAS環境中，多臺主機同時對一個磁碟分割槽進行讀寫會帶來寫入資料一致性的問題，造成檔案系統被破壞或者當前主機寫入後其它主機不能讀取當前寫入資料的問題。

可以通過使用資料共享軟體裝在多臺主機上來實現磁碟分割槽的共享。由資料共享軟體來調配多臺主機資料的寫入，保證資料的一致性。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29337971/viewspace-1073241/，如需轉載，請註明出處，否則將追究法律責任。