|Table of Contents|
| || |
Long Term Support
Stable, tested ServerTemplate assets
Configures a MySQL 5.5 database server. This ServerTemplate provides a high-availability master/slave database configuration that can be used as the backbone for a variety of applications and workloads.
The ServerTemplate supports multiple clouds, using either instance-based storage or attachable volumes. Instance-based snapshot backups are automatically uploaded to your choice of remote object storage (Amazon S3, Rackspace Cloud Files, SoftLayer Object Storage, etc.). It also includes iptables management for clouds that do not support cloud-level firewall services like security groups.
Note: For a complete list of the ServerTemplate's features and support, view the detailed description under its Info tab.
The ServerTemplate's recipes create a filesystem for storing data and taking LVM snapshots. If the database server is launched into a cloud that supports volumes, such as EBS volumes for EC2, volume storage will be used. However, if the cloud does not support volumes (i.e. Rackspace First Generation), the filesystem will be created on the instance's local ephemeral drive. In both cases, an LVM is created for data storage purposes so that the filesystem functions the same regardless of whether the data is stored on the ephemeral drive, a single mounted volume, or stripe of mounted volumes.
By default, an LVM will be created where 90% of the filesystem is used for data storage and 10% is reserved for taking LVM snapshots or restoring a database.
Note: Primary backups may fail if there is not enough space available to complete an LVM snapshot. Change the 'Percentage of the LVM used for data (1)' input accordingly depending on the size of the database and the number of database modifications that are made between backups.
The way in which you access your MySQL database server depends on your cloud provider. For Amazon EC2, CloudStack, and other clouds that support security groups, you must use security group(s) with the appropriate permissions set. See Deployment Prerequisites (Linux). For example, the database servers need to allow connections from the application servers over TCP port 3306 (the default MySQL port), as well as for master-slave database replication. In all clouds, regardless of whether they support security groups or not, Iptables is used to set IP-specific port permissions, which provides better firewall permission control than only using security groups because access permissions are IP-specific (not group-specific).
For example, the database server only listens for requests from servers defined in its Iptables configuration file. Remember, in most cloud infrastructures, you typically cannot control what private IP address is assigned to an instance. (e.g. EC2, instances are randomly assigned a private IP address at launch time.)
Before an application (e.g. PHP) can perform an action on a database (e.g. create a new record), the servers must first be granted access at the network-level before successfully making an application-level request.
Once the database server has updated its permissions to allow access between the application and database tiers, the application can connect to the database using the required information. For example, the application locates the "master" database server using the 'Database Master FQDN' input (e.g. master-db.example.com). The application accesses the database, which is defined by the 'Database Schema Name' input by using the username and password of a database user that has database access privileges, which is specified by the 'Database Application Username' and 'Database Application Password' inputs.
Similarly, the Slave-DB will start replicating with the Master-DB by logging into the MySQL database as a user with replication privileges using credentials specified by the 'Database Replication Username' and 'Database Replication Password' inputs.
The following scenario explains how iptables and tags are used to configure secure firewall permissions in the cloud.
If you need to open other ports on a database server besides the default TCP ports (22, 80, 443, and 3306), you must create the appropriate rules using the "Firewall" inputs, as described in the Base ServerTemplate for Linux (Chef) documentation.
Note: For more information about iptables, refer to the Linux supporting documentation for this tool.
The ServerTemplate contains scripts that can retrieve a MySQL database dump file from one of the following Remote Object Storage (ROS) locations:
Use the following inputs to provide the required information to retrieve the dump file from the ROS container.
* If the dump file is a 'private' object in the ROS container, you must provide valid cloud storage credentials for authentication purposes.
For example, if my dump file (app_test-20121603072614.gz) is a 'private' object located in an Amazon S3 bucket called 'projectx-db', my inputs would look like the following.
The ServerTemplates support the use of multiple block devices where each block device can consist of a single volume or stripe of volumes. Although most users will only use one block device, some will find it useful to use two block devices. For example, you might use the first block device, which consists of a stripe of volumes for the main database, and the second block device for storing transactional log files in a single volume. Be sure to name the inputs accordingly depending on the block device. Related block device inputs will include the block device number in parentheses. (e.g. 'Total Volume Size (1)') By default, the ServerTemplates include inputs for up to two block devices, but if you need additional block devices, see Increase the Number of Block Devices.
The Database Manager for MySQL ServerTemplates published by RightScale support the use of primary and secondary storage locations for creating backups of databases.
Primary backups are designed to take the most efficient backup of your database based upon the best storage solution that's supported by the cloud provider in which your server is running. When you launch a database server and run an operational script to initialize it as either a master or slave, the operational script schedules a cron job to save backups as the primary storage type, which is automatically selected for you based on your cloud provider. For clouds that support volume-based storage and volume snapshots, primary backups are always saved as volume snapshots.
Below is a list of each supported cloud and its default primary backup storage solution. For clouds that do not support volume snapshots, you can use any ROS solution listed under the 'Primary Backup Storage Cloud (default)' input.
By default, the primary backup cron job runs once per hour on each "slave" server and once per day on the "master" server.
For clouds that support volumes, use the 'Nickname' input to name the volumes that are attached to the servers. By default, the input is set to "data_storage" so if you have multiple deployments within a RightScale account you should use a unique name for this input for organizational purposes. Otherwise, you will have to filter by tag to find the volumes that are specific to a deployment.
Secondary backup storage is designed to take backups to a remote cloud/region in the case of a cloud outage or database migration to another cloud provider. The Database Manager for MySQL 5.1/5.5 ServerTemplates also let you select a secondary backup location from the following available public-cloud remote object storage (ROS) providers:
Data is stored as .gzip files (or objects) in named ROS containers. Files are stored as private or public objects. By default, they will be stored as private objects that are only accessible to servers launched with the same cloud credentials.
While secondary backups are typically slower and more resource-intensive than volume-based primary backups, they are recommended and useful in disaster-recovery or cloud migration scenarios where you need to launch the database servers in a different cloud/region.
By default, secondary backups are performed manually (as needed) by running the db::do_secondary_backup operational script, as described in the Database Manager for MySQL 5.1/5.5 (v13.5 LTS) - Runbook.
By default, a cron job is configured on each database server once it's initialized as either a master or slave to take continuous backups.
The hour and minute of the backup is randomly generated at launch time, unless you use the following inputs to specify a more convenient time in standard crontab format.
By default, secondary backups are taken manually. However, if you want to create a cron job for taking secondary backups, use the following inputs to configure a time for taking secondary backups. Note: You do not have to create a cron job for taking secondary backups on both the master and slave database servers.
Warning! Unlike primary backups that are saved as volume snapshots and have an enforced, backup retention policy to keep the number of archived snapshots to a manageable number, there is no automatic clean-up of secondary backups. Therefore, if you have a large database, you may want to define a process for deleting the older secondary backups in order to reduce your monthly ROS data storage charges. You are responsible for manually deleting any secondary backups that you no longer wish to keep.
The most common customization of a MySQL database server is tuning the MySQL parameters to be more optimized for your own database. The MySQL ServerTemplate uses a default set of MySQL tuning parameters that is typically sufficient for most common MySQL databases. However, as you become more familiar with the performance characteristics of your database you may want to modify some of these parameters accordingly.
Note: The locations below apply to the following revision of the ServerTemplate: [rev 8]
MySQL Tuning Parameters (Default)
The default MySQL tuning parameters.
The exhaustive MySQL configuration file.
To learn how to override the default settings, see Override Chef Cookbooks.
This ServerTemplate supports replication between master and slave database servers located in different clouds/regions. In such use cases, replication must be performed over the public network. Therefore, it's strongly recommended that you set up secure replication using SSL to encrypt the transfer of the data and logs.
Use the following inputs to configure both the master and the slave database servers to support SSL network connections.
To learn how to set up a multi-cloud database setup using SSL, see MySQL Database Replication Across Clouds - Tutorial.
By default, log data files will expire after two (2) days (as defined by the 'MySQL Expire Logs Days' input). Logs are either saved locally on the ephemeral disk (default) or sent to a dedicated logging server or service. See Logging with rsyslog (v13.5 LTS).
|Glossary | 用語 | 용어||Site Map | Site Help||Community||Corporate Site||Get Support||Dashboard Login|
|Doc Feedback||Product Feedback||Resources||MultiCloud Marketplace||Forums|
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.