負責galera上執行刪除語句
delete from t1 where group_id=2 and group_id=3;
執行后，群集破壞，除了主節點存活，其他倆個節點全都停掉。
查看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