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)
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
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
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
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 查看所有节点的最新的事务号后决定启动哪个。
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
