集群資料庫同步
1. 分布式資料庫 與 集群資料庫 之間的關系
分布式, 往往指數據被割裂, 分置不同地方
集群指, 在任何實例上, 看到的數據都是一致的.
兩者有非常大的不同.
mysql 做不了集群, 只能做分布. 可以認為你必須先知道數據在哪個mysql實例上.
2. 資料庫集群環境中，每台伺服器中數據一致嗎
如果是oracle的RAC集群的話，數據是完全一致的。
oracle的集群數據時放在共享存儲上的，三台資料庫都同時讀寫這個存儲上的數據。
通過內部機制來保證不會產生臟數據！
rac集群里的數據只有一份！是放在共享磁碟上的！
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. 兩個互信集群怎麼實時同步兩者的hbase資料庫中的數據
HBase是一個分布式的存儲系統，可以很容易在廉價PC上搭建其大規模存儲系統，用於存儲海量數據，這使得HBase適合於作為站點數據統計工具的存儲系統。
1）對於實時數據的統計，HBase能夠提供較低延遲的讀寫訪問，承受高並發的訪問請求；而對於歷史數據的統計，HBase則可以被視為一個巨大的Key-Value存儲系統，用於存儲各個網站上歷史的訪問信息，用於做離線的數據分析與報表生成。
2）對於像PV、UV、IP這樣需要求累加計算的操作（求SUM/AVG），由於要對HBase表中相關記錄進行掃描求和計算，所以如果被統計站點的數據量很大的話，使用HBase來做可能會保證不了很快的響應速度。也就是說，從前端發出一個查詢請求到最終結果的響應，時間會比較長（超過1秒或更長）。對於這個問題，將在第3節進行討論。
3）對於像站點訪客流水信息這樣的實時數據展示，則比較適合於使用HBase來做，只要我們設計了合理的key，那麼在根據key取單條訪問記錄時響應速度會很快。
下面是一個使用HBase作為存儲系統的結構示意圖：
其中，HBase服務端就是指HBase集群，應用程序分別通過入庫端與查詢端對HBase進行寫操作與讀操作。
從HBase應用角度來看，可以分為兩個不同的方向：
1）第一種方向，將HBase視為一個可靠可用的容量巨大的Key-Value存儲系統，使用HBase的作用很簡單，就是將其作為一個黑匣子來使用，按照之前設計好的表結構來存儲具有稀疏結構的數據。基於這種思路，如果HBase無法完全滿足業務的需求，就在應用程序層次做一些設計或者優化工作，以最終滿足業務的需求。
2）第二種方向，由於HBase是開源的，所以可以對HBase本身機制進行完善與擴展，最終形成一個能夠滿足業務需要的穩定可用的HBase版本。
5. sql server 2012 集群熱備 同步資料庫數據
強烈建議 ALWAYSON
不要集群了，直接用3台來做ALWAYSON 不過需要加存儲
6. 資料庫集群是什麼
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( 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" />
7. Mysql集群的數據不同步怎麼回事
這種情況是因為系統裡面已經有MySQL服務或者是MySQL埠號被佔用,可以去 計算機---管理---服務裡面MySQL服務改成手動,然後停止該服務
8. 如何實現兩個資料庫之間的表數據同步
首先你要說明一下這2個資料庫是什麼關系
資料庫集群，那麼 AB 兩庫是 鏡像 還是 互備，當然，根據資料庫 品牌不同，同步的方式也不一樣，不過都可以通過安裝過程和建立 資料庫實例中的配置 來實現
資料庫之間通過其他可控程序連接，那麼，該情況下，需要數據可能出現延遲等，不推薦
資料庫之間沒有連接，但是都由同一個節點進行數據下發，那麼就在這個節點上實現一個跨庫事物控制就行了
9. 集群資料庫讀寫分離怎麼實現數據同步
集群資料庫讀寫分離怎麼實現數據同步
讀寫分離還能理解,就是兩個資料庫,一個讀一個寫,可是寫了以後怎麼數據同步額,代碼能控制嗎
10. MySQL-redis中的數據怎樣與mysql集群數據同步
在更新MySQL的數據時候同樣更新redis來保證同步，如果要是保持數據的一致性，再增加一個刷新的功能，就是按照一定的規則重新將mysql的數據讀取出來，更新到redis中。
我一般是應用redis是作為緩存，或者一些集合運算的應用，所以同步的策略和應用cache的一樣的。