Ec2 Instance Limitations; Deploying A Mysql Database Using Ec2 - Oracle 5.0 Reference Manual

Once you have configured your AMI with MySQL and the rest of your application stack, save the AMI
so that you can deploy and reuse the instance.
Once you have your application stack configured in an AMI, populating your MySQL database with
data should be performed by creating a dump of your database using mysqldump, transferring the
dump to the EC2 instance, and then reloading the information into the EC2 instance database.
Before using your instance with your application in a production situation, be aware of the limitations
of the EC2 instance environment. See
MySQL AMI, consult the notes on deployment. See
Using EC2".

15.4.2. EC2 Instance Limitations

Be aware of the following limitations of the EC2 instances before deploying your applications. Although
these shouldn't affect your ability to deploy within the Amazon EC2 environment, they may alter the
way you setup and configure your environment to support your application.
• Data stored within instances is not persistent. If you create an instance and populate the instance
with data, then the data only remains in place while the machine is running, and does not survive a
reboot. If you shut down the instance, any data it contained is lost.
To ensure that you do not lose information, take regular backups using mysqldump. If the data
being stored is critical, consider using replication to keep a "live" backup of your data in the event
of a failure. When creating a backup, write the data to the Amazon S3 service to avoid the transfer
charges applied when copying data offsite.
• EC2 instances are not persistent. If the hardware on which an instance is running fails, the instance
is shut down. This can lead to loss of data or service.
However, if you use EBS, you can attach an EBS storage volume to an EC2 instance, and that EBS
volume is persistent. Like a disk, an EBS volume can fail, but it is possible to create point-in-time
snapshots of the volume. Snapshots are persisted to Amazon S3 and can be used to restore data in
the event of volume failure.
• To replicate your EC2 instances to a non-EC2 environment, be aware of the transfer costs to and
from the EC2 service. Data transfer between different EC2 instances is free, so using replication
within the EC2 environment does not incur additional charges.
• Certain HA features are either not directly supported, or have limiting factors or problems that could
reduce their utility. For example, using DRBD or MySQL Cluster might not work. The default storage
configuration is also not redundant. You can use software-based RAID to improve redundancy, but
this implies a further performance hit.

15.4.3. Deploying a MySQL Database Using EC2

Because you cannot guarantee the uptime and availability of your EC2 instances, when deploying
MySQL within the EC2 environment, use an approach that enables you to easily distribute work among
your EC2 instances. There are a number of ways of doing this. Using sharding techniques, where you
split the application across multiple servers dedicating specific blocks of your dataset and users to
different servers is an effective way of doing this. As a general rule, it is easier to create more EC2
instances to support more users than to upgrade the instance to a larger machine.
The EC2 architecture works best when you treat the EC2 instances as temporary, cache-based
solutions, rather than as a long-term, high availability solution. In addition to using multiple machines,
take advantage of other services, such as
application to help reduce the load on the MySQL server so that it can concentrate on writes. On the
large and extra large instances within EC2, the RAM available can provide a large memory cache for
data.
EC2 Instance Limitations
Section 15.4.2, "EC2 Instance
Section 15.4.3, "Deploying a MySQL Database
to provide additional caching for your
memcached
1331
Limitations". To begin using your