Management¶

Restarting the cluster¶

Individual cluster nodes can stop and be restarted without issue. When a database loses its connection or restarts, the Galera Cluster brings it back into sync once it reestablishes connection with the Primary Component. In the event that you need to restart the entire cluster, identify the most advanced cluster node and initialize the Primary Component on that node.

To find the most advanced cluster node, you need to check the sequence numbers, or the seqnos, on the last committed transaction for each. You can find this by viewing grastate.dat file in database directory:

$ cat /path/to/datadir/grastate.dat

# Galera saved state
version: 3.8
uuid:    5ee99582-bb8d-11e2-b8e3-23de375c1d30
seqno:   8204503945773

Alternatively, if the database server is running, use the wsrep_last_committed status variable:

SHOW STATUS LIKE 'wsrep_last_committed';

+----------------------+--------+
| Variable_name        | Value  |
+----------------------+--------+
| wsrep_last_committed | 409745 |
+----------------------+--------+

This value increments with each transaction, so the most advanced node has the highest sequence number and therefore is the most up to date.

Deployment strategies¶

Galera can be configured using one of the following strategies:

• Each instance has its own IP address:

  OpenStack services are configured with the list of these IP addresses so they can select one of the addresses from those available.

• Galera runs behind HAProxy:

  HAProxy load balances incoming requests and exposes just one IP address for all the clients.

  Galera synchronous replication guarantees a zero slave lag. The failover procedure completes once HAProxy detects that the active back end has gone down and switches to the backup one, which is then marked as UP. If no back ends are UP, the failover procedure finishes only when the Galera Cluster has been successfully reassembled. The SLA is normally no more than 5 minutes.

• Use MySQL/Galera in active/passive mode to avoid deadlocks on SELECT ... FOR UPDATE type queries (used, for example, by nova and neutron). This issue is discussed in the following:

  • IMPORTANT: MySQL Galera does *not* support SELECT ... FOR UPDATE
  • Understanding reservations, concurrency, and locking in Nova

Configuring HAProxy¶

If you use HAProxy as a load-balancing client to provide access to the Galera Cluster, as described in the HAProxy, you can use the clustercheck utility to improve health checks.

1. Create a configuration file for clustercheck at /etc/sysconfig/clustercheck:

   MYSQL_USERNAME="clustercheck_user"
   MYSQL_PASSWORD="my_clustercheck_password"
   MYSQL_HOST="localhost"
   MYSQL_PORT="3306"
   

1. Log in to the database client and grant the clustercheck user PROCESS privileges:

   GRANT PROCESS ON *.* TO 'clustercheck_user'@'localhost'
   IDENTIFIED BY 'my_clustercheck_password';
   
   FLUSH PRIVILEGES;
   

   You only need to do this on one cluster node. Galera Cluster replicates the user to all the others.

2. Create a configuration file for the HAProxy monitor service, at /etc/xinetd.d/galera-monitor:

   service galera-monitor
   {
      port = 9200
      disable = no
      socket_type = stream
      protocol = tcp
      wait = no
      user = root
      group = root
      groups = yes
      server = /usr/bin/clustercheck
      type = UNLISTED
      per_source = UNLIMITED
      log_on_success =
      log_on_failure = HOST
      flags = REUSE
   }
   

3. Start the xinetd daemon for clustercheck. For servers that use init, run the following commands:

   # service xinetd enable
   # service xinetd start
   

   For servers that use systemd, run the following commands:

   # systemctl daemon-reload
   # systemctl enable xinetd
   # systemctl start xinetd