有人可以幫助解釋為什麼 DBA 會反對數據庫集群的細節嗎？
我是系統管理員，不會每天管理數據庫。我的組織正在考慮使用數據庫集群來實際消除某些服務的停機時間。我們主要使用 oracle 數據庫 (v19) 和一些 SQL (2016)。我們的 DBA 反對這一點，據我研究，對數據庫集群唯一真正的負面影響是數據庫損壞的風險較低。我們有四個不同的備份位置，包括一個異地備份。我試圖進一步了解我們的 DBA 立場，並了解數據庫集群將如何影響他們的日常工作。任何見解將不勝感激！
作為一名擁有 30 年 Oracle 經驗的 DBA，其中大約一半使用 Oracle RAC，我可以說，如果您的目標是減少停機時間，那麼 RAC（具有共享儲存的主動-主動集群）或 DataGuard（具有故障轉移的複制）可以當然有幫助。缺點是它們可能會引入很多複雜性，並且 - 對於 RAC - 一些特定的硬體要求：因此，如果您的 DBA 以前沒有使用過這些技術，那麼學習曲線會很重要，並且可能需要花費一些費用來獲得正確的硬體以使其工作.
根據我的經驗，使用 RAC 或 DataGuard 的數據損壞風險並沒有顯著增加。實際上，我從來沒有聽說過這是目前 Oracle 災難恢復技術的“騙局”。財富 100 強公司每天都嚴重依賴這些，所以只要你的 DBA 接受過適當的培訓，我傾向於相信它。
從純粹的商業角度來看，RAC確實會引入大量額外的許可成本。DataGuard 沒有 RAC 複雜，基本版本不需要任何額外的許可。Oracle 還有一款名為 GoldenGate 的產品，可用於為除 Oracle 之外的許多其他數據庫平台提供 DR。
最後，您需要權衡所有這些費用（培訓、硬體、許可證等）和風險與停機成本和/或您現在擁有的任何災難恢復計劃。
除了 Oracle 回答提到的內容之外，您在使用 SQL Server 時也遇到了類似的障礙。SQL Server 中 HA/DR 的實際解決方案是通過AlwaysOn 可用性組設置故障轉移集群。但使用它們的潛在障礙是：
- 增加的許可成本 - 所有伺服器都需要執行企業版，並且輔助副本伺服器需要獲得許可。
- 增加的性能成本 - 因為數據從主同步到輔助。如果您在同步模式下執行其中一個輔助伺服器（以最大程度地降低數據失去的風險），那麼當它落後太多並且主伺服器正在等待事務時，該輔助伺服器可能成為主伺服器的瓶頸在那次重播。
- 增加管理工作 - 諸如數據庫和伺服器更新之類的事情不再是微不足道的。在一個過程中，您基本上必須中斷集群並導致故障轉移到一台伺服器以首先應用更新，然後故障轉移回另一台伺服器以執行相同操作，然後重新啟用集群。驗證 AlwaysOn 可用性組是否仍按預期工作並且所有輔助節點都趕上主節點也是一個過程。從應用程序的角度來看，您可能必須至少進行一些小的更改，以確保應用程序知道要正確連接到哪個伺服器。（AlwaysOn 可用性組有一個偵聽器，可以利用它來簡化此操作。）
對於管理故障轉移集群的基礎架構團隊和管理實際副本的 DBA 團隊來說，使用 AlwaysOn 可用性組有一個相當大的學習曲線。除了所有這些，我敢肯定還有其他原因，它也不是那麼交鑰匙實施。或者，基礎架構團隊使用的 HA/DR 解決方案通過維護整個伺服器本身的精確副本來工作。我聽說這些縮小了上述一些問題。