Change the Total Size of the Volume Stripe
Table of Contents
Objective
To either grow or shrink the total size of the current volume stripe that is being used by a running MySQL database setup with zero downtime.
Background
Over the lifecycle of your database, it may become necessary to change the total size of the stripe of volumes that are being used to store your MySQL data. Typically, you will want to grow the size of the database, but there may be some scenarios where you will want to shrink the size of the volume stripe. Fortunately, the steps to perform both actions is relatively the same. There are several different ways to grow the size of your database setup.
- Keep the number of volumes in the stripe the same, but increase the total size of the stripe
- Keep the volume settings the same, but increase the instance size of the database servers to increase performance (See Upgrade Database Servers)
- Increase the number of volumes in the stripe (See Change the Number of Volumes in a Stripe)
This tutorial will only focus on the first scenario.
Since each application and database is unique, you will need to perform some sandbox tests to determine which changes make the most sense for your project.
Things to Consider
- Cost - Remember, if you're leveraging volumes in a public cloud like Amazon, cost will definitely be a factor that you'll want to take into consideration because your overall costs will be affected by the size of the instance, as well as the size of each volume. Storage costs of your snapshots (e.g. frequency and archive settings) should also be taken into consideration.
- Time - If you want to decrease the amount of time it takes to perform a backup, perhaps you'll want to increase the numbers of volumes in your stripe. For example, if you are using a single volume that's 100GB, you can decrease the amount of time to perform a backup by 4x if you migrate to a stripe of four 25GB volumes.
- Performance - Perhaps a volume stripe of four will give you optimal performance, but it might not be cost effective for your project. Or maybe you simply need to change from a 'small' to a 'large' instance type to take advantage of the added CPU power.
Ultimately, you must perform the necessary tests to determine which combination best suits your needs.
Steps
Below are the steps that you will need to make modifications to your volume stripe. These steps assume that you have an operational master-slave database setup.
- If you haven't already done so, import the appropriate "Database Manager for MySQL 5.0 Toolbox - 11H1" ServerTemplate which contains several useful scripts including the one that you will need to run to perform the upgrade.
- Go to your Deployment (Manage -> Deployments).
- Clone the Slave-DB Server and rename it. (e.g. DB3) This Server will eventually become your new Master-DB, so you might want to change its zone settings so that it's launched into the same zone as the current Master-DB. At this point, you also have the option of changing the instance size. However, be sure to select the appropriate MCI so that an image with the appropriate architecture will be used.
- Launch the cloned Server. Make sure INIT_SLAVE_AT_BOOT = False. Wait for the Server to become operational.
- Before you grow the size of the volume stripe, you'll need to temporarily disable continuous backups. Run the "DB Freeze binary backups" script on both the Master-DB and Slave-DB Servers.
- You are now ready to change the total size of your stripe. Go to the Scripts tab of the cloned (DB3) Server. Under the "Any Script" section, run the script for attaching volumes of a different size to the cloned Server. It is one of the scripts in the 'Toolbox' ServerTemplate that you imported earlier. Choose the appropriate script based upon which MySQL ServerTemplates you're using for your database setup.
- "DB EBS slave init and grow stripe volume - 11H1" script from the 'Toolbox' ServerTemplate. You'll need to specify values for any missing inputs: EBS_TOTAL_VOLUME_GROUP_SIZE - Enter the new total size for the EBS Stripe.
- Wait for the volumes to be created and for the data on the new Slave-DB (DB3) Server to become in-sync with the Master-DB. See Checking master or slave database status.
- Next, run the script to promote the new Slave-DB (DB3) Server to become the new Master-DB. Go to the new Slave-DB's Scripts tab. Run the "DB EBS promote to master" Operational Script. The existing Master-DB will switch roles and become a slave of the new master. A backup will also be created, except this time the snapshots will be of the larger volumes.
- Wait for the backup snapshots to be 100% complete.
- Clone the new Master-DB server and rename it. (e.g. DB4) This Server will become your new Slave-DB with the larger volume stripe. You may want to change its zone settings so that it's launched into a different zone than the new Master-DB.
- Launch the new (DB4) Server. Except this time, set INIT_SLAVE_AT_BOOT = True.
- Re-enable continuous backups on the new Servers (DB3 and DB4). Run the "DB unfreeze binary backups" script on both Servers.
- Once you're satisfied with your upgraded setup and no longer need the old (original) Servers, you can safely terminate them using the "DB TERMINATE SERVER - Delete EBS volume and halt" Operational Script so that the attached volumes will be automatically deleted when the Servers shut down.
What feedback to expect
The Events pane will highlight the progress of the operation. Click on the name of an action in the pane to view a detailed output of the action that can be used to troubleshoot the cause of a failure, if necessary.
- © Copyright 2015 RightScale Technical Support