Is there a way to show the Cluster database's uptime?

Obviously I can see each individual node's database uptime with the likes of:

select TIME_FORMAT(SEC_TO_TIME(VARIABLE_VALUE ),"%Hh %im") as Uptime from information_schema.GLOBAL_STATUS where VARIABLE_NAME="Uptime";

But this is not the same as the time the cluster database has been operating without interruption...?

(and longest time of all the nodes would not necessarily give an approximation either as nodes can come and go, but the DB should still be up) (there doesn't see to be a suitable status variable, including wsrep variables)

  • 1
    File a feature request with MariaDB or Codership. – Rick James Sep 18 '17 at 17:13
  • Good idea - have done so, will see what happens - still feel this is something that should already be available... so they may come back with an answer anyway – user3566845 Sep 18 '17 at 20:21
  • @user3566845 please post the link to the bug report. Thanks – Ivanov Sep 23 '17 at 7:19

I didn't know a good answer to this myself, but thought it was a good question and that it would be a good feature to have. So I asked for ideas in Codership's Google group (here). You're right that there aren't any obvious status variables for this, but two methods were suggested:

  1. Assuming you access the cluster through a DB proxy, then use a monitoring tool (Nagios, Zabbix, maybe PMM, maybe MONyog, ...) and log the availability of the cluster. Uptime is then the time since the last failure.
  2. grep the error log on each of the cluster nodes to find the timestamp of the most recent bootstrap. This coincides with the timestamp for when the status variable wsrep_cluster_conf_id is equal to 1, and can be found in the error log with something like:

    grep -e conf_id -e 'Quorum results' node1.err | grep '= 1,' -B 1

I suppose these two methods give a different perspective of 'uptime': The first method is more from the applications' point of view, and the second method is from the cluster's point of view. They may not always give the same answer since the cluster could be "up", but not necessarily always in a state that makes it accessible. Also, there could be network issues between the application and the DB proxy, and between the DB proxy and the cluster, which would make the cluster seem "down" from the applications' point of view, but in reality it is still "up".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.