PXC原理分析

基本环境

节点1 192.168.1.114
节点2 192.168.1.115
节点3 192.168.1.116

Percona-Xtradb-Cluster 5.6 版本下载:

wget http://www.percona.com/downloads/Percona-XtraDB-Cluster-56/Percona-XtraDB-Cluster-5.6.21-25.8/binary/tarball/Percona-XtraDB-Cluster-5.6.21-rel70.1-25.8.938.Linux.x86_64.tar.gz

依赖包安装:

[[email protected] mysql3306]# yum install  perl-DBD-MySQL.x86_64 perl-IO-Socket-SSL.noarch socat.x86_64 nc -y

[[email protected] opt]# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm -y

[[email protected] opt]#yum install epel-release -y

[[email protected] mysql3306]# yum install -y percona-xtrabackup

初始化报错:

This probably means that your libc libraries are not 100 % compatible with this binary MySQL version. The MySQL daemon, mysqld, should work normally with the exception that host name resolving will not work. This means that you should use IP addresses instead of hostnames when specifying MySQL privileges !

解决办法:echo "ip 主机名" >>/etc/hosts

初始化报错:

./bin/my_print_defaults: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory
FATAL ERROR: Neither host ‘bogon‘ nor ‘localhost‘ could be looked up with
./bin/resolveip
Please configure the ‘hostname‘ command to return a correct
hostname.
If you want to solve this at a later stage, restart this script
with the --force option

解决办法:[[email protected] mysql]# yum -y install openssl098e.x86_64

[[email protected] mysql]# ./scripts/mysql_install_db 

[[email protected] mysql]# cp support-files/mysql.server /etc/init.d/mysql

第一节点启动:

[[email protected] mysql]# /etc/init.d/mysql bootstrap-pxc

[email protected]:mysql3306.sock  04:11:44 [(none)]>grant all privileges on *.* to ‘mysql‘@‘%‘ identified by ‘mysql‘;

[email protected]:mysql3306.sock  04:15:31 [(none)]>grant all privileges on *.* to ‘sst‘@‘localhost‘ identified by ‘mysql‘;

[email protected]:mysql3306.sock  04:16:18 [(none)]>flush privileges;

其他节点启动:

[[email protected] mysql]# /etc/init.d/mysql  start

检查集群状态:

show global status like “wsrep%”;

wsrep_local_state  4      #表示正常监听

wsrep_local_state_comment  Synced

wsrep_cluster_status  Primary    #表示是主节点可写入
wsrep_connected  ON

注意:
第一个节点启动的节点( 如果集群全部关闭,第一个起动也需要用这样的形式)
#/etc/init.d/mysql bootstrap-pxc
其它节点
#/etc/init.d/mysql start
备注:
如集群是不是所有的节点都关闭不用使#/etc/init.d/mysql bootstrap-pxc 启动。都可以用
#/etc/init.d/mysql start启动

新加入节点相当于新启一个节点,在启动时间把自己写入 wsrep_cluster_address 中,同时在
wsrep_node_address 中声明自已的 IP 即可。

当一个节点需要加入集群时(称为joiner)向集群申请全量,也可以指定集群中的机器:/etc/init.d/mysql start --wsrep_sst_donor=xxx.

SST:state snapshop transfer(镜像全量传输),提供SST的节点称为donor,一般不参与负载,IST:Incremental State Transfer(增量传输)。

SST,IST这些数据存放在gcache.size,默认是128M,有参数

gcache对应磁盘中galera.cache,数据库重启gcache会全部释放。

gcache分配算法:一个小时形成了多少binlog ,10分钟500M,一个小时3个G。如果说离线1个小时,就需要设置大于3个G。

[[email protected] data]# cat grastate.dat
# GALERA saved state
version: 2.1
uuid: 6dae0dc2-2834-11e6-a45a-66ae03d92d96
seqno: -1  
cert_index:

seqno-1表示已加入到集群,数据库关闭后seqno会变。

PXC不是sql层的合并,而是文件、引擎层的合并。基本没有延迟,如果设备足够快如pci-e设备,其他节点可能比主库还快。

a,b,c 三个节点

a: update tb set col1=col1+100 where id = 100;

b: update tb set col1=col1-100 where id=100;

