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

PREVIOUS POST
NEXT POST

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.

PREVIOUS POST
NEXT POST

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. says

    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.)

Leave a Reply

Your email address will not be published. Required fields are marked *