负责galera上执行删除语句

delete from t1 where group_id= and group_id=;

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

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

mariadb galera群集故障记录-LMLPHP

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_rowswsrep_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的值来监测。在这种状态下,运行执行showset命令。
  • 当发生短暂的断开后,集群健康的部分还是可以被访问的,如果他的状态被修改了,将开始重新同步。同时,集群中失败的部分将断开所有的客户端连接。这对客户端来说特别意外,尤其是在客户端是空闲的状态,并不知道到底发生了什么错误。需记住一点,在连接到这个孤立节点的连接恢复,如果有一个数据流在这个节点上,并且将要花很长时间才能同步,这时,健康的节点将会说集群准备好了而且是同步的,然后刚加入的节点会说她仅仅只是加入(还没同步)。这个连接会得到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

04-14 21:31