- 1. PXC 介绍2015.07.31
王洪权
Weibo:foreverreturn
mydbalife@gmail.com
- 2. 内容概要一 PXC介绍
二 PXC兼容性
三 PXC限制
四 PXC运维技巧（防止踩坑）
问答
- 3. 初识别PXC2018/10/15Percona XtraDB Cluster免费开源
目前已经很多企业部署到生产环境。Percona
XtraDB ClusterPercona Server出品WSREP patchesGalera library
- 4. 2018/10/15PXC 架构图
- 5. 2018/10/15PXC 特性synchronous replicationmulti-master replicationparallel applying on slavesdata consistencyautomatic node provisioning
- 6. 2018/10/15Virtually synchronoushttps://en.wikipedia.org/wiki/Virtual_synchrony
- 7. 2018/10/15多主复制
- 8. 2018/10/15并行复制
- 9. 2018/10/15强数据一致性
- 10. 2018/10/15自动添加节点
- 11. 2018/10/15CAP theoremhttp://en.wikipedia.org/wiki/CAP_theorem
Consistency (all nodes see the same data at the same time)
Availability (a guarantee that every request receives a response about whether it succeeded or failed)
Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)
- 12. 2018/10/15ConsitencyNode availabilityConsistencyPartition Tolerance
- 13. 2018/10/15网络异常
- 14. 2018/10/15MySQL复制所有的数据库实例都是可以访问的但是此时数据是不一致的
- 15. 2018/10/15PXC 集群实例system2是不能
访问的，因为做集群重构system2为非主分量，1/3投票小于50%形成非主分量，system1,system3 2/3 投票大于50%，形成主分量，可以访问。因此，PXC数据是完全一致的
- 16. 2018/10/15脑裂哪个系统可用？PXC中这种状况2个节点都不可以访问，PXC完全可以防止脑裂
- 17. 2018/10/15PXC和MySQL对比MySQL复制:
可以访问所有的系统
但是数据不一致数据完全一致PXC:
- 18. PXC兼容性完全兼容已有的系统（innodb引擎，优化器执行计划，完全相同的优化思路）
最小化的迁移（非常方便的从现有系统迁移到PXC）
快速的回退版本(无锁化，非常容易的恢复到非PXC系统)
- 19. PXC限制只支持INNODB表
不允许大事务的产生（否则的话后果很严重）
写性能取决于最差的节点
不能解决热点更新问题
乐观锁控制
对于写密集型应用需要控制单个节点的大小，单个节点数据越大，新加节点如果采用自动添加可能产生很大抖动（添加节点建议用备份或者备份+binlog 进行ist 同步）。
- 20. 2018/10/15乐观锁
- 21. 乐观锁原理2018/10/15
- 22. 乐观锁原理2018/10/15
- 23. 乐观锁原理
对于多点写入需要应用程序处理这些异常
建议生产环境下使用单点写入，防止这种冲突。
PXC无法解决热点行更新问题2018/10/15
- 24. 2018/10/15写入性能图示
- 25. 2018/10/15自动添加节点需注意单个DB的大小建议通过备份+binlog建立大的DB节点，减少抖动
- 26. PXC 真的就那么完美么？
PXC 用前一定要规避它的风险，了解它的各个原理，充分做好测试，否则的话，后果很严重….
如果充分了解它的原理后，用起来还是很不错的。
正所谓：知己知彼，百战不殆！
2018/10/15
- 27. 2018/10/15PXC 运维技巧迁移到PXC拓扑
安全备份，躲避流控
节点添加SST原理
节点添加IST原理
适度备份减少节点SST
Gcache设置注意事项
宕机节点修复-选择正确的doner
添加新节点--使用IST
减少抖动-正确表结构变更
常规维护原理
宕机节点维护原理
投票选举原理
多IDC部署
PXC 恢复误操作
PXC 外挂slave设置操作
尽可能的控制单个事务的大小
Haproxy设置
- 28. 迁移到PXC拓扑2018/10/15PXCMASTERPXCPXClog-slave-updates
log-bin=on新节点加入需要SST新节点加入需要SSTlog-slave-updates
log-bin=onlog-slave-updates
log-bin=on单slave节点迁移到PXC：
- 29. 迁移到PXC拓扑2018/10/15SLAVEPXCMASTERPXCPXClog-slave-updates
log-bin=on新节点加入需要SST新节点加入需要SSTlog-slave-updates
log-bin=onlog-slave-updates
log-bin=on多slave节点迁移到PXC：
- 30. 迁移到PXC拓扑2018/10/15SLAVEPXCMASTERPXCPXClog-slave-updates
log-bin=on新节点加入需要SST新节点加入需要SSTlog-slave-updates
log-bin=onlog-slave-updates
log-bin=onDual master迁移到PXC：
- 31. 迁移到PXC注意事项1 评估你的工作负载PXC是否可以完全cover(tcpcopy导入流量测试)，包括单个事务的响应时间，集群整体的吞吐量。
2 一定要完全熟悉PXC的原理和运维操作，规避运维过程中的风险点，做到出问题后可以迅速定位解决，在上线前充分的做好HA测试。
3 上线节点尽量保持单点写入
4 避免迁移到PXC为跨mysql大版本的升级，数据库大版本升级一定也要充分测试程序的兼容性。2018/10/15
- 32. 安全备份，躲避流控pxc1,pxc2,pxc3 三个节点
Pxc1为主写入节点
在pxc2上实施备份
mysql> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)
Pxc2 日志
2015-07-30 10:59:11 7311 [Note] WSREP: Provider paused at 3a83e2aa-31d9-11e5-9f16-0a6ecbb5f827:5266678 (5319109)
Pxc2 状态变量
mysql> show status like '%wsrep_local_recv_queue%';
| wsrep_local_recv_queue | 888 |
| wsrep_local_recv_queue_max | 888 |
Pxc1 写入阻塞
2018/10/15
- 33. 安全备份，躲避流控2018/10/15
- 34. 安全备份，躲避流控Xtrabackup在备份时刻会发送flush table with read lock,这个是发生流控产生，因为是全局读锁，所以会造成整个集群阻塞，因此为了避免这个问题需要做以下步骤
在备份节点
第一 set global wsrep_desync=ON;
第二 take backup
第三 show status like '%wsrep_local_recv_queue%';待接收队列为0的话
第四 set global wsrep_desync=OFF;2018/10/15
- 35. 适度备份减少节点SST适度的备份，当一个节点发生宕机后（硬件损坏等），可以优先使用备份恢复，并且可以在一定条件下，减少SST的发生。
有三个条件:
– 使用XtraBackup的版本 >= 2.0.1
– XtraBackup备份的时候加--galerainfo
– gcache设置足够大，保证通过备份恢复后，增量的数据还在gcache中，这个时候可以ist,如果不在的话就只能先追binlog，最终再进行ist2018/10/15
- 36. 适度备份减少节点SST1 在节点进行备份使用—galera-info，备份后查看xtrabackup_galera_info
cat xtrabackup_galera_info
5050aa2a-10d6-11e5-9003-0ee649e64578:2251445
2 在新机器上恢复备份
3 查看其他节点的writeset 在gcache 中的最小的序列号
mysql -e "show global status like 'wsrep_local_cached_downto';"
+---------------------------+---------+
| Variable_name | Value |
+---------------------------+---------+
| wsrep_local_cached_downto | 2251443 |
+---------------------------+---------+
2018/10/15
- 37. 适度备份减少节点SST4 如果集群节点的gcache中的事务号，包含xtrabackup_galera_info中的事务号的话，从其他节点拷贝grastate.dat，在新节点编辑 grastate.dat ，并且把xtrabackup_galera_info中的事务号填入seqno: 后边。
# GALERA saved state
version: 2.1
uuid: 5050aa2a-10d6-11e5-9003-0ee649e64578
seqno: 2251445
cert_index:
5 在新节点指定一个可以复制的增量gcache节点
service mysql start --wsrep_sst_donor=pxc2|pxc3
2018/10/15
- 38. Gcache设置注意事项Gcache存储了所有的 writeset ,因此说这个集合的大小直接决定了允许其他节点宕机后多长时间内可以进行ist 同步。
show global status like 'wsrep_received_bytes';
show global status like 'wsrep_replicated_bytes';
select sleep(60);
show global status like 'wsrep_received_bytes';
show global status like 'wsrep_replicated_bytes';
| wsrep_received_bytes | 83976571 |
| wsrep_replicated_bytes | 0 |
[...]
| wsrep_received_bytes | 90576957 |
| wsrep_replicated_bytes | 800 |
2018/10/15
- 39. Gcache设置注意事项因此:
每分钟数据写入:
(second wsrep_received_bytes – first wsrep_received_bytes) + (second wsrep_replicated_bytes – first wsrep_replicated_bytes)
(90576957 – 83976571) + (800 – 0) = 6601186 bytes or 6 MB per minute.
每小时数据写入:
6MB * 60 minutes = 360 MB per hour of writesets received by the cluster.
默认是128M，适当调大gcache可以减少SST情况的发生，因为gcache是内存映射文件，因此会占用内存，建议设置32G
2018/10/15
- 40. PXC节点添加SST原理2018/10/15我什么都没有，我要进行sst
- 41. PXC节点添加IST原理2018/10/15我需要从 event2复制，你的gcache
中有我需要的数据么，有的话，咋们
就进行IST吧
- 42. 宕机节点修复-选择正确的doner
如果不选择一个正确的doner节点，很可能发生SST的情况，因为xtraback在备份节点的时候是会触发流控的，引起整个集群短时间抖动，这对于集群来说是非常危险的动作，所以说处理故障节点的时候一定确保修复后采用IST。
可以采用下列方法规避：
在目标节点上，查看自己的事务号mysqld_safe --wsrep-recover
在各个节点运行show global status like ‘wsrep_local_cached_downto’; 查看每个节点的gcache中保存的最小事务号
确定其他节点在gcache中的事务号包含目标节点的事务号，在目标节点，执行增量同步 service mysql start --wsrep_sst_donor=node1|node2|node32018/10/15
- 43. 添加新节点--使用IST
通过全备增备恢复（全备增备均采用--galera-info备份)
从其他运行节点拷贝grastate.dat文件到要新建节点，查看cat xtrabackup_galera_info 文件，找到到最新的事务号，把这个事务号写入grastate.dat文件的seqno: 事务号。
查看目前节点中gcache最小的事务号，运行show global status like ‘wsrep_local_cached_downto’; 如果其他运行节点的的最小事务号包含新建节点的事务号，选中一个doner节点执行增量同步 service mysql start --wsrep_sst_donor=node1|node1|node2
如果运行节点的gcache大于xtrabackup_galera_info文件中的事务号，这个时候需要通过binlog将节点恢复追到最新，然后在binlog中找到应用过后的xid，如果最终恢复的binlog的xid在集群种其他节点的gcache中，这个时候就可以使用ist同步了，把最终恢复的xid写入到grastate.dat文件的seqno: 事务号。2018/10/15
- 44. 减少抖动-正确表结构变更
使用以下方式变更：
– 常规TOI 情况下 ALTER（不靠谱）
– 使用pt-online-schema-change（靠谱）
– 使用RSU方法（不靠谱）
– 使用 5.6 online ALTER （不靠谱，抖动较大）2018/10/15
- 45. 常规维护原理2018/10/15service mysql bootstrap-pxcservice mysql start --wsrep-cluster-address="gcomm://"service mysql start --wsrep_sst_donor=nodeCservice mysql start --wsrep_sst_donor=nodeC|nodeBA 节点常规关闭，待加入集群A B节点常规关闭，待加入集群A B关闭后，C也关闭，如果业务一直都有写入，需要首先初始化C:
- 46. 宕机节点维护原理2018/10/15节点异常包括（机器断电，实例崩溃，系统重启，kernel panic,kill等）
A节点宕机后，2/3 大于50%，suspect_timeout后重新构建集群，构建集群
过程中集群不可用，重新构建完毕后恢复正常。
当A节点加入时候，采用IST的方式，但是不影响整个集群。
A,B相继宕机，不能形成主分量，这个时候C节点不可用。如果想让C节点可以
接受请求的话，需按照下列操作
SET GLOBAL wsrep_provider_options='pc.bootstrap=true';
三节点全部宕机后，直接启动集群即可，启动C节点 service mysql bootstrap-pxc
也可以 mysqld_safe --wsrep-recover 查看所有节点的最新的事务号后决定启动哪个。
- 47. 全部节点异常宕机处理IDC断电等原因，导致节点全部宕机
pxc1
ps axu|grep mysql|awk '{print $2}'|xargs -i kill -9 {}
pxc2
ps axu|grep mysql|awk '{print $2}'|xargs -i kill -9 {}
pxc3
ps axu|grep mysql|awk '{print $2}'|xargs -i kill -9 {}
三个节点都会存在gvwstate.dat 文件。
cat gvwstate.dat
my_uuid: 03579979-1294-11e5-8391-873351fadd53
#vwbeg
view_id: 3 03579979-1294-11e5-8391-873351fadd53 3
bootstrap: 0
member: 03579979-1294-11e5-8391-873351fadd53 0
member: fa565042-1293-11e5-a3e4-1299a5345170 0
member: ff6e97a7-1293-11e5-ab2c-5af2f29d63e6 0
#vwend
2018/10/15
- 48. 全部节点异常宕机处理
分别在pxc1,pxc2,pxc3启动数据库
pxc1
service mysql start
pxc2
service mysql start
pxc3
service mysql start2018/10/15
- 49. 节点宕机时间过长重新进行IST同步Pxc1,pxc2,pxc3 三台的集群，其中任意一台宕机，例如pxc3宕机，操作步骤：
1 修复宕机的节点pxc3 ,如果可以修复，直接修复，如果不可以修复通过备份修复。
2 修复PXC3后，在启动前mysqld_safe --wsrep-recover 查看当前pxc3的事务号
3 查看pxc1,pxc2两个节点gcache的事务好
mysql -e "show global status like 'wsrep_local_cached_downto';"
mysql -e "show global status like 'wsrep_local_cached_downto';“
如果pxc1和pxc2的gcache的事务号包含pxc3节点的事务号，即可以选定pxc1和pxc2的任意节点为doner节点，执行同步
service mysql start --wsrep_sst_donor=pxc1|pxc2
5 如果不存在，如果想避免SST可以通过备份+binlog修复。2018/10/15
- 50. 投票选举原理2018/10/15
- 51. 投票选举原理2018/10/153个节点当发生网络异常情况下,左边两个节点2/3大于50%仍然可以访问，隔离的节点1/3概率小于50%，不可以读写
- 52. 投票选举2018/10/154个节点当发生网络异常情况下,左边右边两个节点2/4不大于50%，不能形成主分量，隔离的网络两边都为非主分量，不可以访问
- 53. 三节点是最推荐的一个设置2018/10/15投票选举原理
- 54. 多IDC部署2018/10/15无法保证DC1掉电，系统可用可以保证任意一个DC异常系统可用可以保证任意一个DC单节点宕机后，本DC令一个节点可用，并且节点恢复可以从本IDC进行。
- 55.
注意：
多DataCenter部署节点时候，要保证IDC间网络的延时。伴随着延时的增加集群整体的吞吐量会下降，单次事务的响应时间会增加。
当采用DNS做数据中心切换的情况下，多IDC 部署时，当出现一个DataCenter异常的情况下，可以通过更改DNS等方式指向其他数据中心，由于DNS存在缓存刷新时间，即便是存在对异常数据中心的操作也可以正常同步到其他数据中心，保证数据的可靠性。
2018/10/15多IDC部署
- 56. PXC恢复误操作log-bin=on
log-slave-updates=on
这2个一定要在节点上打开，因为只要有binlog在，加上全备和增备，可以轻松的进行基于时间点的恢复.2018/10/15
- 57. PXC恢复误操作2018/10/15查找truncate 语句的position通过 xtrabackup进行恢复
- 58. PXC恢复误操作2018/10/15恢复表在truncate前为止恢复表之后，导出，导入到线上。
- 59. PXC挂异步slave 操作2018/10/15通常会有在一个PXC集群外挂slave，用于测试或者统计用:
异步slave连接到PXC集群种连接A,当A发生宕机后，异步slave需要从新找点，连接B。
- 60. PXC挂异步slave 操作2018/10/15当A节点宕机后，冒然连接B节点是完全不正确的，这个时候需要找点操作
- 61. PXC挂异步slave 操作2018/10/15找到异步slave的relay log中最终的Xid找到B节点中与之对应的Xid，通过Xid找到相关的position
- 62. PXC挂异步slave 操作2018/10/15停掉slave复制，重新找点，连接到新的master上
- 63. PXC挂异步slave 操作基于5.6的gtid，轻松进行异步slave找点操作。
在PXC集群各个节点上打开gtid
server_id=1
log-bin=pxc1-bin
log_slave_updates
enforce_gtid_consistency=1
gtid_mode=on
如果集群种任意一个节点发生宕机后，外挂slave都可以轻松切换到其他的PXC节点。
CHANGE MASTER TO MASTER_HOST =‘new_master_ip',MASTER_USER ='rep_user,MASTER_PASSWORD = ‘rep_password',MASTER_AUTO_POSITION =1;2018/10/15
- 64. 尽量控制单个事务的大小一定要控制单个事务的大小，因为当遇到大的dml操作时候，很可能导致PXC集群节点异常。
任何一种数据库对于大事务操作都应该避免。
做法：把大事务操作拆分成小事务。2018/10/15
- 65. Haproxy设置2018/10/15 clustercheck
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Content-Length: 40
Percona XtraDB Cluster Node is synced.mysqlchk 9200/tcp # mysqlchktail /etc/services
- 66. 2018/10/15Haproxy设置
- 67. 演示
demo2018/10/15
- 68.
问答2018/10/15
