A: For auto-increment particular, Cluster changes auto_increment_offset for each new node. In the single node workload, locking handled by usual way how InnoDB handles locks. In case of write load on several nodes, Cluster uses optimistic locking and application may receive lock error in the response on COMMIT query.
A: When the node crashes, after the restart it will copy whole dataset from another node (if there were changes to data since crash).
A: Your check should be simply:
SELECT 1 FROM dual;
You can also check the node health with the clustercheck script. You need to set up clustercheck user:
GRANT USAGE ON *.* TO 'clustercheck'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19';
You can then check the node health by running the clustercheck script:
/usr/bin/clustercheck clustercheck password 0
If the node is running correctly you should get the following status:
HTTP/1.1 200 OK Content-Type: text/plain Connection: close Content-Length: 40 Percona XtraDB Cluster Node is synced.
In case node isn’t sync or if it is off-line status will look like:
HTTP/1.1 503 Service Unavailable Content-Type: text/plain Connection: close Content-Length: 44 Percona XtraDB Cluster Node is not synced.
<user> <pass> <available_when_donor=0|1> <log_file> <available_when_readonly=0|1> <defaults_extra_file>” Recommended: server_args = user pass 1 /var/log/log-file 0 /etc/my.cnf.local” Compatibility: server_args = user pass 1 /var/log/log-file 1 /etc/my.cnf.local”
A: XtraDB Cluster populates write set in memory before replication and this sets one limit for how large transactions make sense. There are wsrep variables for max row count and max size of of write set to make sure that server is not running out of memory.
What I mean is like having 4 nodes, 4 tables like sessions_a, sessions_b, sessions_c and sessions_d and have each only on one of the nodes?
A: Not at the moment for InnoDB tables. But it will work for MEMORY tables.
A: Then Quorum mechanism in XtraDB Cluster will decide what nodes can accept traffic and will shutdown nodes that not belong to quorum. Later when the failure is fixed, the nodes will need to copy data from working cluster.
A: It would not handle it. The split brain is hard stop, XtraDB Cluster can’t resolve it. That’s why the minimal recommendation is to have 3 nodes. However there is possibility to allow a node to handle the traffic, option is:
wsrep_provider_options="pc.ignore_sb = yes"
A: It is possible in two ways:
A: This is expected behavior, to prevent split brain. See previous question.
A: You may need to open up to 4 ports if you are using firewall.
Regular MySQL port, default 3306.
Port for group communication, default 4567. It can be changed by the option:
wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4010; "
Port for State Transfer, default 4444. It can be changed by the option:
Port for Incremental State Transfer, default port for group communication + 1 (4568). It can be changed by the option:
wsrep_provider_options = "ist.recv_addr=10.11.12.206:7777; "
A: There is no “async” mode, all commits are synchronous on all nodes. Or, to be fully correct, the commits are “virtually” synchronous. Which means that transaction should pass “certification” on nodes, not physical commit. “Certification” means a guarantee that transaction does not have conflicts with another transactions on corresponding node.
A: Yes. On the node you are going to use as master, you should enable log-bin and log-slave-update options.
A: Try to disable SELinux. Quick way is:
echo 0 > /selinux/enforce