Date: 18 1 月, 2018
我被問過這個問題不止幾次，所以我想我會在我的第一篇博客文章中回答這個問題。基本答案是肯定的，在多站點集群中使用異步複製時，可能會導致意外失敗的數據丟失。在一個理想的世界裡，每個公司都會有一個到他們災難恢復站點的暗光纖連接，並使用與他們的多站點集群同步複製，消除數據丟失的可能性。但是，現實情況是，在許多情況下，到災難恢復站點的廣域網連接有太多的延遲來支持同步複製。在這種情況下，異步複製是一個很好的選擇。選擇WSFC多站點群集使用的異步複製解決方案時，有多種選擇，包括來自EMC，IBM，HP等公司的基於陣列的解決方案。以及基於主機的解決方案，就像“SteelEye DataKeeper Cluster Edition”中那樣近乎親愛的解決方案。由於我最了解DataKeeper，所以我將解釋DataKeeper的這一切是如何工作的。當使用SteelEye DataKeeper和異步複製時，我們允許將一定數量的寫入存儲在異步隊列中。可以排隊的寫入次數由“高位標記”確定，“高位標記”是DataKeeper用來確定鏡像狀態從“鏡像”更改為“暫停”之前隊列中有多少數據的可調整值。。當輔助服務器和主服務器之間發生通信故障時，也會進入“暫停”狀態。處於暫停狀態時，多站點群集中的自動故障轉移將被禁用，從而限制意外故障中可能丟失的數據量。如果原始數據集被認為是“永久丟失”，則可以手動解鎖目標服務器上的剩餘數據，然後可以使集群節點投入使用。在“暫停”狀態下，DataKeeper允許異步隊列耗盡，直到達到“低水位”，此時鏡像將進入“重新同步”狀態，直到所有數據再次同步。此時，鏡像再次處於“鏡像”狀態，並且自動故障轉移再次啟用。只要你的廣域網鏈路沒有飽和或破壞，在這個異步隊列中的任何時候，你永遠不應該看到更多的寫入。如果出現意外的故障（請拔掉電源線），您將失去異步隊列中的任何寫入。當您需要使用多站點群集實現的卓越恢復點目標（RPO）和恢復時間目標（RTO）時，這是您所做的交易，但是您的WAN鏈路有太多的延遲來有效支持同步複製。如果您需要花時間通過Windows性能日誌和警報來監視DataKeeper異步隊列，那麼由於DataKeeper複製引擎的高效性，我認為您會驚喜地發現大部分時間異步隊列都是空的。即使在大量寫入的時候，異步隊列也很少會變得非常大，並且幾乎立即就會排空，所以在任何給定時間處於風險的數據量都是最小的。如果考慮到災難中的備選方案可能是從昨晚的備份中恢復，那麼使用異步複製可能導致意外故障的寫入次數極少！當然，也有一些情況下，即使丟失一個單一的寫是不可容忍的。在這種情況下，建議在高速，低延遲的LAN或WAN連接上使用SteelEye DataKeeper的同步複製選項。轉載https://clusteringformeremortals.com/2009/07/的許可