資料庫群集

Ⅰ 資料庫集群應如何設計

上面那些全是胡說八道，什麼是資料庫設計都不懂，拿些前端的程序代碼來矇事。

沒什麼難設計的。會者不難。

不過能做這個工作的設計師薪水不低。你這樣問不知道是你在做這個，還是你是相關的主管。

告訴你這些，那你的薪水拿的太容易了。

Ⅱ 資料庫集群技術有哪些

資料庫集群技術
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能被用來提高整個邏輯資料庫或者部分重要伺服器的處理速度，可用性和安全性。

Ⅲ 資料庫集群是什麼

拿ORACLE為例：
集群是多台伺服器共同提供服務，資料庫集群的意思就是多台運行內資料庫服務的伺服器組容成一個集群。
ORACLE的集群，自己的是RAC，最少需要2台機器，先裝CLUSTER或者GRID，再在集群上安裝資料庫，就可以了。
要是DB2的話，還得用IBM的操作系統，安裝一個集群軟體
HACMP等等的。
反正
核心要理解的就是
，做集群，要有集群系統來支撐。例如
，文件同步訪問等等的。
RAC，HACMP等等的，都屬於集群系統！

Ⅳ 什麼是資料庫集群

現在比較大型點的系統基本上是AP+DB的架構: AP指應用程序,DB指資料庫端
AP放在一個伺服器上,DB放在另一個伺服器上
當一個系統比較大,訪問的用戶數量比較多的時候,比如QQ,上億用戶.

這時一個伺服器就吃不消了,這樣就想到多個伺服器跑同一個AP應用.
DB端也一樣.
linux集群 指的就是多個伺服器跑同一個AP應用,系統管理員的工作
資料庫集群 指的就是多個伺服器跑同一個DB資料庫.資料庫管理員的工作

linux集群基礎就要熟悉linux系統.
資料庫集群基礎就要熟悉具體的資料庫如oracle,db2,sysbase.mysql.等

0基礎可以學,只是要花時間.0基礎想搞到集群估計得花3個月時間.這還是要有環境的,有人指導才行.

Ⅳ 什麼是sqlserver的集群

由二台或更多物理上獨立的伺服器共同組成的「虛擬」伺服器稱之為集群伺服器。一項稱做MicroSoft集群服務(MSCS)的微軟服務可對集群伺服器進行管理。一個SQL Server集群是由二台或更多運行SQL Server的伺服器（節點）組成的虛擬伺服器。如果集群中的一個節點發生故障，集群中的另一個節點就承擔這個故障節點的責任。
認為一個SQL Server集群能夠給集群中的兩個節點帶來負載平衡，這是一種常見的誤解。雖然這似乎很有用，但卻是不正確的。這也意味著集束SQL Server不能真正提高性能。集束SQL Server只能提供故障轉移功能。故障轉移就是當系統中的一台機器發生故障失去其功能時，另一台機器將接手運行它的SQL Server實例。這種功能失效可能是由於硬體故障、服務故障、人工故障或各種其它原因。
為何要集束SQL Server環境？
在實用性方面，集群SQL Server環境令人滿意。在進行故障轉移時，將資料庫實例由一台伺服器轉移到另一台伺服器的時間非常短暫，一般只需要3至7秒鍾。雖然需要重建連接，但對資料庫的終端用戶而言，故障轉移處理通常是透明的。低廉的故障轉移成本還可幫助你對集群中的節點進行維護，而不會造成伺服器完全無法訪問。
SQL Server集群類型
一共有兩種類型的SQL Server集群：主動/被動集群和主動/主動集群。下面分別對它們進行說明（說明以兩個節點的SQL Server集群為基礎）。
主動/被動集群
在這種類型的集群中，一次只有一個節點控制SQL Server資源。另一個節點一直處於備用模式，等待故障發生。進行故障轉移時，備用的節點即取得SQL Server資源的控制權。
優點：由於伺服器上只有一個實例在運行，所以在進行故障轉移時，不需要另外的伺服器來接管兩個SQL Server實例，性能也不會因此降低。
缺點：由於虛擬伺服器上只有一個SQL Server實例在運行，另一台伺服器總是處理備用模式與空閑狀態。這意味著你並沒有充分利用你購買的硬體。
主動/主動集群
在這種類型的集群中，集群中的每個節點運行一個獨立且主動的SQL Server實例。發生節點故障時，另一個節點能夠控制發生故障節點的SQL Server實例。然後這個正常的節點將運行兩個SQL Server實例——它自己的實例和發生故障的實例。
優點：通過這種配置，你能夠充分利用你的硬體。在這樣的系統中，兩個伺服器都在運行，而不是只有一台伺服器運行，而另一台處於等待故障發生的備用模式，因此你能夠充分利用你購買的機器。
缺點：如果進行故障轉移，一台伺服器運行兩個SQL Server實例，性能就會受到不利影響。然而，性能降低總比虛擬伺服器完全失靈要強得多。這種配置的另一故障在於它要求購買的許可要比主動/被動集群多一些。因為集群在運行兩個主動SQL Server實例，這要求你購買兩個單獨的伺服器許可。在某些情況下，這也可能對你形成阻礙。
集群考慮
在高實用性方面，集群SQL Server環境有一定的優勢。然而，高實用性也確實伴隨某種折衷。
首先，建立一個集群SQL Server環境非常昂貴。這是因為集群中的節點必須遵照集群節點的兼容性列表。而且，還需要建立一個復雜的網路，機器的配置必須幾乎相同，同時需要實現資料庫文件磁碟子系統共享。存儲區網路(SAN)是建立這種子系統的不錯選擇，但SAN並非必要，而且十分昂貴。另外，如果你正在運行一個主動/主動集群，你需要為集群中運行SQL Server實例的每台機器的處理器購買一個許可。
因為當地集群主要局限於同一地理區域，自然災難可能會使集群完全失靈。在那種情況下，你需要轉移到災難恢復站點進行繼續操作。你也可以建立地理分散的SQL Server集群，但這樣的系統更加復雜與昂貴。

