Warning: This page contains outdated or otherwise non-applicable product information, and has been deprecated. Please use the RightScale Support Portal's search feature to search for up-to-date information on this topic.
To migrate an existing MySQL EBS database setup that's using the v1 ServerTemplate ("MySQL EBS v1") to the newer v2 ServerTemplate ("MySQL 5.x EBS v2"), which supports EBS striping and other enhancements that are not available in the v1 ServerTemplate.
Note: This tutorial only applies to migrations of MySQL 5.0 databases. If you want to upgrade from MySQL 5.0 to MySQL 5.1, you are responsible for ensuring that your database is compatible before performing a migration with the "MySQL 5.1 EBS v2" ServerTemplate. If you perform this type of migration you will need to disable MySQL version checking (OPT_DB_RESTORE_VERSION_CHECKING = "False").
Table of Contents
The v2 ServerTemplates support the option of using a set of striped EBS Volumes for the database. Although this tutorial assumes that you are going to take advantage of the EBS striping capability, it is not required. You can still migrate to the v2 ServerTemplate and continue to use a non-striped EBS volume for backups (EBS_STRIPE_COUNT=1).
- Note: You cannot restore a backup taken from a MySQL EBS Server with striping onto a Server that does not support EBS Stripes. (See FAQ 137 for alternative solutions.)
What's new in the v2 ServerTemplate?
- Support for EBS stripes. One of the benefits of EBS stripes is enhanced disk performance. Internal tests have shown that a stripe count of 1 or 4 often yield the best performance, but you should test different stripe counts to see what works best for your application. For a more specific discussion, please see AWS Forums (search topic: EBS stripe).
- Restore from a slave backup. Previously, a backup (EBS Snapshot) of the Master-DB was required in order to launch a Slave-DB. The v2 ServerTemplates are designed to launch a new Slave-DB using the most recent backup regardless of whether it's from a master or slave. The ability to restore from a slave backup will reduce the amount of time needed for database replication. As a result, the Slave-DB Server should come online faster and become in-sync with the Master-DB within a shorter timeframe.
- Support for MySQL 5.0 and MySQL 5.1
There are potentially two migration paths to start using the v2 ServerTemplate:
- EBS v1 to EBS Stripe v2 - Follow steps below.
- S3 to EBS Stripe v2 - See MySQL Setup Migration: S3 to EBS Stripe v2.
Follow the steps below to migrate from a standard (or regular) MySQL EBS setup that uses a single EBS volume to a setup that uses a set of striped EBS volumes.
- Prerequisite: A Deployment with a running MySQL EBS Master-DB server (launched using a revision of the "MySQL EBS v1" ServerTemplate)
- Clone the existing Deployment
- Go to Design -> MultiCloud Marketplace. In order to perform the migration you will need to import the following components.
- ServerTemplate: "MySQL 5.0 EBS v2" or "MySQL 5.1 EBS v2"
- RightScript: "DB EBS create migrate script from MySQL EBS v1 to stripe volume" (You can also gain access to this RightScript by importing the "MySQL EBS Toolbox v2" ServerTemplate.)
- Add a Server into the cloned Deployment using the "MySQL 5.0/5.1 EBS v2" ServerTemplate.
- Delete any database Servers using the old v1 ServerTemplate from the cloned Deployment so that only inputs related to the v2 ServerTemplates will be visible.
- Define the following Inputs in the cloned Deployment. You'll want to define these Inputs at the Deployment level.
- DB_LINEAGE_NAME- This input is similar to the DB_EBS_PREFIX input in the "MySQL EBS v1" ServerTemplate, except it will be used to locate the set of backup EBS Snapshots. There will be an EBS Snapshot for each EBS Volume in the stripe. Important! It's absolutely imperative that you use a different name than you are currently using for the v1 ServerTemplates in order to keep your backups separate from each other. Otherwise, a v1 Server will try to restore using a striped EBS volume or a v2 Server will try to use a non-EBS striped volume. (e.g. mydb-stripe)
- Launch the v2 Server. Make sure INIT_SLAVE_AT_BOOT is set to "False" otherwise the Server will become "stranded in booting."
- Go to the v2 Server's Scripts tab. Next, you will use the 'Any Script' option to perform a one-time execution of a RightScript that will initialize the Server as a Slave-DB 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 MySQL EBS v1 to stripe volume" script from the list of imported RightScripts and run the RightScript, which will write the appropriate script on the current server. When the Input verification screen appears, you will need to override the following Input parameter:
- DB_EBS_PREFIX - Specify the value that you used for the DB_EBS_PREFIX in the v1 ServerTemplate (e.g. mydb) so that the Server can initialize as a Slave-DB Server by using a non-striped backup (EBS Snapshot) that was created using the v1 ServerTemplate. The most recent completed backup will be used. When you execute the RightScript, a striped EBS backup will be created, however it will be of your old v1 database.
- EBS_STRIPE_COUNT - Specify the number of striped EBS volumes. (e.g. 1, 2, 3) If you do not want to use EBS striping, set this value to one. Preliminary results from RightScale's own performance testing has shown that stripe counts of 1 or 4 often yield the best performance.
- DB_EBS_SIZE_MULTIPLIER - The factor by which you would like to multiply the current size of your EBS volume (not the actual size of the database) so that there is room for the database to grow. The value will determine the total size of the stripe. For example, assuming your current volume is 3GB and you have a stripe count of 3, if you set this value to double the size (e.g. 2), it would create 3 volumes in the stripe where each one was 2GB EBS volume (total = 6GB).
- Next, you will need to manually run the script that was just added to the server. SSH into the server and run the following command
- Once the data streaming has been 100% completed, it will be a Slave-DB Server with a set of EBS striped volumes, however it will be replicating with the old Master-DB in the original Deployment.
- Run the "DB EBS backup" 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 going to the next step. (e.g. mydb-stripe200912022311) To track the status of the snapshots, go to Clouds -> AWS Region -> EBS Snapshots.
Note: Each EBS Snapshot will have 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-DB that's using the new v2 ServerTemplate. You can now launch multiple Slave-DB Servers in the cloned Deployment since you can restore using a slave backup with the v2 ServerTemplate. Be sure to set the INIT_SLAVE_AT_BOOT 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-DB your new Master-DB, run the "DB EBS promote to master" 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 v2 ServerTemplate and successfully launch a new Slave-DB Server, except this time it will use the DB_LINEAGE_NAME Input (e.g. mydb-stripe) of 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-DB will replicate with the new Master-DB in the cloned Deployment.