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的原理_第1张图片

 

安装PXC过程中
iptables 禁掉
selinux 也禁掉

 

 


 

传统复制流程

PXC的原理_第2张图片

 

 

 异步

PXC的原理_第3张图片

 

 

半同步 超过10秒的阀值会退化为异步

PXC的原理_第4张图片

 

 

 

不管同步或是半同步,都存在一定的延迟
PXC怎么做到不延迟呢
PXC最大的优势
强一致性
无同步延迟


每一个节点都可以读写
WriteSet写的集合
用箱子推给Group里所有的成员, data page 相当于物理复制,而不是发日志
就是一个写的结果了

 

 

 

 

 

 

PXC的原理_第5张图片

 

 

 

 

 

用户发起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

 PXC的原理_第6张图片

 

 

 

 

 

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

 

转载于:https://www.cnblogs.com/zengkefu/p/5678279.html

你可能感兴趣的:(PXC的原理)