Limitations

This page lists limitations of MySQL/Galera replication.

  1. 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:CREATE USER… or GRANT… but issuing: INSERT INTO mysql.user… will not be replicated. In general, non-transactional engines cannot be supported in multi-master replication.
  2. 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_INCREMENT column to a table without breaking your application.
  3. Unsupported queries:
    • LOCK/UNLOCK TABLES cannot be supported in master-master replication.
    • lock functions (GET_LOCK(), RELEASE_LOCK()…)
  4. Query log cannot be directed to table. If you enable query logging, you must forward the log to a file: 
    log_output = FILE

    Use general_log and general_log_file to choose query logging and log file name.

  5. XA transactions can not be supported due to possible rollback on commit.
  6. 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_rows and wsrep_max_ws_size variables 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.

Trace: • limitations

Login