July 24, 2014

High availability for MySQL on Amazon EC2 – Part 5 – The instance monitoring script

This post is the fifth of a series that started here.

From the previous posts of this series, we now have nearly everything setup, only a few pieces are missing. One of the missing pieces is the Pacemaker script that run on the MySQL instance.

First, this script is optional, Pacemaker will accept a noop bash script but since we have the opportunity to run a script on the MySQL host, let’s take it. At minimum, let’s use mysqladmin to ping the database to see if it is available. If not, the recommended action is to stop the heartbeat service (pacemaker). Stopping Pacemaker will trigger a resource transfer to the monitoring instance which will in turn cause the running MySQL instance to be killed and a new one started. Here is a simple instance script, more complex ones are obviously possible.

About Yves Trudeau

Yves is a Principal Consultant at Percona, specializing in technologies such as MySQL Cluster, Pacemaker and DRBD. He was previously a senior consultant for MySQL and Sun Microsystems. He holds a Ph.D. in Experimental Physics.

Comments

  1. Justin says:

    What kind of write performance can be expected out of this sort of configuration? One of the issues I’ve heard about with AWS is write speed across the internal network causing latency issues between nodes in the cluster. Did you experience anything like that?

  2. Rik says:

    Good advice would be to _never_ add a username & password this way, it is plainly visible to all users who can run ps. Not an issue if you are certainly the only user, but still inadvisable.

    Use mysql(admin) –defaults-file=/path/to/file/with/settings, and sane file permissions for that file.

  3. The password will actually appear as xxxxxx in ps output on most systems. (I do agree with your suggestion though. I have had many a customer forget to tell me the password, and I find it from the history file easily.)

Speak Your Mind

*