Galera Cluster一致性问题

MariaDB Galera Cluster + ProxySQL 方案

三个实例组成一个集群，为多主模式，即 Multi-Master，可以支持同时多点写入，多主同步复制。

Galera Cluster 提供了基于验证的复制，其是一种乐观的同步复制。每一个节点在复制事物时，都会拿这些写集(write-set)与正在 APPLY 队列的写集作比对，如果没有冲突，这个事物就可以继续提交，或 APPLY ，及时任务这个事务被提交，之后在数据库层面，进行事务上的提交操作。

Galera Cluster 的复制，也被称为虚拟同步复制，实际上一种逻辑同步，因为每个节点的操作是相互独立的，更为准确的说是异步的。逻辑同步指的是一个事务在一个node上执行成功后，保证它在其他的node上一定会被成功执行，但不保证及时同步。

从上图中可以看到，在客户端收到 DML请求（Insert/Update/Delete） 时给到node1 后，node1会将其封装为写集(Write Set)，并广播到node2、node3，node2、node3收到写集(Write Set) 后，进行冲突检查，如果没有冲突，先通知node1进行commit，node2和node3将数据写入队列，之后再由 wsrep_slave_threads读取进行commit。故其同步必定会存在一定的延迟。

常见问题汇总

1. 如果主节点（负责写入的节点）写入过大，apply_cd时间过长，导致数据更新操作时间过长，怎么处理?

   wrep_slave_threads 参数配置成cpu的个数或者1.5倍。

2. 脑裂

   任何命令执行出现unknown command，表示出现脑裂，集群中任意两个节点间通信的4567端口不通，并且无法对外提供服务。

   SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";通过这个命令来强制恢复出现脑裂的节点。

3. 并发写

   如果在集群多个节点进行写/更新操作，有可能同时不同节点update同一行操作时就会出现锁死问题，出现:Error：1213 SQLSTATE:4001.解决：指定更新和写入都在都一个节点操作。

4. DDL全局锁

   采用 pt-online-schema-change

5. 只支持Innodb引擎，表结构必须要有主键，不然会造成集中每个节点的data page里的数据不一致。

   不支持表级锁，即不能lock/unlock tables，使用行级锁

6. 新节点加入加入&故障节点恢复加入集群，此时不能有写操作，不然会导致被写入的那台库DDL死锁。所以需要暂停集群业务写操作，等数据一致后在开启写操作。

如何掌控Galera Cluster的同步延迟，使其同步延迟減至最小
1、调整 wsrep_slave_threads 参数 : 有多少threads可以同时由queue读取资料及commit，建议设置为cpu的1~1.5倍
2、调整 flow control 参数: 避免任一Node交易时落后其它Node太多，用于协调每个Node，保证commit的速度可优于queue的增长速度

# mysql 查询 
MariaDB [(none)]> show variables like "wsrep_sst_method"; 
+------------------+-------+ 
| Variable_name    | Value | 
+------------------+-------+ 
| wsrep_sst_method | rsync | 
+------------------+-------+ 

1 row in set (0.001 sec) 

MariaDB [(none)]> show variables like "wsrep_slave_threads"; 
+---------------------+-------+ 
| Variable_name       | Value | 
+---------------------+-------+ 
| wsrep_slave_threads |   1   | 
+---------------------+-------+ 

1 row in set (0.001 sec)

There might be a small period of time when a replica is out of sync. This happens because the source may apply events faster than the replica. And if you do read from the replica, you may read the data that has not changed yet. You can see that from the diagram.

However, this behavior can be changed by setting the wsrep_causal_reads=ON variable. In this case, the read on the replica will wait until the event is applied (this will obviously increase the response time of the read). The gap between the replica and the source is the reason why this replication is called virtually synchronous replication, and not real synchronous replication.

参考

• http://www.sre-devops.info/galera-cluster-sync/

• https://www.percona.com/doc/percona-xtradb-cluster/LATEST/features/multimaster-replication.html