1. 淺談資料庫集群軟體優缺點有哪些
集群（Cluster）是由兩台或多台節點機（伺服器）構成的一種鬆散耦合的計算節點集合，為用戶提
供網路服務或應用程序(包括資料庫、Web服務和文件服務等)的單一客戶視圖，同時提供接近容錯機的故
障恢復能力。集群系統一般通過兩台或多台節點伺服器系統通過相應的硬體及軟體互連，每個群集節點都
是運行其自己進程的獨立伺服器。這些進程可以彼此通信，對網路客戶機來說就像是形成了一個單一系統，
協同起來向用戶提供應用程序、系統資源和數據。除了作為單一系統提供服務，集群系統還具有恢復服務
器級故障的能力。集群系統還可通過在集群中繼續增加伺服器的方式，從內部增加伺服器的處理能力，並
通過系統級的冗餘提供固有的可靠性和可用性。
二、集群的分類：
1、高性能計算科學集群：
以解決復雜的科學計算問題為目的的IA集群系統。是並行計算的基礎，它可以不使用專門的由十至
上萬個獨立處理器組成的並行超級計算機，而是採用通過高速連接來鏈接的一組1/2/4 CPU的IA伺服器，
並且在公共消息傳遞層上進行通信以運行並行應用程序。這樣的計算集群，其處理能力與真正超級並行
機相等，並且具有優良的性價比。
2、負載均衡集群：
負載均衡集群為企業需求提供更實用的系統。該系統使各節點的負載流量可以在伺服器集群中盡可
能平均合理地分攤處理。該負載需要均衡計算的應用程序處理埠負載或網路流量負載。這樣的系統非
常適合於運行同一組應用程序的大量用戶。每個節點都可以處理一部分負載，並且可以在節點之間動態
分配負載，以實現平衡。對於網路流量也如此。通常，網路伺服器應用程序接受了大量入網流量，無法
迅速處理，這就需要將流量發送給在其它節點。負載均衡演算法還可以根據每個節點不同的可用資源或網
絡的特殊環境來進行優化。
2. 資料庫集群
拿ORACLE為例：
集群是多台伺服器共同提供服務，資料庫集群的意思就是多台運行資料庫服務的伺服器組成一個集群。
ORACLE的集群，自己的是RAC，最少需要2台機器，先裝CLUSTER或者GRID，再在集群上安裝資料庫，就可以了。
要是DB2的話，還得用IBM的操作系統，安裝一個集群軟體 HACMP等等的。
反正 核心要理解的就是 ，做集群，要有集群系統來支撐。例如 ，文件同步訪問等等的。
RAC，HACMP等等的，都屬於集群系統！
3. 資料庫集群技術有哪些
資料庫集群技術
1)提高資料庫處理速度的技術
目前有四種提高資料庫處理速度的辦法：
◆ 提高磁碟速度：這包括RAID和其他磁碟文件分段的處理。主要的思想是提高磁碟的並發度（多個物理磁碟存放同一個文件）。盡管實現方法各不相同，但是它們最後的目的都是提供一個邏輯資料庫的存儲映象。我們要評價的六個系統都能有效地利用這些技術。由於ICX已經有最大的磁碟冗餘度，RAID 磁碟系統的設置應該側重於速度，而不是數據冗餘。這樣磁碟利用的效益就會提高。
◆ 分散數據的存放：主要思想是利用多個物理伺服器來存放數據集的不同部分（一個資料庫表格分散到多個伺服器或者每個伺服器分管幾個內容不同的表格）。這些辦法不但可以擴展數據集（數據集的可擴性），而且使得不同的伺服器進行並行計算成為可能。例如，對於ORACLE的RAC來講，由於它是共享磁碟的體系結構，你只需要簡單地增加一個伺服器節點，RAC就能自動地將這節點加入到它的集群服務中去。RAC會自動地將數據分配到這節點上，並且會將接下來的資料庫訪問自動分布到合適的物理伺服器上，而不用修改應用程序。對於UDB來講，因為它是非共享磁碟的體系結構，因此就必須手工修改數據的分區，MSCS和ASE也是同樣的情況。MySQL也需要手工分區，並且是這幾種資料庫中支持分區的自動化程度最低的，也就是說，應用程序需要自己負責資料庫的分布式訪問。不管數據存放是如何實現的，分布式存放數據的缺點是對資料庫的可用性有負面影響。任何一台伺服器的損壞都會影響整個系統的可用性。但是，這是迄今為止各大資料庫廠商能提供的業界最好的資料庫集群技術了。ICX是一種基於中間件的資料庫集群技術，它對客戶端和資料庫伺服器都是透明的。因此，ICX可以用來集群幾個資料庫集群（一個邏輯資料庫），也可以用於集群幾個物理資料庫伺服器（來增強一個分管關鍵數據的物理伺服器）。
◆ 對稱多處理器系統：此技術的思想是利用多處理機硬體技術來提高資料庫的處理速度。但是，除了ICX，所有其它的資料庫集群技術只支持單一的可修改的邏輯資料庫。絕大部分的資料庫事務處理是磁碟密集型的，純計算負荷很小的，對稱多處器技術在資料庫上的應用的實際收益是很有限的。這也說明了為什麼實際應用中最多隻用了四個CPU的原因。所有的基於資料庫引擎的集群都支持這個技術，ICX對SMP技術是中性的，因為它能把多個資料庫伺服器集合在一起構成一個集群，也能將多個現存的資料庫集群集合在一起，構成集群的集群。
◆ 交易處理負載均衡：此技術的思想是在保持數據集內容同步的前提下，將只讀操作分布到多個獨立的伺服器上運行。因為絕大多數的資料庫操作是瀏覽和查詢,，如果我們能擁有多個內容同步的資料庫伺服器，交易負載均衡就具有最大的潛力（可以遠遠大於上面敘述的最多達四個處理器的對稱多處理器系統）來提高資料庫的處理速度，同時會具有非常高的數據可用性（真正達到5個9，即99.999%）。所有基於資料庫引擎的集群系統都只支持一個邏輯資料庫映象和一個邏輯或物理的備份。這個備份的主要目的是預防數據災難。因此，備份里的數據只能通過復制機制來更新，應用程序是不能直接更新它的。利用備份數據進行交易負載均衡只適用於一些非常有限的應用，例如報表統計、數據挖掘以及其它非關鍵業務的應用。只有ICX能夠做到同步復制多個資料庫伺服器從而達到在保持數據一直性前提下的真正的負載平衡。
上述所有技術在實際部署系統的時候可以混合使用以達到最佳效果。
2）提高資料庫可用性的技術
根據物理法則，提高冗餘度是提高資料庫可用性的唯一途徑。
提高資料庫冗餘度大致有四種方法：
◆ 硬體級的冗餘：主要思想是讓多處理機同時執行同樣的任務用以屏蔽瞬時和永久的硬體錯誤。有兩種具體的實現方法：構造特殊的冗餘處理機和使用多個獨立的資料庫伺服器。冗餘處理機的造價昂貴，效益很低。實際應用日漸減少。基於資料庫的集群系統都是用多個獨立的資料庫伺服器來實現一個邏輯資料庫，在任意瞬間，每台處理器運行的都是不同的任務。這種系統可以屏蔽單個或多個伺服器的損壞，但是因為沒有處理的冗餘度，每次恢復的時間比較長，它們需要把被損壞的服務進程在不同的伺服器上從新建立起來。ICX讓多個獨立的資料庫伺服器作同樣的處理。發現處理器問題時的切換不需要重建進程的狀態，所以故障屏蔽是極快的。
◆ 通訊鏈路級的冗餘：冗餘的通訊鏈路可以屏蔽瞬時和永久的通訊鏈路級的錯誤。基於資料庫引擎的集群系統有兩種結構：共享磁碟和獨立磁碟。RAC, MSCS 和 MySQL CS可以認為是共享磁碟的集群系統。UDB和ASE 是獨立磁碟的集群系統。共享磁碟集群系統對網路系統的要求很高，所以通訊的冗餘度最小。獨立磁碟集群系統可以把磁碟系統獨立管理，通訊冗餘度較高。 ICX的通訊鏈路級的冗餘度最高，因為它使用的是多個獨立的資料庫伺服器和獨立的磁碟系統。 ICX也可以用於共享磁碟系統。 但是冗餘度會相應降低。
◆ 軟體級的冗餘：由於現代操作系統和資料庫引擎的高度並發性，由競爭條件、死鎖、以及時間相關引發的錯誤占據了非正常停機服務的絕大多數原因。採用多個冗餘的運行資料庫進程能屏蔽瞬時和永久的軟體錯誤。基於資料庫引擎的集群系統都用多個處理器來實現一個邏輯資料庫，它們只能提供部分軟體冗餘，因為每一瞬間每個處理器執行的都是不同的任務。只有ICX可以提供最大程度的軟體級冗餘。
◆ 數據冗餘：有兩類冗餘數據集。
被動更新數據集：所有目前的數據復制技術(同步或非同步)，例如磁碟鏡像（EMC的TimeFinder系列）、資料庫文件復制（如DoubleTake, Veritas and Legato）以及資料庫廠商自帶的資料庫備份工具都只能產生被動復制數據集。通常，為了實現復制功能，需要消耗掉主伺服器5%（非同步）到30%（同步）的處理能力。被動更新的數據一般只用於災難恢復.被動更新數據集還有兩個致命的問題：一旦主處理機故障造成數據損壞，被動更新的數據集也會被破壞。另外，和主動更新系統相比，被動更新系統對數據網路的帶寬要求更高。這是因為它缺少交易的信息，很多數據復制是盲目的。
主動更新數據集：這種數據集需要一台（或多台）獨立的備份資料庫伺服器來管理，由於這種數據集及時可用，它可以有多種用途，例如報表生成，數據挖掘，災難恢復甚至低質量負載均衡。 同樣地，這里也有同步和非同步兩種技術。
◆ 非同步主動復制數據集：這種技術是先把事務處理交給主伺服器來完成，然後這些事務處理再被串列地交給備份伺服器以執行同樣的操作來保證數據的一致性。這種技術生成的數據集和主數據集有一個時間差，所以僅適用於災難恢復、數據挖掘、報表統計以及有限的在線應用。所有的商用資料庫都支持非同步主動復制技術。這種辦法的難度在於復制隊列的管理上，這個隊列是用來屏蔽主伺服器和備份伺服器之間的速度差異的。因為主伺服器可以盡可能地利用所有軟硬體的並發性來處理並發的事務，而備份伺服器只能串列地復制，在高負荷事務處理的情況下，復制隊列經常可能溢出。因為沒有任何辦法來控制事務處理請求的速度，在高負荷事務處理的情況下，復制隊列只能經常性地重建。因為所有現代資料庫系統都支持熱備份和LOG SHIPPING。通過精心策劃，應該可以實現不關閉主伺服器而重建隊列。ICX也支持非同步主動復制. ICX的復制隊列的重建是通過ICX的自動數據同步軟體來完成的，所以不需要人工操作。
◆ 同步主動復制數據集：這種技術要求所有的並發事務處理在所有的資料庫伺服器上同時完成。一個直接的好處就是沒有了隊列的管理問題，同時也可以通過負載均衡實現更高的性能和更高的可用性。這種技術也有兩種完全不同的實現方法：完全串列化和動態串列化。完全串列化的事務處理來自於主資料庫的事務處理引擎，RAC, UDB, MSCS (SQL Server 2005) 和 ASE是用完全串列化並結合兩階段提交協議來實現的，這種設計的目標就是為了獲得一份可用於快速災難恢復的數據集。這種系統有兩個關鍵的問題。第一，兩階段提交協議是一種「ALL OR NOTHING」的協議。仔細研究兩階段提交協議後就能發現，為了獲取這備份數據集，事務處理的可用性會降低一半。第二，完全串列化的做法又引進了主-從資料庫伺服器速度不匹配的問題。強制同步造成整個系統的速度被降低到完全串列化的水平。相反，ICX-UDS採用了動態串列復制引擎。這設計可以充分利用多個獨立資料庫的處理能力。ICX避免了使用兩階段提交協議，因此一個事務處理只有在集群中的所有伺服器全都同時崩潰的情況下才會回滾。
為了防災，必須使用遠程網路。 所以我們在這里討論遠程數據復制的辦法。這里大概有四種辦法。
◆ 動態遠程非同步復制：這種辦法是指主伺服器通過遠程網串列地把交易復制到備份伺服器上。由於主-副之間的速度不匹配，隊列管理的問題就很突出。 由於遠程網的速度一般都比較慢，隊列溢出的概率大大增加。所有的集群系統都支持這種復制辦法，只是隊列管理的辦法不同而已。DM，FM和RAID都不能支持這種辦法。RAID只能在區域網內工作。
◆ 動態遠程同步復制.：這種辦法是指主伺服器通過遠程網並行地把交易復制備份伺服器上。只有ICX 具有這種能力。
◆ 靜態遠程非同步復制.：這種辦法是指通過遠程網把數據串列地復制（不通過資料庫伺服器）到異地。DM和FM支持這種復制辦法。因為串列處理和隊列管理的關系，這對於處理量大的系統不適用。但是這種復制辦法對應用是透明的，所有集群系統都可採用.
◆ 靜態遠程同步復制.：這種辦法也是指通過遠程網把數據串列地復制（不通過資料庫伺服器）到異地。不同的是，這里沒有隊列管理。取代隊列管理的是發送端的一個新的協議：每次發送都要等接受端確認復製成功。否則回滾。DM和FM都支持這種復制辦法。這種辦法只能在短距離范圍內工作， 大約5 英里光纖的樣子。如果超出這個距離范圍的話，顯然事務處理回滾的概率就會很高。但是這種復制辦法對應用是透明的，所有集群系統都可採用。
3）提高資料庫安全和數據集可擴展的技術
在提高資料庫安全性和數據集可擴性這兩方面，可以創新的空間是很小的。資料庫最常見的安全辦法是口令保護，要麼是分布式的，要麼是集中式的。在資料庫前面增加防火牆會增加額外的延遲，因此，盡管許多安全侵犯事件是來自於公司內部，但是資料庫防火牆還是很少被採用。如果資料庫集群技術是基於中間件技術實現的，就有可能在不增加額外延遲的情況下 ，在數據經過的路徑上實現防火牆功能。ICX完全實現了這種思想。
資料庫數據集的可擴性只能通過將數據分布到多個獨立的物理伺服器上來實現。為了彌補可用性的損失，ICX能被用來提高整個邏輯資料庫或者部分重要伺服器的處理速度，可用性和安全性。
4. 怎樣實現資料庫負載均衡集群
集群系統的概要
現在的計算機社會中，持續的提供不停止的服務已經成為通往成功的關鍵。例如僅由於 1
台機器故障或超負荷而宕機就導致對客戶的服務全面停止。這樣的話，不但會帶來莫大的
損失，還會失去客戶的信任。
隨著集群系統的導入，發生意外事故時會將系統停止時間(宕機時間)降低到最小限度、使
負載均衡，提高其可用性。
所謂集群，有「集團」、「團」的意思，顧名思義是「將多個計算機匯集成一群(或者多群)，謀求
提升可靠性及處理性能的系統」。集群系統有多個種類，可分為下列3 種。其中，
NEC ExpressCluster 屬於High Availability 集群。
HA (High Availability) 集群
是平時作為運行伺服器作業，在運行伺服器發生故障時將業務交接到待機伺服器的集
群。是以高可用性為目的的集群。包括共享磁碟型、鏡像磁碟型。
負載均衡集群
是將客戶端的請求遵從恰當的負荷均衡原則分配給各節點的集群。是以高擴展性為目
的的集群、一般無法進行數據交接。包括load balance 集群、並列資料庫集群。
HPC (High Performance Computing)集群
是指計算量非常大的集群。是為使用超級計算機執行單一業務的集群。使用所有節點
的CPU 來執行單一業務的網格計算技術近年來已成為熱點。
5. 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求
來具體說說資料庫集群吧
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)
1、高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如」雙機熱備」, 「雙機互備」, 「雙機」。高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。
2、負載均衡集群(Load Balance Cluster)
負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。
負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。
3、科學計算集群(High Performance Computing Cluster)
高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。
高性能計算分類：
3.1、高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。
這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。
所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。
3.2、分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。
下面說說這幾種集群的應用場景：
高可用集群這里不多作說明。
想Dubbo是比較偏向於負載均衡集群，用過的猿友應該知道（不知道的可以自行了解一下），Dubbo同一個服務是可以有多個提供者的，當一個消費者過來，它要消費那個提供者，這里是有負載均衡機制在裡面的。
搜索引擎Elasticsearch比較偏向於科學計算集群的分布計算。
而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。
我們以Dubbo為例：
集群容錯（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）
Dubbo提供了這些容錯策略：
集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展
Failover Cluster
失敗自動切換，當出現失敗，重試其它伺服器。(預設)
通常用於讀操作，但重試會帶來更長延遲。
可通過retries="2"來設置重試次數(不含第一次)。
Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。
通常用於非冪等性的寫操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。
通常用於寫入審計日誌等操作。
Failback Cluster
失敗自動恢復，後台記錄失敗請求，定時重發。
通常用於消息通知操作。
Forking Cluster
並行調用多個伺服器，只要一個成功即返回。
通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks="2"來設置最大並行數。
Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一台報錯則報錯。(2.1.0開始支持)
通常用於通知所有提供者更新緩存或日誌等本地資源信息。
負載均衡（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）
Dubbo提供了這些負載均衡策略：
Random LoadBalance
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。
RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒掛，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。
LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。
ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。
當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
演算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
預設只對第一個參數Hash，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />
預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />
6. 如何重啟集群的資料庫
關閉：
srvctl stop instance -d orcl -i orcl1
srvctl stop instance -d orcl -i orcl2
啟動：
srvctl start instance -d orcl -i orcl1
srvctl start instance -d orcl -i orcl2
以上命令假設你的資料庫名為orcl，實例名分別為orcl1,orcl2