首先要规范集群中节点的数量，整个集群中节点数控制在最少3个、最多8个范围内。最少3个节点是为了防止出现脑裂现象，因为只有在两个节点下才会出现此现象。脑裂现象的标志就是输入任何命令、返回结果都是unkown command，节点在集群中，会因为新节点的加入或者故障，同步失效等而发生状态的切换。
--节点状态变化阶段：
open：节点启动成功，尝试连接到集群。
primary：节点已处于集群中，在新节点加入时，选取donor进行数据同步时会产生的状态。
joiner：节点处于等待接收同步文件时的状态。
joined：节点完成数据同步的工作，尝试保持和集群进度一致。
synced：节点正常提供服务的状态，表示已经同步完成并和集群进度保持一致。
doner：节点处于为新加入的节点提供全量数据时的状态。
注意：doner节点就是数据的贡献者，如果一个新节点加入集群，此时又需要大量数据的SST传输，就有可能因此而拖垮整个集群的性能。所以在生产环境中，如果数据量小，还可以使用SST全量传输，但如果数据量很大就不建议使用这种方式了。可以考虑先建立主从关系，在加入集群。
PXC有两种节点的数据传输方式：一种叫SST全量传输，另一种叫IST增量传输。
SST传输有：xtrabackup、mysqldump和rsync三种方法。而增量传输就一种方法就是xtrabackup。但生产环境中一般数据量不大的时候，可以使用SST全量传输，但也只实现xtrabackup方法。
在PXC中还有一个特别重要的模块就是GCache。它的核心功能就是每个节点缓存当前最新的写集。如果有新节点加入进来，就可以把新数据的增量传递给新节点，而不需要再使用SST方式了。这样可以让节点更快地加入集群中。涉及参数如下：
gcache.size：代表用来缓存写集增量信息的大小。它的默认大小是128MB，通过wsrep_provider_options参数设置。建议调整为2GB-4GB范围，足够的空间便于缓存更多的增量信息。
gcache.mem_size：代表gcache中内存缓存的大小，适度调大可以提高整个集群的性能。
gcache.page_size：可以理解为如果内存不够用（gcache不足），就直接将写集写入磁盘文件中。
--：PXC的工作模式：
galera的工作模式是——某个节点写入一个事务，它会广播到其他节点，而这个所谓的其他节点，也包括自己。也就说自己发出来的事务，自己也会收到，只是在收到并产生GTID之后，就被简单忽略了，而不会再去apply一次。
--：galera的并发控制机制：
并发控制主要是在接口galera_pre_commit中完成的，这个接口是galera最重要的接口之一，这里面实现了最重要的复制、验证逻辑。目前，这个接口中包括的并发控制有以下几点：
①：数据复制：
目前的galera版本中，写集数据的发送是通过asio的异步方式将数据广播出去。这个发送是串行的，是一个临界区，因为在每次 发送前，逻辑上还需要分片，并且每次发送完成之后，需要等待一个GTID的值，所以为了保证数据的一致性，这个发送操作需要串行；
②：写集验证：
要求所有进入处理区的GTID必须是顺序的，因为GTID是顺序产生的，所以在顺序的基础上，同一时间必须只有一个事务可以进行处理，说白了就是串行；
受这种层次并发控制管理的操作主要有验证操作，因此说验证是串行的；
③：写集apply
④：事务commit
这个层次的并发控制机制，默认是3，建议也是3，就是串行提交，这样就保证了不管在主库还是从库，所有的节点产生的binlog都是完全相同的；
3、galera 接口：
---galera_init：
这个接口的作用是初始化一个galera节点，这是一个PXC节点调用的第一个wsrep接口，在启动服务器的时候初始化，将所有需要的参数和环境变量初始化。（如：集群名字，实例地址、需要这个接口做binlog的复制等）
---galera_connect：
这个接口是第二个调用的接口。这个接口的作用是将当前节点加入集群中。加入集群前会调用函数wsrep_view_handler_cb来判断新加入节点与集群的数据是否同步；
---galera_recv：
这个接口的作用是，在这个函数里阻塞式的接收其他节点及本节点发送的数据，并且调用复制apply函数执行复制操作。（这个接口实际上是可以并行存在的。它对应的是参数wsrep_slave_threads有多少个线程，就有多少个galera_recv的调用）
---galera_pre_commit：