This page lists limitations of MySQL/Galera replication.
- Currently replication works only with InnoDB storage engine. Any writes to tables of other types, including system (
mysql.*) tables are not replicated. However, DDL statements are replicated in statement level, and changes to
mysql.*tables will get replicated that way. So, you can safely issue:
INSERT INTO mysql.user…will not be replicated. In general, non-transactional engines cannot be supported in multi-master replication.
- Rows in tables without primary key may appear in different order on different nodes. As a result
SELECT…LIMIT…may return slightly different sets. Don't use tables without primary key. It is always possible to add an
AUTO_INCREMENTcolumn to a table without breaking your application.
- Unsupported queries:
LOCK/UNLOCK TABLEScannot be supported in master-master replication.
- lock functions (
- Query log cannot be directed to table. If you enable query logging, you must forward the log to a file:
log_output = FILE
general_log_fileto choose query logging and log file name.
- XA transactions can not be supported due to possible rollback on commit.
- Transaction size. While Galera does not explicitly limit the transaction size, a writeset is processed as a single memory-resident buffer and as a result, extremely large transactions (e.g.
LOAD DATA) may adversely affect node performance. To avoid that
wsrep_max_ws_sizevariables limit transaction rows to 128K and transaction size to 1Gb by default. If necessary user may want to increase those limits. Future versions will add support for transaction fragmentation.