PXC的原理

http://www.blogs8.cn/posts/AWif6E4mariadb的集群也是抄percona的，原理跟PXC一样maridb-cluster就是PXC，原理是一样的。codeship

大家好，我是架构君，一个会写代码吟诗的架构师。今天说一说PXC的原理,希望能够帮助大家进步!!!

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就消失了

今天文章到此就结束了，感谢您的阅读，Java架构师必看祝您升职加薪，年年好运。