c: update tb set col1=500 where id=100;

如果3个事物同一时间同时更新往其他节点会验证时会通过吗?

因为是本地native processing操作是乐观锁,所以他们都可以操作成功。往其他节点同步时会更新冲突,三个节点都回滚,报Error: 1213 SQLSTATE: 40001。

update,delete引起的这些问题。可以将update和delete放到一个节点解决问题。所以严格环境建议只有一个节点写,其他节点做故障接管、或读。

PXC的局限性:

1,仅仅工作在InnoDB引擎表上,因此对mysql库下的系统表的修改不能被复制,但是DDL操作时可以被复制的,所以可以通过create user、grant 等方式操作系统表

2,不支持在没有主键的表上的DELETE操作,select ... limit 也会在不同节点上返回不同的值(‘‘仅仅是在没有主键的情况下才会limit返回不同的结果集?‘‘)

3,不支持的操作: LOCK/UNLOCK TABLES、 lock functions (GET_LOCK(), RELEASE_LOCK()... )

4,query log日志不能存放在表里面,必须存放在文件

5,最大的事务大小由 wsrep_max_ws_rows、wsrep_max_ws_size定义,LOAD DATA INFILE每10k行提交一次,这种事务将被分割成数

个小的事务(‘‘XtraDB Cluster自动分割?还是操作时手动分割?‘‘)

6,由于集群是基于乐观的并发控制( optimistic concurrency control ),事务冲突的情况可能会在commit阶段发生,当多个节点修改同时同一行数据,只有其中一个节点能够成功,失败的节点将终止,并且返回死锁错误代码 Error: 1213 SQLSTATE: 40001

(ER_LOCK_DEADLOCK) (‘‘这样是否太不稳定了?动不动就会有某个节点中止挂掉的情况?而且这种情况如何处理呢?‘‘)

7,不支持XA事务,因为XA事务有可能在commit的时候出现异常发生rollback(参考http://www.infoq.com/cn/articles/xa-transactions-

handle)

8,整个集群的吞吐量/性能取决于最慢的那个节点,因为需要在所有节点上做Certification,同时还取决于节点间的网络性能,因此需要所有节点都有相同的硬件配置,并且网络、磁盘等性能要尽可能的高,例如使用SSD

9,最小建议的集群节点数为3,为解决脑裂, 最多8个节点

10. DDL语句要特别小心,建议使用pt-online-schema-change。

利用从库使用IST加入PXC集群:

保证从库没有延迟的情况下将同步和数据库关闭,配置PXC参数。记录从库同步位置然后解析binlog记录最后position点。

然后去主库(PXC节点)看最后同步position执行什么事务,找到对应xid。将主库grastate.dat拷贝到slave并修改seqno为对应的xid,最后启动mysql完成IST加入PXC集群。(建议使用mysqld_safe start  --wsrep_sst_donor=xxx。xid从这台机器来,所以要指定这个机器)

在PXC集群环境中也有uuid概念:wsrep_gcomm_uuid ,此uuid公共全局可见。(注意与binlog中记录的serverid+事物编号的GTID是两种不同的概念)。

官方文档: http://www.percona.com/doc/percona-xtradb-cluster/5.6/

时间: 2024-10-07 23:15:57

PXC原理分析的相关文章

kafka producer实例及原理分析

1.前言 首先,描述下应用场景: 假设,公司有一款游戏,需要做行为统计分析,数据的源头来自日志,由于用户行为非常多,导致日志量非常大.将日志数据插入数据库然后再进行分析,已经满足不了.最好的办法是存日志,然后通过对日志的分析,计算出有用的数据.我们采用kafka这种分布式日志系统来实现这一过程. 步骤如下: 搭建KAFKA系统运行环境 如果你还没有搭建起来,可以参考我的博客: http://zhangfengzhe.blog.51cto.com/8855103/1556650 设计数据存储格式

android脱壳之DexExtractor原理分析[zhuan]

