We’ve been testing ClusterControl with three Percona XtraDB Cluster nodes on a virtualized environment and found it to be pretty resilient to faults.  Even after performing a brutal shutdown of all VMs (which is equivalent to pulling the plug on a physical machine) or wiping out the MySQL database on one of the nodes, the cluster returns to its normal state when the VMs are powered back up.  Still, sometimes things can go wrong, and it’s good to know what to do in this case.

First of all, always check the status of the jobs in Logs -> Jobs.  Remember to refresh both the job list window and the job messages window.  Check also the nodes’ logs in Nodes -> Logs.  From shell, peruse /var/lib/mysql/error.log and /var/log/mysqld.log; usually you’ll find the problem there.

ClusterControl will run a cluster recovery job if the cluster is in Degraded or Failure state, and try to repeat this job periodically.  As long as the job is marked as RUNNING in the job list, it’s working.  You should also see in the job messages window the message « GALERA_NODE_MYSQL_DISCONNECTED, expected state GALERA_NODE_SYNCED – waiting! ».  Don’t assume that the system is hung; be patient and wait that the job finishes.

A joiner node might take some time before it gets synced via SST.  During this whole time the node will be marked orange in the UI (note that the donor will be marked orange, too).  A 1-Gb database can take half an hour to be fully synced to one node.

However, if the job ends as FAILED the cluster was definitely unable to automatically do a cluster recovery.  You will also see messages such as « Cannot determine most advanced node », « Unable to join the cluster », and « Node will never reach the expected state » in the job logs.  In this case it’s time to brush up the Linux shell skills. Note: Before operating on the nodes’ MySQL daemons via shell, prevent ClusterControl from interfering by setting Auto Recovery: Cluster / Node to OFF.

 

Starting a node

You can start a node with the command

# service mysql start

or, if this is the first node of the cluster,

# service mysql bootstrap-pxc

The latter command defines the node as the one with the correct copy of the database (to which the other nodes should sync via SST) and boots up the cluster.

If MySQL refuses to start and complains about a lock file or a PID file, it’s a telltale sign that the previous MySQL process did not exit normally.  Get rid of these files:

# rm -f /var/lock/subsys/mysql /var/lib/mysql/mysqld.pid

and try to start MySQL again.

 

Syncing a node

When a node is out of sync it will try a IST towards a donor node to resynchronize itself with the cluster.  If this is not possible, it will try a SST.  If even this fails, you may force a SST by wiping out the contents of the MySQL data directory (we recommend a rename instead of a delete, so you’ll have a copy in case something goes wrong).

First, stop the joiner node.  Try first a graceful stop, then a merciless killing:

# service mysql stop

# killall -9 mysql

Ensure that the MySQL daemon is not running anymore:

# service mysql status

# ps -ef | grep mysql

Then empty the MySQL data directory:

# cd /var/lib/

# mv mysql mysql_bak

# mkdir mysql

# chown mysql:mysql mysql

# chmod 755 mysql

Finally, restart the node:

# service mysql start

If everything goes well you should see a message « Starting MySQL (Percona XtraDB Cluster)… State transfer in progress, setting sleep higher… » followed by a long series of dots.  Be patient and wait that the state transfer finishes.

 

Checking the status of a node

Sometimes the ClusterControl interface may not show the latest status of a node; the node parameters may be wrong, or the node could be shown in orange while everything is working fine.  If this happens, you can fix this glitch by restarting the cmon process in the controller, and logging out and in again in the web interface.

However, remember that you can also know a node’s replication status directly by peeking into its database:

mysql> show status like 'wsrep%';
+------------------------------+----------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------+
| wsrep_local_state_uuid | 7cc2ecbe-6a46-11e4-9475-12a09a60a153 |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 1302900 |
| wsrep_replicated | 5976 |
| wsrep_replicated_bytes | 3668948 |
| wsrep_repl_keys | 18144 |
| wsrep_repl_keys_bytes | 282612 |
| wsrep_repl_data_bytes | 3003872 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 14326 |
| wsrep_received_bytes | 8668980 |
| wsrep_local_commits | 5976 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 2 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000163 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 771 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 21.064359 |
| wsrep_local_cached_downto | 1282779 |
| wsrep_flow_control_paused_ns | 255319480 |
| wsrep_flow_control_paused | 0.000015 |
| wsrep_flow_control_sent | 3 |
| wsrep_flow_control_recv | 5 |
| wsrep_cert_deps_distance | 68.694613 |
| wsrep_apply_oooe | 0.069655 |
| wsrep_apply_oool | 0.000155 |
| wsrep_apply_window | 1.178809 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.116384 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 66 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.005765 |
| wsrep_incoming_addresses | 10.77.77.1:3306,10.77.77.2:3306,10.77.77.3:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0.000621526/0.00070109/0.000757882/5.79492e-05/3 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | 7b7a2512-d13d-11e4-a2d5-5e582d8fef8e |
| wsrep_cluster_conf_id | 92 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | 7cc2ecbe-6a46-11e4-9475-12a09a60a153 |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 0 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 3.9(r93aca2d) |
| wsrep_ready | ON |
+------------------------------+----------------------------------------------------------+

Here you can see that the node is correctly in the cluster and synced with the others.

This is the full list of WSREP status variables.  For reference, you might also want to have a look at the list of WSREP system variables which specify how the node is configured for replication.

2 réponses

Trackbacks (rétroliens) & Pingbacks

  1. […] and so on. This was explained in a previous blog post. […]

  2. […] In a previous blog post I wrote about the steps to take to troubleshoot and restore in its working state a Percona database cluster.  This blog article adds some more information. […]

Laisser un commentaire

Participez-vous à la discussion?
N'hésitez pas à contribuer!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.