mariadb galera群集故障记录

负责galera上执行删除语句

delete from t1 where group_id= and group_id=;

执行后，群集破坏，除了主节点存活，其他俩个节点全都停掉。

查看galera的限制，没有主键的表，不支持DELETE操作。但是查看删除数据的表是有主键的，只不过删除不是根据主键删除，不知道是不是这个原因

galera官方的限制：

• 当前的复制仅仅在 InnoDB 存储引擎 下才能工作。任何其他的引擎对数据表的写操作，都不会被复制（ 包括系统表mysql.* ）。但 CREATE USER 等实际上是修改了 mysql.* 的表的DDL语句是会被复制的。同时 galera 官方实验性的支持 MyISAM 引擎，具体请查看系统变量wsrep_replicate_myisam。
• 不支持如下的锁定：LOCK TABLES , FLUSH TABLES {table lists} WITH READ LOCK, GET_LOCK(),RELEASE_LOCK(),...。适当的使用事务可以克服这些限制。全局锁定操作是支持的，如FLUSH TALBES WITH READ LOCK。
• 所有的表都必须有一个主键(多列主键是支持的)。没有主键的表，不支持DELETE操作。同时，在没有主键的表中，内容行出现的顺序在集群的不同的节点中可能不同。
• query log不能被记录到一张表中。如果你开启了查询日志，你需将日志导入到文件中：log_output=FILE。
• 不支持 XA transactions。
• 事物大小。galera没有明确限制事物大小。一个写入操作是在一个单独的内存缓存块中进行的，所以一个大的事务操作(如LOAD DATA)将会对节点的性能产生很大的不利影响。为了避免这个，系统变量 wsrep_max_ws_rows 和 wsrep_max_ws_size 默认限制了事务的行数为12.8万，事务的大小为1G。如果有必要，可以增大这些配置。将来版本将支持事务碎片。

其他限制（排名不分先后）:

• 如果你使用mysqldump做状态迁移，如果过程中出现任何错误（如：您没有数据库账号，或者账号权限不对），都将在服务器的错误日志中出现SQL SYNTAX错误提示。不要被这个错误提示欺骗了，仅仅是一种奇葩的日志记录方式。伪语句中实际上包含了错误语句。
• Do not use transactions of any essential size. 插入10万行，服务器将需要额外的200-300Mb。在一些不幸的场景中，50万行需要1.5Gb，100万行需要3.5Gb。
• 当包含DDL时锁定是不严谨松散的。例如，如果你在DML操作时，并行的开始一个DDL语句，在通常的MySQL设置中，MySQL将等待元数据的锁定，但是在galera中却会不顾一切的执行。只要你配置的是集群模式，就算是只有一个节点，也会执行。这种行为可能引起一些副作用，导致的结果还没有进行深入研究。尽量避免这样的并行操作。
• 不要依赖自增值。galera使用的机制是基于生成一个唯一的不冲突的序号来自增，所以每一次自增序号都有空白。见：http://codership.blogspot.com/2009/02/managing-auto-increments-with-multi.html
• 一个命令可能失败ER_UNKNOWN_COM_ERROR产生"WSREP has not yet prepared node for application use" 或 'Unknown command' in older versions 的错误信息。当集群进入脑裂并且节点是少数部分时。例如，当网络出现故障时，当节点暂时的和其他节点失去联系。同样也可能出现在状态变更的时候。节点采取这个措施来防止数据不一致。这通常是一个临时状态，可以通过检查wsrep_ready的值来监测。在这种状态下，运行执行show和set命令。
• 当发生短暂的断开后，集群健康的部分还是可以被访问的，如果他的状态被修改了，将开始重新同步。同时，集群中失败的部分将断开所有的客户端连接。这对客户端来说特别意外，尤其是在客户端是空闲的状态，并不知道到底发生了什么错误。需记住一点，在连接到这个孤立节点的连接恢复，如果有一个数据流在这个节点上，并且将要花很长时间才能同步，这时，健康的节点将会说集群准备好了而且是同步的，然后刚加入的节点会说她仅仅只是加入（还没同步）。这个连接会得到unknown command的回复。最终都会同步的。
• 在启动前仔细检查binlog_format的配置是否为ROW,这个值可以在运行时改变。所以不要在运行时改变binlog_format的值。这不仅仅造成复制失败，而会让所有其他的节点崩溃。
• 如果使用rsync来做状态迁移，当一个节点在状态迁移前崩溃时，rsync进程可能永远挂起了，占用着端口而且阻止节点重启。这个问题表现为在服务器的错误日志中出现"port in use"命令。找出这个孤儿rsync进程，然后手动杀掉。
• 性能：从设计角度看，集群的性能不会比最慢的节点的性能高。同一台机器上，甚至是单节点的集群的性能也不是独立的数据库的性能好。特别是在大型的事务处理的时候。
• 不支持Windows。
• 复制过滤：在galera集群中，需要小心使用复制过滤。作为一个基本准则，除了InnoDB的DML更新操作，这些复制过滤是不被galera集群推崇的：binlog-do-db,binlog-ignore-db,replicate-wild-do-db,replicate-wild-ignore-db。然而replicate-do-db,replicate-ignore-db过滤是被InnoDB和MyISAM存储引擎的DDL和DML语句支持的。也就是说，必须小心使用复制过滤，因为可能造成数据差异和复制中断。
• FLUSH PRIVILEGES不会被复制。
• 5.5.40-galera和10.0.14-galera之前的版本，需要关闭query cache的功能。
• 在设置异步复制时，在galera节点作为从节点时，在从节点上不支持并发复制（slave-parallel-threads>1)。

原文地址: https://mariadb.com/kb/en/mariadb/mariadb-galera-cluster-known-limitations/

参考

mariadb galera 集群注意事项(翻译) - 永福的博客 - OSCHINA https://my.oschina.net/foreverich/blog/743851