http://www.blogs8.cn/posts/AWif6E4
mariadb的集群也是抄percona的，原理跟PXC一樣
maridb-cluster就是PXC，原理是一樣的。
codeship這個公司
已經被Percona收購了
PXC的原理
PXC會使用大概是4個端口號
3306 數據庫對外服務的端口號
4444 請求SST SST: 指數據一個鏡象傳輸 xtrabackup , rsync ,mysqldump
4567 : 組成員之間進行溝通的一個端口號
4568 : 傳輸IST用的。相對於SST來說的一個增量。
安裝PXC過程中
iptables 禁掉
selinux 也禁掉
傳統復制流程
異步
半同步 超過10秒的閥值會退化為異步
不管同步或是半同步，都存在一定的延遲
PXC怎么做到不延遲呢
PXC最大的優勢
強一致性
無同步延遲
每一個節點都可以讀寫
WriteSet寫的集合
用箱子推給Group里所有的成員， data page 相當於物理復制，而不是發日志
就是一個寫的結果了
用戶發起Commit，在收到Ok之前
集群每次發起一個動作，都會有一個唯一的編號
PXC獨有的Global Trx Id
動作發起者: commit_cb
其它節點多了一個動作： apply_cb
上面的這些動作，是通過那個端號交互的？
4567
4568端口 IST 只是在節點下線，重啟加入那一個時間有用
4444 只會在新節點加入進來時起作用
pxc結構里面
如果主節點寫入過大
apply_cb 時間會不會跟不上
wsrep_slave_threads參數 解決apply_cb跟不上問題 配置成和CPU的個數相等或是1.5倍
當前節點commit_cb 后就可以返回了
推過去之后，驗證通過就行了可以返回客戶端了
cb==commit block 提交數據塊
SST和IST
State Snapshot Transfer(SST) 全量傳輸
Incremental state Transfer(IST)增量傳輸
每個節點都有一份獨立的數據
我們通過SST和IST說一下PXC的啟動關閉流程
當我們啟動第一個節點， bootstrap-pxc
當前集群沒有其它成員，你就是老大了。
在第一個節點上可以把帳號初始化， 基本初始化，都搞定了。
初始化的時間，隨便那個節點都可以。
其它節點再起來就是要加入進來的。 joining node
wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx
你是新成員，你沒有ID
第一個節點 把自已備份一下（snapshot) 傳給加入的新節點： SST
socat.x86_64
perl-IO_Socket
nc
另一個節點是死的還是活的？
這時兩個節點會進行一個投票
當第三個節點要加入的時間
wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx
給貢獻數據者
Donor
新啟動的節點-> open ->primary
4567 端口溝通
joiner 我是新加入的
joined
需要有一個人能給他提供一份全量的數據
SST 發生的者的身上就是donor
donor 需要發起innobackupex
傳輸SST有幾種方法：
1. xtrabackup
2. mysqldump mysql庫也會傳輸
3. rsync 對innodb整個庫進行鎖定來拷貝，保證一致性
如果node3 需要停一下機
reboot , 加點內存，換個硬盤的
node3 希望說能不能把增量傳給我
IST
Galera 2.X之前只能傳全量
node3能停多長時間，可以傳IST
gcache.size
wsrep_provider_options 默認128M
wsrep_provider_options="gcache.size=1G"
gid : 1000
1200 > gcache.size .id
gralea.cache
gcache.size到底分配多大合適呢
1個小時
可以算一個小時的binlog量大概多大
一般預留2-3小時，gcache.size大小2-4G
假設我們三個節點都關閉了，會發生什么呢
發現一個可怕的事情
全部傳SST
沒有做到最后關閉的節點，最先啟動
建議滾動關閉
1. node1 先閉 修復完畢
加回來了
2. 再關node2 ,修復完畢
加回來了
3. 再關node3 ,修復完畢
加回來了
原則要保持Group里最少一個成員活着
滾動升級，先升級集群里的一個節點，再下一個節點再下一個節點
Gcache 數據沒了。
數據庫關閉之后，會保存一個last Txid
node1 1000
node2 1001
node3 1002
node1 是整個集群的老大
其它節點加進來發現數據不一致，以老大為准
會有丟數據風險
所有節點全關閉了
第一個用bootstrap-pxc啟動的節點，他就為自已是老大了
第二節點加來了，還在老大的關系嗎
兄弟兩個是平起平座的
面臨一個丟數據問題
mysqld —wsrep_recover —bootstrap-pxc 使用mysqld —wsrep_recover參數啟動mysqld
—wsrep_recover
When server is started with this variable, it will parse Global Transaction ID (GTID) from log, and if the GTID is found, assign it as initial position for actual server start. This option is used to recover GTID.
[mysqld_safe]
wsrep_recover=1
wsrep_recover=on
node3 1002
node3 bootstrap-pxc
gcache 最小的GTID是多少呢
1002
node2加入 ： 1001
SST
node1加入 一樣的傳輸 SST
怎么避免gcache丟失這件事情呢
1. 所有的節點中最少有一個在線，進行滾動重啟
2. 利用主從的概念，把一個從節點轉化成PXC里的節點
PXC集群的腦裂問題
輸入任何命令都顯示unkown command
推薦是三個節點
假設變成了兩個節點
突然出現了兩集群之間連不通了
模擬
iptables Start 4567端口連不通了。
kill -9 mysqld
忽略腦裂的命令
SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";
PXC使用中的特點 和注意事項
PXC里任何節點都可以讀寫
他的ID增長順序是什么樣的
show global variables like "%auto%";
offset 是節點數
起始值有啥區別嗎
1，2，3
node1, 1 node2: 2 node3： 3 offset: 3
1,4, 7,10 node1
5, 8, 11 … node2
6, 9, 12 …. node3
跟雙主一樣，通過控制步長和起始值來避免自增主鍵沖突
update tb set col3=col3-100 where id=10;
native 處理 node1,node2, node3 理論可以同時處理這個SQL
在PXC里同時更新到同一行記錄是可能存在這個風險的
樂觀並發控制
只鎖本地的行記錄，不鎖別人的，不鎖全局，本地處理完再發給別人，那么就有可能大家同時更新同一行記錄
Error： 1213 SQLSTATE: 40001
考慮單節點寫入
DDL操作
在某成員上做DDL操作，atler table 操作時間可以長一點。
會把整個集群鎖着
ptcc做一個大表來模擬
metadata lock 搞定
在PXC結里，不可能不做表結構變更呀
解決：使用pt-online-schema-change
開發建個表告訴你數據不能復制
MyISAM引擎不能被復制，PXC只支持Innodb
mysql庫全是MyISAM人家咋復制呢
DCL語句 Create user， drop user, grant ,revoke
pxc結構里面每個表必須有主鍵
如果沒有主建，有可能會造成集群中每個節點的Data page里的數據不一樣
node1 data page 6 rows
node2 data page : 7rows
select * from tb limit 100;
不支持表級的鎖 lock /unlock tables
pxc里只能把slow log ,query log 放到File里，不能放到table里
不支持XA事務
三個節點。假設其中有一個節點 SSD，其它節點是HDD，整個集群的硬件配置要一樣
木桶理論 ：一個木桶打多少水以木桶里最短的那塊木板決定，水太多會溢出
整個集群數最好為3，最多是8個
其中一個節點死掉了，還有2個節點
發現整個集群還能活
writeSet最大是多呢
wsrep_max_ws_rows
wsrep_max_ws_size 不要超過16KB
pxc的監控
clustercheck
課后問題
1、節點下線在哪里看
答：可以在MYSQL 的Error log記錄
2、從庫啟動怎么確認傳輸的是SST還是IST
答：可以在MYSQL 的Error log里看
3、gcache是否存在
答：只在活着的機器上存在，如果整個集群掛掉，gcache就消失了