http://www.cnblogs.com/jiaoxiake/p/6818786.html内容如下 导语: 上一篇我们分析android脱壳使用对dvmDexFileOpenPartial下断点的原理,使用这种方法脱壳的有2个缺点: 1.  需要动态调试 2.  对抗反调试方案 为了提高工作效率, 我们不希望把宝贵的时间浪费去和加固的安全工程师去做对抗.作为一个高效率的逆向分析师, 笔者是忍不了的,所以我今天给大家带来一种的新的脱壳方法——DexExtractor脱壳法. 资源地址: Dex

android脱壳之DexExtractor原理分析

导语: 上一篇我们分析android脱壳使用对dvmDexFileOpenPartial下断点的原理,使用这种方法脱壳的有2个缺点: 1.  需要动态调试 2.  对抗反调试方案 为了提高工作效率, 我们不希望把宝贵的时间浪费去和加固的安全工程师去做对抗.作为一个高效率的逆向分析师, 笔者是忍不了的,所以我今天给大家带来一种的新的脱壳方法--DexExtractor脱壳法. 资源地址: DexExtractor源码:https://github.com/bunnyblue/DexExtracto

Adaboost算法原理分析和实例+代码(简明易懂)

Adaboost算法原理分析和实例+代码(简明易懂) [尊重原创,转载请注明出处] http://blog.csdn.net/guyuealian/article/details/70995333     本人最初了解AdaBoost算法着实是花了几天时间,才明白他的基本原理.也许是自己能力有限吧,很多资料也是看得懵懵懂懂.网上找了一下关于Adaboost算法原理分析,大都是你复制我,我摘抄你,反正我也搞不清谁是原创.有些资料给出的Adaboost实例,要么是没有代码,要么省略很多步骤,让初学者

Android视图SurfaceView的实现原理分析

附:Android控件TextView的实现原理分析 来源:http://blog.csdn.net/luoshengyang/article/details/8661317 在Android系统中,有一种特殊的视图,称为SurfaceView,它拥有独立的绘图表面,即它不与其宿主窗口共享同一个绘图表面.由于拥有独立的绘图表面,因此SurfaceView的UI就可以在一个独立的线程中进行绘制.又由于不会占用主线程资源,SurfaceView一方面可以实现复杂而高效的UI,另一方面又不会导致用户输

AbstractQueuedSynchronizer的介绍和原理分析(转)

简介 提供了一个基于FIFO队列,可以用于构建锁或者其他相关同步装置的基础框架.该同步器(以下简称同步器)利用了一个int来表示状态,期望它能够成为实现大部分同步需求的基础.使用的方法是继承,子类通过继承同步器并需要实现它的方法来管理其状态,管理的方式就是通过类似acquire和release的方式来操纵状态.然而多线程环境中对状态的操纵必须确保原子性,因此子类对于状态的把握,需要使用这个同步器提供的以下三个方法对状态进行操作: java.util.concurrent.locks.Abstra

linux中mmap系统调用原理分析与实现

参考文章:http://blog.csdn.net/shaoguangleo/article/details/5822110 linux中mmap系统调用原理分析与实现 1.mmap系统调用(功能)      void* mmap ( void * addr , size_t len , int prot , int flags ,int fd , off_t offset )      内存映射函数mmap, 负责把文件内容映射到进程的虚拟内存空间, 通过对这段内存的读取和修改,来实现对文件的

Android 4.4 KitKat NotificationManagerService使用详解与原理分析(一)__使用详解

概况 Android在4.3的版本中(即API 18)加入了NotificationListenerService,根据SDK的描述(AndroidDeveloper)可以知道,当系统收到新的通知或者通知被删除时,会触发NotificationListenerService的回调方法.同时在Android 4.4 中新增了Notification.extras 字段,也就是说可以使用NotificationListenerService获取系统通知具体信息,这在以前是需要用反射来实现的. 转载请

一个日期算法的原理分析

1.问题描述 在 OSC 问答频道有一个问题:时间算法:帮忙解答下 简单的复述一遍就是能够通过如下式子来计算month月day日是一年的第几天. 闰年是 day_of_year=(275*month)/9 - (month+9)/12 + day - 30 非闰年比这个少1天.可以简单的验证,这个式子中每个部分计算后都取整,整个结果总是对的. 我们知道1.3.5.7.8.10.12都是31天,2月的天数有点诡异,其他都是30天,正常情况下我们写程序会写很多if来判断月份,进而计算累积的天数.但是