Percona XtraDB Cluster 修行手册（一）

最近正好公司准备新上一个高可用要求的mysql，结合实际遇到的问题做个记录吧。
安装什么的不谈了，摘自5.7.21-29.26版本官方文档以及一些自己所想到的东西：

优点：
1.所有数据全集群同步，不需要远程访问。
2.无管理节点，可以在任何节点丢失的情况下继续提供服务。
3.优秀的读扩展性。

缺点：
1.加入新节点开销大，sst(State Snapshot Transfer)会传输整个数据集。
2.不适宜作为写扩展方案，节点越多，真正获得的写性能相比起整个开销而言并不会越多，
  反而会提高费效比。
3.有几个节点就有几份完整数据集。

限制：
1.复制仅仅限于INNODB引擎的表。所有的其余类型的表包括mysql schema下的表都不可复制
  DDL语句通过语句格式复制，所以grant和create user语句是没问题的。但是某些取巧的
  账户/权限操作，比如修改mysql.user表行不通(除非你想使用体验版myisam复制的赌你的
  数据不会出问题)。
2.不支持所有的显式的锁表操作：
  lock table/flush tables with read lock/get_lock()等等。
3.general日志不可被定向到表，只能用file存储。
4.事务被 wsrep_max_ws_rows 和 wsrep_max_ws_size 控制。在笔者的机子上的情况
   mysql> show variables like '%wsrep_max_ws%';
   +-------------------+------------+
   | Variable_name     | Value      |
   +-------------------+------------+
   | wsrep_max_ws_rows | 0          |
   | wsrep_max_ws_size | 2147483647 |
   +-------------------+------------+
   load data infile被分割为诸多小事务，每10000行提交一次。
5.cluster级别的乐观锁导致如果两个操作同一行的语句同时提交到本地节点而还没完成集群内的
  确认的话，其中一个会被abort，同时报error1213(死锁)。
6.不支持分布式事务。
7.集群的写入受限于最慢的节点，需要高性能，就使用可靠的硬件吧，特别是有写回功能的
  带电池的raid卡，值得拥有！！！
8.建议最好至少使用三节点的cluster，免得脑裂什么的。
9.不支持binlog_rows_query_log_events，想要方便的话，老老实实用general日志吧。
10.不要使用alter table import/export，以免造成节点失去同步状态(单节点丢失，除非在全节
   点都执行同样的操作)。老老实实用mysqldump吧。

关于初始同步：
1.State Snapshot Transfer(SST)复制所有数据到新节点。
  这个同步基于Xtrabackup，由wsrep.cnf的wsrep_sst_method参数控制，三个可选参数分别是
  mysqldump/rsync/xtrabackup(5.7版本为xtrabackup-v2)。前二者都会隐式执行flush tables
  with read lock。所以默认也是xtrabackup。
2.Incremental State Transfer (IST)增量复制数据到一个很短时间掉线的节点上。
  每个节点都会有一个 ring-buffer，作为存储最近的N个changes。donor节点在需要时传输这部
  分数据以增量的模式复制到新节点，避免SST。status wsrep_local_state_comment可以看到前
  面所说的当前的N。根据innodb status可以取到XID。

关于MULTI-MASTER REPLICATION：
点击打开链接
这个链接是网上各种图的原产地^_^
1.其响应时间主要由三个方面构成：
 Network round-trip time+Certification time+Local applying
2.关于复制：
  其实mysql进入5.7时代之后，已经有了并行复制了。所以PXC也必须有。原文是：A slave can
  have many parallel threads configured using the wsrep_slave_threads variable。惊喜
  的是wsrep_slave_threads 控制着最大并行度(IO和CPU充足的话，调大它吧)。
  有可能存在这样一种情况：某个节点写负载太大，导致另外的节点apply跟不上，这时候这些节
  点就是不同步的状态。这也是为什么PXC的内部复制叫做virtually synchronous replication
  而不是real synchronous replication的原因。设置wsrep_causal_reads=ON 能解决这个问题，
  同时也增加了读的响应时间。总之选择靠谱的硬件总是好的(没有加钱解决不了的问题^_^)。
  一个非常关键的一点是，由于乐观锁的存在，所以在应用程序中必须要有对于ERROR DEADLOCK
  的处理。

PXC STRICT MODE(default ENFORCING)：
  这个特性分为四个级别，DISABLED/PERMISSIVE/ENFORCING/MASTER。用于校验是否违背后文中
  出现的各种检查，以及为背后的行为处理。前两者不建议使用(一个根本不校验，第二个校验
  失败仅仅记录一个日志然后照常运行)，第三与第四的区别在于ENFORCING用于多个节点write，
  MASTER用于单个write节点。
  校验类型很多包括：Storage engine/MyISAM replication/Binary log format/
  Tables without primary keys/Log output/Explicit table locking/
  Auto-increment lock mode/Combining schema and data changes in a single statement/
  Discarding and Importing Tablespaces。其实这些校验都是前文限制篇中所说的各种限制。
  任何在启动时的配置或者启动后改变这些限制的相关参数的行为，在enforcing模式下都会导
  致error log并且deny或者启动不成功。
  有个值得注意的地方是，PXC在严格模式下CTAS是不能执行成功的，当然我们可以换种方式，
  比如：
  create table tab_name like tab_name1;
  insert into tab_name select * from  tab_name1;