mariadb galera cluster failure record

Delete statement on responsible galera

delete from t1 where group_id=2 and group_id=3;

After the execution, the cluster damage, in addition to the master node alive, the other two nodes are all stopped.

View galera restrictions, there is no primary key table, do not support the DELETEoperation. But view the table to delete data is the primary key, but not deleted by deleting the primary key, do not know is not the reason

 

 

galera official restrictions:

• The current copy can only work under the InnoDB storage engine. Any other engine writes data to the table, will not be copied (including system tables mysql. *). But CREATE USERsuch as actually modify the mysql. * DDL statement tables will be copied. Meanwhile galera experimental official support MyISAM engine, please see the system specific variables wsrep_replicate_myisam.
• Lock does not support the following: LOCK TABLES, FLUSH TABLES {table lists} WITH READ LOCK, GET_LOCK(), RELEASE_LOCK(), .... The appropriate use of a transaction can overcome these limitations. Global lock operations are supported, such as FLUSH TALBES WITH READ LOCK.
• All tables must have a primary key (multi-column primary key is supported). No primary key table, does not support the DELETEoperation. Meanwhile, no primary key in the table, the order contents of the line may appear different at different nodes in the cluster.
• query logIt can not be recorded into a table. If you open the query log, you need to log into file: log_output=FILE.
• Not supported XA transactions.
• The size of things. galera not explicitly limit the size of things. A write operation in a separate memory block for a cache, the operations of a large transaction (e.g., LOAD DATA) will have a huge adversely affect the performance of the node. To avoid this, the system variables wsrep_max_ws_rowsand wsrep_max_ws_sizethe number of lines default transaction limit of 128,000, the size of the transaction is 1G. If necessary, you can increase these configurations. Future versions will support transactional pieces.

Other restrictions (in alphabetical order):

• If you are using mysqldumpto do the migration status, if any error (such as: you do not have a database account, or the account permissions are not) occurs during error log will appear in the server's SQL SYNTAXerror. Do not be deceived by this error message, just a wonderful way of logging. Pseudo statement actually contains the wrong statement.
• Do not use transactions of any essential size. Insert 100,000 rows, the server will require additional 200-300Mb. In some unfortunate scenario, 500,000 lines need to 1.5Gb, 100 million lines need to 3.5Gb.
• When the lock is not included DDL rigorous loose. For example, if you operate in DML, DDL statements to start a parallel, in a typical setting in MySQL, MySQL will wait for the lock metadata, but it will in galera in desperate execution. As long as you are configuring a cluster model, even if only one node, will be executed. This behavior may cause some side effects, it has not resulted in an in-depth study. Try to avoid such parallel operations.
• Do not rely on self-appreciation. Galera mechanism used is based on generating a unique serial number that does not conflict from increasing, so each time increment numbers are blank. see:http://codership.blogspot.com/2009/02/managing-auto-increments-with-multi.html
• A command may fail ER_UNKNOWN_COM_ERRORto produce "WSREP has not yet prepared node for application use"or 'Unknown command' in older versionserror messages. When the cluster node and is split into the brain few part. For example, when the network fails, when the node and other nodes temporarily lost contact. Similarly, when the state changes may also occur. This node take measures to prevent data inconsistency. This is usually a temporary state, by checking the wsrep_readymonitored values. In this fashion, the execution showand setcommand.
• When the brief disconnection occurred, part of a cluster of health can still be accessed if his status was changed will start resynchronization. At the same time, part of a cluster of failure will disconnect all client connections. This is particularly surprising for the client, especially the client is idle state, an error in the end do not know what happened. Need to remember that recovery in isolated nodes connected to this connection, if there is a data stream on this node, and it will take a long time to synchronize, then, it will say a healthy node cluster and is ready to synchronize and then just adding a node would say she was just added (not synchronized). This connection will get unknown commanda reply. The final will be synchronized.
• Before starting carefully check binlog_formatwhether the configuration is ROW, this value can be changed at runtime. So do not change the value of binlog_format at runtime. This is not only causing copying to fail, and let all the other node crashes.
• If you are using rsyncto do the migration status, when a node crashes before the state transition, rsync process may never hang up, take up the port and stop the node restart. This problem occurs in the performance of the server's error log "port in use" command. Find orphan rsync process, and then manually kill.
• Performance: From a design perspective, the performance of the cluster will not be higher than the slowest performance node. On the same machine, or even a single-node cluster performance is not a good stand-alone database performance. Especially when large-scale transaction processing.
• It does not support Windows.
• Copy Filter: galera in a cluster, you need to be careful to use the filter to copy. As a basic principle, in addition to the update operation DML InnoDB These replica filter are not esteemed galera cluster: binlog-do-db, binlog-ignore-db, replicate-wild-do-db, replicate-wild-ignore-db. However replicate-do-db, replicate-ignore-dbthe filter is supported DDL InnoDB and MyISAM storage engines and DML statements. In other words, the filter must be used with care copy, because it may result in differences in data replication and interrupts.
• FLUSH PRIVILEGESIt will not be copied.
• 5.5.40-galera and before 10.0.14-galera version, need to turn off query cachethe feature.
• When asynchronous replication provided in galera node is a slave, does not support concurrent replication (slave-parallel-threads> 1) from the node.

Original Address: https://mariadb.com/kb/en/mariadb/mariadb-galera-cluster-known-limitations/

 

reference

mariadb galera cluster Precautions (Translation) - Yongfu's blog - OSCHINA https://my.oschina.net/foreverich/blog/743851