MySQL Setup Migration: S3 to EBS Stripe (11H1)

Objective

To migrate an existing MySQL EBS database setup that is using the MySQL-S3 ServerTemplate ("MySQL Bootstrap" and "MySQL Additional") to the one of the 11H1 ServerTemplates (Database Manager with MySQL 5.0 - 11H1 or Database Manager with MySQL 5.1 - 11H1), which supports EBS volume striping and other enhancements that are not available in the MySQL EBS v1 ServerTemplate. 

Table of Contents

Overview

Steps

Follow the steps below to migrate from a MySQL S3 setup where backups of the database are saved directly to S3 as *.tar files to a setup that uses a set of striped EBS volumes.  

• Prerequisite: A deployment with a running MySQL master database server (launched using a revision of the "MySQL Bootstrap" ServerTemplate)
• Clone the existing deployment.
• Go to Design -> MultiCloud Marketplace -> ServerTemplates.  In order to perform the migration, you will need to import the following to your account:
  • ServerTemplate: Database Manager with MySQL 5.0 - 11H1 or Database Manager with MySQL 5.1 - 11H1
  • RightScript: "DB EBS create migrate script from non-EBS to stripe volume"  (You can also access this RightScript by importing the Database Manager with MySQL 5.0 Toolbox - 11H1 ServerTemplate.)
• Add a server into the cloned deployment using the appropriate Database Manager with MySQL - 11H1 ServerTemplate.
• Delete any database servers using the old "MySQL Bootstrap" or "MySQL Additional" ServerTemplate from the cloned deployment. 
• Define the following inputs in the cloned deployment. You should define these inputs at the deployment level.
  • DB_LINEAGE_NAME - This input is used to name newly created EBS snapshots, and later to locate the most recent EBS snapshot for restorations. There will be an EBS snapshot for each EBS volume in the stripe. For organizational purposes, you should use a different name than what you are currently using for the other ServerTemplates (e.g. mydb-stripe).
  • DB_EBS_SIZE_MULTIPLIER - The factor by which you would like to multiply the current size of your database so that there is room for it to grow. The value will determine the total size of the stripe. For example, assuming your current database is 3 GB and you have a stripe count of 3, if you set this value to 2, this will create 3 EBS volumes in the stripe where each volume is 2 GB (for a total of 6GB).
  • EBS_STRIPE_COUNT - Specify the number of striped EBS volumes (e.g., 1, 2, or 3). If you do not want to use EBS striping, set this value to 1. Preliminary results from RightScale's own performance testing has shown that stripe counts of 1 or 4 often yield the best performance.
• Launch the 11H1 server.  Ensure that INIT_SLAVE_AT_BOOT is set to "False"; otherwise, the server will enter the "stranded in booting" state. Note: Double-check the my.cnf files on both servers, to make sure that the settings in both files match what is desired.
• Go to the 11H1 server's Scripts tab.  Next, you will use the "Any Script" option to execute a RightScript that will initialize the server as a slave database server and then create and attach a set of striped EBS volumes to the server.  Since replication can take a long time to complete, you will need to manually run the script on the server itself. But first, you need to add that script to the server. Select the "DB EBS create migrate script from non-EBS to stripe volume - 11H1" script from the list of imported RightScripts and choose to run it on the current server, which will import the script onto that server. When the input verification screen appears, override the following input parameter:
  • DB_EBS_PREFIX - Specify the same value that you used for the BACKUPFILE_PREFIX input in the "Bootstrap/Additional" ServerTemplates (e.g. mydb) so that the server can initialize as a slave database server by using a non-EBS backup created using the "Bootstrap" ServerTemplate.  When you execute the RightScript, a striped EBS backup is created; however, it will be of your old database.
• Next, you must manually run the script that was just added to the server. SSH into the server and run the following command

/tmp/init_slave.sh

• Once the script is 100% complete, the server will be a slave database server with a set of EBS striped volumes; however, it will be replicating with the old master database server in your original deployment.
• Run the DB EBS backup - 11H1 operational script to create snapshots (backups) of each volume in the EBS stripe.
• Wait for all of the backups to be completed.  For example, if your stripe count is 3, you must wait for all 3 EBS Snapshots to be 100% complete before proceeding to the next step. To track the status of the snapshots, go to Clouds -> AWS Region -> EBS Snapshots.
  
  
  You will notice that each EBS snapshot has the same nickname; but, if you take a closer look at each snapshot, you'll notice that its associated tags are used to properly configure a set of striped EBS volumes.  Therefore, it's important that you never delete any of the snapshot's tags.
  
• You now have a slave database server that is using the new 11H1 ServerTemplate.  You can now launch multiple slave servers in the cloned deployment since you can restore using a slave backup with the 11H1 ServerTemplate.  Be sure to set the INIT_SLAVE_AT_BOOT input to "true" on new slave servers when they're launched.  For example, you might want to launch additional slaves in order to test the performance benefits of using different EBS stripe counts.
• If you want to make the slave server the new master database server, run the DB EBS promote to master - 11H1 operational RightScript.  It will also create your first "master" backup of the striped EBS volumes.
• Later, you can add another server to the cloned deployment using the 11H1 ServerTemplate, and successfully launch a new slave database server—except that this time, it will use the DB_LINEAGE_NAME input (e.g. mydb-stripe) for the cloned deployment to find the correct set of backups (EBS snapshots) to create and attach all of the EBS volumes in the stripe. The new slave database server will replicate with the new master database server in the cloned deployment.
  

See also

• FAQ 137