Percona XtraDB Cluster Limitations¶
The following limitations apply to Percona XtraDB Cluster:
Replication works only with InnoDB storage engine. Any writes to tables of other types, including system (
mysql.\*) tables, are not replicated. However,
DDLstatements are replicated in the statement level, and changes to
mysql.\*tables are replicated that way. So you can safely issue
CREATE USER..., but issuing
INSERT INTO mysql.user...will not be replicated. You can enable experimental MyISAM replication support using the
UNLOCK TABLESis not supported in multi-source setups
Lock functions, such as
RELEASE_LOCK(), and so on
- 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_file to choose query logging
and the log file name.
Maximum allowed transaction size is defined by the
LOAD DATA INFILEprocessing will commit every 10,000 rows. So large transactions due to
LOAD DATAwill be split to series of small transactions.
Due to cluster-level optimistic concurrency control, a transaction issuing a
COMMITmay still be aborted at that stage. There can be two transactions writing to the same rows and committing in separate Percona XtraDB Cluster nodes, and only one of the them can successfully commit. The failing one will be aborted. For cluster-level aborts, Percona XtraDB Cluster gives back deadlock error code:
(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
XA transactions are not supported due to possible rollback on commit.
The write throughput of the whole cluster is limited by the weakest node. If one node becomes slow, the whole cluster slows down. If you have requirements for stable high performance, then it should be supported by corresponding hardware.
The minimal recommended size of cluster is three nodes. The third node can be an arbitrator.
InnoDB fake changes feature is not supported. This feature has been removed.
enforce_storage_engine=InnoDBis not compatible with
When running Percona XtraDB Cluster in cluster mode, avoid
ALTER TABLE ... IMPORT/EXPORTworkloads. It can lead to node inconsistency if not executed in sync on all nodes.
All tables must have the primary key. This ensures that the same rows appear in the same order on different nodes. The
DELETEstatement is not supported on tables without a primary key.
Percona Server 5.7 data at rest encryption is similar to the MySQL 5.7 data-at-rest encryption. Review the available encryption features for Percona Server for MySQL 5.7. Percona Server 8.0 provides more encryption features and options which are not available in this version.
- Avoid reusing the names of a persistent table for a temporary table. Although MySQL allows a temporary table and a persistent table to have the same name, this approach is not recommended. If a persistent table name matches a temporary table name, Galera Cluster blocks the replication to that table.
With wsrep_debug set to 1, the error log may contain the following message:
... [Note] WSREP: TO BEGIN: -1, 0 : create table t (i int) engine=innodb ... [Note] WSREP: TO isolation skipped for: 1, sql: create table t (i int) engine=innodb.Only temporary tables affected.
- As of version 5.7.32-13.47, an INPLACE ALTER TABLE query takes an internal shared lock on the table during the execution of the query. The
LOCK=NONEclause is no longer allowed for all of the INPLACE ALTER TABLE queries due to this change.
This change addresses a deadlock, which could cause a cluster node to hang in the following scenario:
ALTER TABLEquery in one session or being applied as Total Order Isolation (TOI)
A DML on the same table from another session
Do not use one or more dot characters (.) when defining the values for the following variables:
MySQL and XtraBackup handles the value in different ways and this difference causes unpredictable behavior.