資料庫的集群配置
『壹』 資料庫集群是什麼
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( 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" />
『貳』 資料庫集群
拿oracle為例：
集群是多台伺服器共同提供服務，資料庫集群的意思就是多台運行資料庫服務的伺服器組成一個集群。
oracle的集群，自己的是rac，最少需要2台機器，先裝cluster或者grid，再在集群上安裝資料庫，就可以了。
要是db2的話，還得用ibm的操作系統，安裝一個集群軟體
hacmp等等的。
反正
核心要理解的就是
，做集群，要有集群系統來支撐。例如
，文件同步訪問等等的。
rac，hacmp等等的，都屬於集群系統！
『叄』 如何在Windows系統中配置Mysql群集
MySQL 群集是一種技術，該技術允許在無共享的系統中部署「內存中」和「磁碟中」資料庫的 Cluster 。通過無共享體系結構，系統能夠使用廉價的硬體，而且對軟硬體無特殊要求。此外，由於每個組件有自己的內存和磁碟，不存在單點故障。MySQL Cluster 由一組計算機構成，每台計算機上均運行著多種進程，包括 MySQL 伺服器，NDB Cluster 的數據節點，管理伺服器，以及（可能存在的）專門的數據訪問程序。
管理伺服器(MGM節點)負責管理 Cluster 配置文件和 Cluster 日誌。Cluster 中的每個節點從管理伺服器檢索配置數據。當數據節點內出現新的事件時，節點將關於這類事件的信息傳輸到管理伺服器，然後，將這類信息寫入 Cluster 日誌。
目前能夠運行 MySQL Cluster 的操作系統有 Linux、Mac OS X 和 Solaris，最新的版本已經支持 Windows 操作系統。
MySQL 群集的數據節點之間的通信是不加密的，並且需要高速的帶寬，所以建議把群集建立在一個高速區域網內，不建議跨網段、跨公網的部署這種系統體系。
MySQL 群集分為三種節點：管理節點，數據節點和SQL節點。
管理節點：主要用於管理各個節點，能夠通過命令對某個節點進行重啟、關閉、啟動等操作。也能夠監視全部節點的工作狀態。
數據節點：主要是對數據的存儲，不提供其他的服務。
SQL節點：主要是對外提供SQL功能，類似一台普通的 MySQL Server。
而SQL節點和數據節點可以是同一台機器，也就是說這台機器即是SQL節點也是數據節點。它們只是邏輯關繫上的劃分，實際部署時，甚至所有的階段都可以位於同一台物理機器上，只是配置較復雜些。
一、軟體下載機器操作環境
配置 MySQL 群集必需使用其群集版本，注意和 MySQL Server 版本的區別。本文以 Windows 平台下的 MySQL 群集版本 MySQL Cluster 7.1.3 為例（截至2010年6月初的最高版本），這是 MySQL Server 5.1 系列版本之一，添加了群集的功能。下載地址為：http://dev.mysql.com/downloads/cluster，選擇 mysql-cluster-gpl-noinstall-7.1.3-win32.zip 文件，這是一個 for Windows 32位版本的、免安裝的二進製版本。
根據自己的操作系統的位數，也可以選擇 64 位版本的。還有一個 27.2M 的 Windows(x86, 32-bit) 版本，下載下來需要自己編譯，有經驗的高級用戶可以選用。
本實驗在 2 台安裝 Windows Server 2003(sp2) 的機器上進行。節點分配及 IP 配置如下：
第一台機器，IP 為 10.0.0.201，作為管理節點(MGM)，SQL節點1(SQL1)，數據節點1(NDBD1)。
第二台機器，IP 為 10.0.0.202，作為SQL節點2(SQL2)，數據節點2(NDBD2)。
管理節點最好不要與數據節點部署在同一台伺服器上，否則可能會因為該數據節點伺服器的當機，而導致管理節點伺服器的問題，從而導致整個群集系統的崩潰。
二，配置管理節點：
在第一台機器上，建文件夾 D:\mysql-cluster，在其下建立文件 config.ini，內容如下：
[NDBD DEFAULT]
NoOfReplicas=1
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]
# Managment Server
[NDB_MGMD]
hostname=10.0.0.201
# Storage Engines
[NDBD]
hostname=10.0.0.201
datadir= D:\data
[NDBD]
hostname=10.0.0.202
datadir= D:\data
# SQL Engines
[MYSQLD]
hostname=10.0.0.201
[MYSQLD]
hostname=10.0.0.202
Cluster 管理節點的默認埠是1186，數據節點的默認埠是 2202。從 MySQL 5.0.3開始，該限制已被放寬，Cluster 能夠根據空閑的埠自動地為數據節點分配埠。如果你的版本低於5.0.22，請注意這個細節。
Cluster 管理節點作為一個服務端(通過運行 db_mgmd.exe 程序讀取本配置文件來啟動)，通過本機上的客戶端 ndb_mgm.exe 來連接和操作。
三、配置 MySQL 資料庫伺服器：
在2台機器上，分別依次操作。
解壓 mysql-cluster-gpl-noinstall-7.1.3-win32.zip 文件到 D:\mysql-cluster-gpl-noinstall-7.1.3-win32 文件夾下，把 D:\mysql-cluster-gpl-noinstall-7.1.3-win32\bin 加到 Windows 的系統 path 中。
打開DOS命令行窗口（配置完系統path後，在再次打開新的命令行窗口），執行以下語句，讓 MySQL 作為 Windows 服務運行：
mysqld.exe -install mysql
再在 Windows 服務管理界面里，配置 mysql 服務，手動啟動（不要自動啟動）。
把 D:\mysql-cluster-gpl-noinstall-7.1.3-win32 下的某個備用的配置文件（例如my-small.ini）復制為 my.ini 文件。
建立 D:\tmp 文件夾。
四、配置SQL節點和數據節點：
在2台機器上，分別依次操作。
建立文件夾 D:\data。
編輯 NySQL 配置文件 D:\mysql-cluster-gpl-noinstall-7.1.3-win32\my.ini，在 [mysqld] 節末尾加語句：
#SQL群集節點
ndbcluster
ndb-connectstring=10.0.0.201
有了 ndbcluster 語句，mysql 服務將作為群集的 SQL 節點啟動。mysqld.exe 命令帶參數 –ndbcluster 運行是一樣的效果。
mysql 服務連接到數據節點的 2202 默認埠，或自動分配的別的可用埠。
（問題：SQL節點如何獲得數據節點的IP地址？是否通過連接管理節點，取得所有數據節點的IP地址的列表？）
這里的連接字元串的值在 MySQL 服務啟動時使用，用於連接到管理節點。
在末尾加語句：
#NDB集群節點
[mysql_cluster]
ndb-connectstring=10.0.0.201
註：好像以下形式也可：
[ndbd]
ndb-connectstring=10.0.0.201
這里的連接字元串的值在數據節點啟動時使用，用於連接到管理節點。
五，啟動群集各伺服器
啟動順序依次是：管理節點、數據節點、SQL節點。
1，啟動管理節點
在第一台伺服器的DOS窗口，運行命令：
C:\>ndb_mgmd.exe -f d:\mysql-cluster.conf\config.ini –configdir=d:\mysql-cluster
註：如果不帶 –configdir=d:\mysql-cluster 參數，將默認為 C:\mysql\mysql-cluster 文件夾。
屏幕顯示：
C:\>ndb_mgmd.exe -f d:\mysql-cluster.conf\config.ini –configdir=d:\mysql-cluster
2010-06-10 01:16:57 [MgmtSrvr] INFO — NDB Cluster Management Server. mysql-5.1.44 ndb-7.1.3
2010-06-10 01:16:57 [MgmtSrvr] INFO — Reading cluster configuration from 『d:\mysql-cluster.conf\config.ini'
2010-06-10 01:16:57 [MgmtSrvr] INFO — Got initial configuration from 『d:\mysql-cluster.conf\config.ini', will try to set it when all ndb_mgmd(s) started
2010-06-10 01:16:57 [MgmtSrvr] INFO — Mgmt server state: nodeid 1 reserved for ip 10.0.0.201, m_reserved_nodes 1.
2010-06-10 01:16:57 [MgmtSrvr] INFO — Id: 1, Command port: *:1186
==INITIAL==
2010-06-10 01:16:57 [MgmtSrvr] INFO — Starting initial configuration change
2010-06-10 01:16:57 [MgmtSrvr] INFO — Configuration 1 commited
2010-06-10 01:16:57 [MgmtSrvr] INFO — Config change completed! New generation: 1
==CONFIRMED==
2，啟動數據節點
分別在2台伺服器的DOS窗口運行命令。
第一次，或初始化群集節點時，運行命令：
ndbd.exe –initial
初始化之後，只運行 ndbd.exe 即可。若帶參數 –initial 運行，將使正常運行的群集系統中，數據節點的數據全部丟失。
數據節點依賴管理節點伺服器，進行數據的自動復制和同步，使各個數據節點的數據保持一致，並在某個數據節點意外關閉又恢復後，進行數據的恢復重建。
3，啟動SQL節點
有了 ndbcluster 語句，啟動 mysql 服務，就啟動了SQL節點。應在前2種節點啟動後，分別在2台伺服器上進行。
六、群集管理
在所有的數據節點和SQL節點未啟動之前，運行群集管理節點服務的客戶端 ndb_mgm.exe，只能獲得以下信息：
C:\>ndb_mgm.exe
— NDB Cluster — Management Client –
ndb_mgm> show
Cluster Configuration
———————
[ndbd(NDB)] 2 node(s)
id=2 (not connected, accepting connect from 10.0.0.201)
id=3 (not connected, accepting connect from 10.0.0.202)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @10.0.0.201 (mysql-5.1.44 ndb-7.1.3)
[mysqld(API)] 2 node(s)
id=4 (not connected, accepting connect from 10.0.0.201)
id=5 (not connected, accepting connect from 10.0.0.202)
ndb_mgm>
說明數據節點、SQL節點均未連接到管理節點服務。
在所有的數據節點和SQL節點正確啟動之後，將獲得以下信息：
ndb_mgm> show
Cluster Configuration
———————
[ndbd(NDB)] 2 node(s)
id=2 @10.0.0.201 (mysql-5.1.44 ndb-7.1.3, Nodegroup: 0, Master)
id=3 @10.0.0.202 (mysql-5.1.44 ndb-7.1.3, Nodegroup: 1)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @10.0.0.201 (mysql-5.1.44 ndb-7.1.3)
[mysqld(API)] 2 node(s)
id=4 @10.0.0.201 (mysql-5.1.44 ndb-7.1.3)
id=5 @10.0.0.202 (mysql-5.1.44 ndb-7.1.3)
ndb_mgm>
關閉群集的DOS命令：
ndb_mgm -e shutdown
或在 ndb_mgm 環境下執行 shutdown 命令。
以上命令或關閉管理節點服務和所有的數據節點。隨意、強行關閉群集系統（關機或關閉進程），會導致數據沒有全部寫回磁碟而導致的數據丟失。
關閉SQL節點的 mysqld 服務：
C:\>net stop mysql，或：
C:\>mysqladmin -u root shutdown
七、測試
正常運行的 MySQL 群集系統，通過SQL節點可以對數據節點進行資料庫操作，各數據節點可以自動進行數據同步。某一個數據節點關閉後，不影響SQL節點的使用。某些數據節點出錯後，可以進行恢復。需要注意的是，SQL節點建立資料庫時，必須選擇「ndbcluster」資料庫引擎。如果不選擇「ndbcluster」引擎，建立的資料庫將不會進入MySQL群集系統中，但是可以獨立使用。
另外，每個 NDB 表必須有一個主鍵。如果在創建表時未定義主鍵，NDB Cluster 存儲引擎將自動生成隱含的主鍵。該隱含的鍵也將佔用空間，就像任何其他的表索引一樣。由於沒有足夠的內存來容納這些自動創建的鍵，出現問題並不罕見。
『肆』 如何配置MySQL集群在一台伺服器
-+-+-+-+-+-+-+-+-+-+-+-
-+-+mysql的主從配置+-+-
-+-+-+-+-+-+-+-+-+-+-+-
#############################################################################
常用命令
1.安裝一個mysqld服務
mysqldinstall
2.開啟mysql服務關閉mysql服務
netstartmysqlnetstopmysql
2.開啟一個mysql的3307埠
命令行進入解壓目錄in目錄下
解壓目錄in>mysql-uroot-p-P3307-h127.0.0.1
-u用戶名
-p密碼
-P埠
-h網址
#啟動從庫
Startslave
#停止從庫
Stopslave#############################################################################
開始
用一台電腦測試
先在本電腦上安裝一個mysql（集成的也行）
解壓文件
然後解壓另一個mysql到電腦目錄
》》》》》1.
在解壓目錄創建一個mysql.ini
把一下文檔寫進去配置一個埠號為3307
#mysqld
[mysqld]
port=3307
basedir=D:mysqlsever#D:mysqlsever改成你解壓目錄
datadir=D:mysqlseverdata#D:mysqlsever改成你解壓目錄
安裝一個mysqld服務mysqldinstall
開啟mysql服務netstartmysql
不能正常啟動請查看配置
》》》》2.
#主庫3306
在命令行或者
grant許可權on資料庫對象to用戶
,RELOAD,SUPERON*.*
TOmysql_backup1@'*'
IDENTIFIEDBY'123456'withgrantoption;
flushprivileges;》》》3.
在主庫運行SHOWMASTERSTATUS//運行後查看File和Postion
如Filemysql-bin.000002Postion120
在從庫運行
CHANGEMASTERTOmaster_host='127.0.0.1',
master_user='mysql_backup',
master_password='123456',
master_log_file='mysql-bin.000001',#看上面的File從庫對照主庫寫
master_log_pos=4791;#看上面的Postion從庫對照主庫寫
如果報錯就停止就重新運行
#啟動從庫
Startslave
#停止從庫
Stopslave
在從庫運行Showslavestatus
Slave_IO_Running
Slave_SQL_Running
兩個欄位全部是是Yes基本上就成功了
測試
在主庫上建立一個表在從庫上刷新
############################################################################
『伍』 如何搭建window server 2008資料庫集群
Windowsserver2003中提供了網路負載均衡（NLB）功能。NLB的操作模式有單播和多播兩種，它們之間有什麼區別呢？首先，給大家介紹一下NLB的工作原理：當客戶向NLB群集（NLB的虛擬IP地址）發起請求時，其實客戶的請求數據包是發送到所有的NLB節點，然後運行在NLB節點上的NLB服務根據同樣的NLB演算法來確定是否應該由自己進行處理，如果不是則丟棄客戶的請求數據包，如果是則進行處理。如何將請求數據包發送到所有的NLB節點是NLB運行的關鍵之處，單播和多播這兩種操作模式就是用於實現這一需求。NLB不支持單個NLB群集中的單播/多播的混合環境；在每一個NLB群集中，該群集中的所有節點都必須配置為多播或單播，否則，此NLB群集將無法正常工作。
『陸』 簡述mysql該怎樣進行集群部署
mysql集群部署操作如下：
1、在MySQL集群中.當table引擎為NDBCLUSTER時才做集群，其他非NDBCLUSTER表和一般MySQL資料庫表一樣，不會共享數據。NDBCLUSTER表數據存儲在Data node伺服器內存中，Data Node可以為1台或多台伺服器，它們之間存放共享數據。Data Node伺服器可以分組數據。
例如：2,3,4,5為四台Data Node伺服器ID. 2,3為組0； 4，5為組1； 2，3維持數據相同，4，5維持數據相同。 組0和組1維持數據不同。
2、sql node伺服器中，非NDBCLUSTER數據存在本身資料庫中，table引擎為NDBCLUSTER時，數據存儲在Data Node中。當查詢NDBCLUSTER表時，它會從Data node集群中提起數據.
3、Manager server管理SQl node和Data node狀態。
『柒』 mysql分布式集群的搭建方案
不是很理解，比如說你3台搭建分布式，你通過什麼方式區分庫表？假設每台伺服器上部署一個mysql實例，那你怎麼把數據分布到3個mysql裡面？是每個mysql裡面存不同的表么？如果這樣，就還可以接受。這塊問題不是很大。
第二個問題，你的HA主備，意思是說兩個分布式互為主備？那怎麼備份，怎麼切換？
其實按照你想要達到的目標。應該是每兩台互做主備，形成3對主備庫，然後這3對再組建一個分布式集群。
其實和你要做的可能差不多，不過邏輯上還是有差異的。HA你准備怎麼做？keepalived？
另外，咨詢一下，你的分布式是通過什麼來實現，不同業務訪問不同的資料庫，每個庫存不同的表？還是相同的表分布在不同資料庫？
看你伺服器的配置如何，其實我覺得一般來說拿3台來做備機有點浪費，如果配置允許，可以考慮做成6套mysql主備的分布式集群。
通過交叉互備實現硬體的最大利用。下圖是我們之前用4台伺服器做的一套集群方案。
如果還有其他問題可以和我聯系。
『捌』 如何正確配置基於 oracle 資料庫的 wps v6.12 集群應用系統
本文描述了遠程消息傳遞和遠程支持集群環境的搭建配置過程。這個集群環境由三個集群組成，具體的拓撲結構是：
應用程序集群，不但為應用程序提供工作負載管理以及URL和EJB 請求故障轉移功能，而且還部署了BPC和HTM 容器，提供了對長業務流程和人工業務流程的應用程序的支持。
遠程消息集群，運行WPS默認提供的四個匯流排（SCA應用，SCA系統，BPC和CEI）提供獨立的高效的消息引擎。
遠程支持集群，部署通用事件體系結構和業務規則管理等其他應用程序，提供非同步的事件查詢。
這三個集群配置在兩台機器的不同的節點上，即三個集群的成員水平部署在兩台機器上。在一個集群中的兩個成員是該集群中完全相同的副本。消息傳遞引擎、業務支持和業務流程應用程序分別位於不同的集群上，所以可以根據實際業務負載和硬體環境，靈活調配所需的資源。這種模式，也稱為黃金拓撲，是 WPS 中最復雜的拓撲結構，是大多數企業集成應用用戶的首選，具有如下優點：
可靠性。將所有的應用、消息引擎和通用事件部署在三個集群上面，方便管理和使用。
可擴展性。因為系統中的消息引擎處於的關鍵地位，可能存在之後的訪問需求增長等擴展需要，單獨創建消息引擎集群可以很方便實行這一點。
對於系統運行時可能遇到的處理量非常大和可伸縮性等問題，通過將通用事件基礎架構（CEI）和應用程序分離，可以確保這兩個組件不會爭用相同的資源（內存和CPU）。此拓撲還能幫助創建集中的事件伺服器以處理來自多個源的事件。
所有的應用伺服器由 Deployment Manager 統一管理，降低了系統管理的復雜度。
安裝前的注意事項
在集群環境的安裝過程中，需要同步兩台主機的信息，確保它們之間能夠良好的通信。主要同步的信息包括兩台主機的系統時間、時區設置，並確保兩台機器的時間差在5分鍾之內，如果時間差超過5分鍾，聯合操作將失敗。
更新兩台主機的hosts 文件（默認目錄為/etc/hosts ），確保每台機器均包含對方的host name 和對應的IP 地址，以便主機間的相互訪問。
在使用向導安裝和配置概要時，請按照從上到下的順序輸入配置參數，對於WPS V6.12 ，輸入順序的改變有可能導致未知錯誤。
集群環境的搭建步驟
Informix 資料庫規劃
WPS的集群環境需要後台資料庫的支持。為了提高集群在實際運行中的效率，建議根據功能的不同，創建不同的資料庫。資料庫的詳細信息如下表所示：
資料庫名稱 說明
WPRCSDB 公共資料庫
EVENT 通用事件體系結構資料庫
CEIDB 通用事件體系結構消息傳遞引擎資料庫
SCASYSDB 服務組件系統消息傳遞引擎資料庫
SCAAPPDB 服務組件應用程序消息傳遞引擎資料庫
BPCDB 業務流程編排器資料庫
BPCME 業務流程編排器消息傳遞引擎資料庫
OBSVRDB 業務流程編排器事件收集器資料庫
注意：本文選擇英文語言的資料庫安裝。如果要安裝中文語言的資料庫，請參考本文的：在數據源定製屬性中添加資料庫語言。
安裝WPS的步驟
首先使用圖形化安裝向導在兩台主機上分別安裝WPS v6.1.2 產品，。在安裝產品和搭建集群過程中，步驟如下：
1.選擇「Typical installation」安裝類型。典型安裝也稱為完全安裝，提供了環境的初始化定義，包括通過概要管理工具創建特定了類型的概要文件。
圖2 選擇安裝類型
2.在選擇概要類型界面提供了四種可選擇的概要類型（圖3）。我們選擇「None」，即不創建任何類型的概要，以便在以後的步驟中手動創建概要。
使用Profile Management Tool（PMT） 創建Deployment Manager 概要
Deployment Manager（DM）是管理控制節點，它對集群環境下的所有節點提供了圖形化的管理功能。一個集群環境中一般只需要一個管理概要。下面我們將向您講述創建DM 概要的主要步驟：
1. 在<WPS_HOME>/bin/ProfileManagement/ 下執行命令pmt.sh ，彈出安裝界面。在各種類型的環境選項中選擇 WPS，進入下一步。
2. 在概要類型中提供了三種典型的概要類型，選擇 Deployment manager profile，搭建DM 概要。
3. 在創建方式界面中，默認選項為創建典型的概要文件，在此需要選擇 Advanced profile creation，以便我們在後續步驟中通過管理控制台手動進行集群配置，以滿足特定環境的需求。
4. 填寫要創建的Deployment manager profile的名稱和安裝目錄。
5. 填寫概要的Node Name和Cell name ，指定 Host Name。
6. 在管理安全選項中，如果選中 Enable administrative security 選項，請記住 WPS v 6.1.2
用戶名稱和密碼。這里建議取消 Enable administrative security 選項，不設置安全管理。在後續步驟中可以根據需要手動啟動安全管理選項，設定用戶名密碼。
7. 配置伺服器的埠。
8. 進行資料庫的配置。首先從 Choose a database proct 選擇 Informix Dynamic Server 作為公共資料庫類型，並選擇 Use an existing database。另外，需要指定 Database name，本例中使用先前創建的資料庫 WPRCSDB。不選擇「Deplay execution of database scripts for new or existing database」選項，因為概要文件的安裝過程中會自動創建資料庫 WPRCSDB 中的表。注意：如果創建的資料庫為中文字元集，則需要選擇 「Deplay execution of database scripts for new or existing database「選項，在概要創建完成後，手動執行創建資料庫表（請參考本節內容中的步驟 11）。
9. 在資料庫配置的第2步，需要對 Common DB 參數進行配置。如果是遠程資料庫，則在填寫 Database server host name時，要確保遠程資料庫的host name 已經添加到本地主機（參考本文的第三部分內容「安裝前的注意事項」）；也可以直接在該項填寫遠程資料庫的IP 地址。換句話說，在點擊下一步之前，請確認資料庫的參數信息，否則將在點擊下一步後，會收到不能連接資料庫的錯誤提示。
10. 完成以上步驟後，系統會顯示概要的創建信息。如果發現參數需要調整可以後退向導重新進行輸入。DM 創建成功後，可取消選擇 Launch the First steps console和Create another profile，點擊完成。至此，Deployment Manager 創建完成。如果創建DM 失敗，請查看 <WPS_HOME>/logs/manageprofile 目錄下的日誌文件進行分析。
11. 另外，如果需要手工創建Common DB(WPRCSDB) 相關的表，可執行DM 概要創建生成的資料庫腳本，默認目錄為：
<WPS_HOME>/profiles/Dmgr01/dbscripts/CommonDB/Informix/WPRCSDB 。
請將這些腳本復制到 Informix 資料庫所在機器，並設置如下環境變數：
INFORMIXSERVER=<IFX_INSTANCENAME>
INFORMIXDIR=<IFX_INSTALL_HOME>
之後執行如下命令：
dbaccess – createDatabase_CommonDB.sql
如果WPRCSDB已經創建，可以忽略。
dbaccess WPRCSDB createTable_AppScheler.sql
dbaccess WPRCSDB createTable_CommonDB.sql
dbaccess WPRCSDB createTable_customization.sql
dbaccess WPRCSDB createTable_lockmanager.sql
dbaccess WPRCSDB createTable_mediation.sql
dbaccess WPRCSDB createTable_Recovery.sql
dbaccess WPRCSDB createTable_RelationshipMetadataTable.sql
dbaccess WPRCSDB createTable_EsbLoggerMediation.sql
dbaccess WPRCSDB insertTable_CommonDB.sql
使用PMT 創建自定義概要
接下來，我們手動進行自定義概要的創建。這樣，能夠在創建概要過程中，根據客戶特定的使用需求和環境特點，選擇適合於自己的資料庫，並進行埠、用戶名、密碼等信息的設置。
在創建自定義概要（Custom profile）之前啟動 DeploymentManager（DM）概要，在目錄<WPS_HOME>/profiles/Dmgr01/bin 下，運行startManager.sh 命令。節點概要的創建與 DM 概要的創建類似，在目錄<WPS_HOME>/bin/ProfileManagment 下執行命令pmt.sh，隨即獲得安裝界面，主要步驟如下。
1．選擇 Create 即創建一個新的概要文件。
2．在環境選項中，選擇 WPS，進入下一步。
3．在創建概要的類型中，選擇 Custom Profile，創建一個自定義節點概要。
4．在安裝類型選項中，選擇 Advanced profile creation，以便在後續步驟中通過手動配置相關參數，定製特定的節點概要。
5．輸入節點所對應的DM 概要的主機名稱和埠，默認埠為8879。如果在創建DM時啟動了管理安全性，則需要輸入用戶名和密碼。Federate this node later 選項的選擇取決於是否要在創建節點的同時將其聯合到指定的DM 概要中。這里，我們不選擇該選項，節點會自動與 DM 概要聯合，需要注意的是，要確保 DM 概要此時為啟動狀態。
若選擇創建節點之後手動聯合到 DM 概要中，則需要在創建節點完成後使用<WPS_HOME>/Custom01/bin 目錄下的addNode.sh 命令進行節點與 DM的手動聯合，具體命令如下：
addNode.sh dmgr_hostname<–username username –password password>
6．輸入DM的信息後，進入埠設置頁面，可以自行修改埠號。
7．在資料庫選項中選擇 Informix Dynamic Server 作為資料庫類型，並為Informix JDBC driver 指定正確的路徑。該路徑指向節點所在的本地機器上 ifxjdbc.jar和ifxjdbcx.jar的存儲位置。
8．瀏覽匯總信息無誤後，點擊 Create 開始創建自定義概要。
9．創建成功後，重復以上步驟為另一台機器創建自定義概要。
命令行方式創建Deployment Manager 實例和託管節點實例
創建DM profile 和Custom profile時，除了使用pmt.sh 命令外，還可以選擇命令行方式，即執行<WPS_HOME> /bin/manageprofiles.sh 命令創建概要。創建Deployment manager 概要的命令和腳本如下：
./manageprofiles.sh –create -dbServerPort 8002
–templatePath <WPS_HOME>/profileTemplates/dmgr.wbiserver
–profileName Dmgr01
-dbDelayConfig true –dbCommonForME false
–dbType INFORMIX –dbHostName aix235.cn.ibm.com
–dbInstance IFXTest –hostName aix235.cn.ibm.com
–enableAdminSecurity false –dbName wprcsdb
–dbPassword informix –ndtopology false
-cellName aix235Cell01 –nodeName aix235CellManager01
–dbJDBCClasspath /opt/jdbc/lib –dbUserId Informix
–dbCreateNew false –profilePath <WPS_HOME>/profiles/Dmgr01
創建自定義節點的命令和腳本如下：
./manageprofiles.sh –create –dmgrHost 9.186.111.234
–profileName Custom01 –templatePath <WPS_HOME>/profileTemplates/managed.wbiserver
–dbType INFORMIX –ndtopology false
–cellName aix234Node01Cell –hostName aix234.cn.ibm.com
–nodeName aix234Node01 –dbJDBCClasspath /home/jdbc/lib
–dmgrPort 8879 –profilePath <WPS_HOME>/profiles/Custom01
『玖』 資料庫集群 應該
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( 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" />