Ⅵ 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求

其實也可以理解成一樣，目的都是為了實現資料庫的負載均衡，高可用性。回
之間的不同要看怎麼設計了，分布答式一般是各分布節點根據哈希演算法或其他演算法分散存儲數據，意思就是所有節點的數據加起來才算是整體數據。從應用端傳過來的請求只操作涉及到的某個節點或部分節點就可完成一次請求。
資料庫集群很多設計的都是所有節點伺服器之間的數據是完全同步的。當一個應用發出請求，首先發給負載伺服器，根據應用系統提供的負載均衡演算法或是資料庫本身的負載均衡演算法，選擇一個負載最小節點來執行請求並返回數據，同時集群中還有一個同步伺服器來保證各節點中的數據一致。

總結：可以理解成一樣，而且分布式與集群設計的時候也可以一起用

Ⅶ 資料庫集群是什麼意思

現在比較大型點的系統基本上是AP+DB的架構: AP指應用程序,DB指資料庫端
AP放在一個伺服器上,DB放在另一個伺服器上
當一個系統比較大,訪問的用戶數量比較多的時候,比如QQ,上億用戶.

這時一個伺服器就吃不消了,這樣就想到多個伺服器跑同一個AP應用.
DB端也一樣.
linux集群 指的就是多個伺服器跑同一個AP應用,系統管理員的工作
資料庫集群 指的就是多個伺服器跑同一個DB資料庫.資料庫管理員的工作

linux集群基礎就要熟悉linux系統.
資料庫集群基礎就要熟悉具體的資料庫如oracle,db2,sysbase.mysql.等

0基礎可以學,只是要花時間.0基礎想搞到集群估計得花3個月時間.這還是要有環境的,有人指導才行.

Ⅷ 資料庫集群

拿ORACLE為例：

集群是多台伺服器共同提供服務，資料庫集群的意思就是多台運行資料庫服務的伺服器組成一個集群。

ORACLE的集群，自己的是RAC，最少需要2台機器，先裝CLUSTER或者GRID，再在集群上安裝資料庫，就可以了。

要是DB2的話，還得用IBM的操作系統，安裝一個集群軟體 HACMP等等的。

反正 核心要理解的就是 ，做集群，要有集群系統來支撐。例如 ，文件同步訪問等等的。

RAC，HACMP等等的，都屬於集群系統！