Yes, but instances are provisioned only with network interfaces on their data center's internal service network (ServiceNet). Connecting to a Cloud Database instance remotely requires either a Cloud Server or Cloud Load Balancer to proxy the connection.
Cloud Databases: FAQs
- Getting Started -
Each Cloud Database instance comes with an attached storage volume. Storage volumes are automatically provisioned on a shared Internet Small Computer System Interface (iSCSI) storage area network (SAN) that provides for increased performance, scalability, availability, and manageability. Applications with high I/O demands are performance-optimized and data is protected through both local and network RAID-10. Additionally, network RAID provides synchronous replication of volumes with automatic failover and load balancing across available storage clusters.
Every Cloud Databases instance is optimized for performance. Cloud Databases uses container-based virtualization, which eliminates the performance bottlenecks of the traditional hardware virtualization and enables your database to run at near bare metal speeds. It also uses dedicated SAN storage and high speed networking to give you faster access to your data.
Cloud Databases is a stand-alone, API-based, relational database service built on OpenStack® cloud that allows Rackspace customers to easily provision and manage multiple MySQL database instances. Instances are provisioned in a single-tenant, container-based environment per account and are accessible via the Rackspace internal ServiceNet network. Each database instance is optimized for performance. You can run a database instance with MySQL, Percona, or MariaDB as the database technology.
Cloud Databases provides a complete solution for customers demanding a high-performance, purpose-built infrastructure designed for relational databases backed and supported by engineers who specialize in MySQL workloads. Cloud Databases is a fully managed service for customers who want to focus on developing their applications and not worry about the underlying infrastructure. The service offers on demand backups and restores, integrated monitoring, redundant storage, scalability to grow based on your application needs, and full control of your database.
Any US or UK customer with a Cloud account will be able to provision multiple ServiceNet database instances, manage multiple databases and users (within resource limits). This service is also available to RackConnected Cloud Servers. Both First and Open Cloud Servers can connect to Cloud Databases, as well as any product with access to our internal ServiceNet network within the same regional datacenter.
No, Cloud Databases are available only to customers with Cloud account credentials. Managed Operations Service Level or Dedicated customers with RackConnect (that is those customers who also have a Cloud account) have access, but can use the service only with their Rackspace Cloud product resources.
Yes, Cloud Databases supports connecting to your instance using SSL. An SSL certificate is installed for each Cloud Databases instance that enables a secure connection between your application and the instance. When an SSL connection is established, any data transfer between the instance and application is encrypted.
The duration of the backup will depend on the size of your databases and any network saturation during the backup.
To restore a database backup, you must create a new database instance, specifying the backup that you want to restore during the create request. Your backup is loaded to the new instance, and you will receive a DNS endpoint for the new instance. After the restore operation is complete, you can update your application to use the new endpoint.
The original instance is not altered during a restore operation and may remain in use or be deleted through the API, CLI, or Control Panel.
There are no limits on how many database backups you can create. Note that you can run only one backup at a time; duplicate requests result in a 422 error.
Backups are not deleted when an instance is deleted. You must manually remove any stored backups.
The behavior of your instance during a backup depends on the storage engine that you are using for tables. If you use only InnoDB, write access to your database instance is not suspended. Conversely, if you have MyISAM tables, those databases are write-locked during the backup process.
MySQL supports several types of table engines, also know as table types. The tables on a Cloud Databases instance can use a mix of different table engine types or they can all use the same type. Currently we support backups of databases that use InnoDB and MyISAM.
Backups are stored in your Cloud Files account, and you are charged for storage used. Standard rates for Cloud Files storage apply. For current costs, see the Cloud Files pricing page.
Backups are created by using Percona XtraBackup to perform a hot copy of all databases on an instance. The resulting database files are streamed directly to your Cloud Files account for storage.
Manual backup and restore operations are currently supported from within the Control Panel. For more information, please read the article Managing Backups for Cloud Databases. Alternately you can manage backup operations via the Cloud Databases API, or by using the Trove command line tool (CLI).
Although Cloud Databases provides built-in data replication, as a best practice, we encourage our Cloud customers to back up their data using MySQL tools like mysqldump. Managed Operations Service Level customers can request assistance with backups from their support team.
Monitoring and Troubleshooting
The Cloud service level agreement (SLA) on the Rackspace website.
Monitoring is available for all Cloud Databases instances through pre-configured Cloud Monitoring checks, including load average, CPU, memory, disk storage, network, and a number of MySQL metrics. You can monitor your Cloud Databases instances using the Cloud Control Panel, the Cloud Monitoring API, or the Cloud Monitoring command-line tool.
You can also set up alarms to send you email alerts based on thresholds you define. An alert for disk space is set up by default for every instance. You can also use our Cloud Intelligence beta site to observe usage patterns or any unexpected changes in your environment.
Yes. A Cloud Databases support ticket category is available in the Cloud Control Panel.
Support coverage information for Managed Infrastructure and Managed Operations Service Level is available on the Cloud Databases support matrix page.
Yes, but by default all users created through the Control Panel, API, and command line interface (CLI) have full permissions.
To create read-only users, you first must enable the root user and use that user to generate and manage additional users with read-only privileges.
Yes. Currently, the root user can only be enabled via the public API or command line interface (CLI). We do plan to integrate this feature into the Cloud Control Panel at a later date.
Once root is enabled, it cannot be disabled.
Cloud Databases supports MySQL 5.6, Percona 5.6 and MariaDB 10. For all newly created Cloud Database instances, MySQL 5.6 is the default. We will continue to support MySQL 5.1 for legacy instances, but we recommend our customers use the latest version of MySQL, Percona, or MariaDB because they offer significant performance improvements and newer features. For more information to help you choose the right database version for your application, see Choosing the right data store.
The following table shows bandwidth, in megabits per second (Mbps), based on instance size.
|512 MB||20 Mbps|
|1 GB||100 Mbps|
|2 GB||200 Mbps|
|4 GB||300 Mbps|
|8 GB||400 Mbps|
|16 GB||500 Mbps|
Release notes, API documentation, and a getting started guide for Cloud Databases are all available on the Rackspace API Documentation site.
Yes. All accounts, by default, have a preconfigured set of thresholds (or limits) to manage capacity and prevent abuse of the system. The system recognizes two kinds of limits: rate limits and absolute limits. Rate limits are thresholds that are reset after a certain amount of time passes. Absolute limits are fixed at the account level. For the most up-to-date information about rate and absolute limits (which include instance and volume limits), see the Limits section in the Rackspace Cloud Databases Developer Guide.
If you cannot access your Cloud Databases instance, your data is still protected on a redundant SAN.
Cloud Databases provides several options for connecting to your database, giving you complete flexibility in how you access your database. For increased security, your database is available only on the Rackspace private network by default. However, you can connect to your database by using several methods described at the following links:
Additionally, you can use the Cloud Control Panel, API, or command line interface (CLI) to manage your database instance. Some of the features are not available in the Control Panel but can be accessed through API or through the CLI. More information about the API and CLI is located in the Cloud Databases API documentation, in both the API developers guide and the getting started guide.
You can set the default time zone for a Cloud Databases instance of MySQL by creating a configuration group that sets the
default_time_zone parameter to the offset from UTC (for example, "-6:00" for CST).
For more information, see Setting the time zone for a Cloud Databases instance.
Yes. Configuration settings for Cloud Databases instances can be stored and applied using the Cloud Control Panel and the Cloud Databases API. You can save your settings in configuration groups, and each configuration group can be applied to multiple instances. You can maintain multiple configuration groups to account for different workloads.
Access to MySQL is allowed only over port 3306; shell-level access is not available. Full MySQL access can be obtained by enabling the root user on the database instance.
The default storage engine is InnoDB, but other storage engines included with MySQL 5.1, such as MyISAM, also work for certain use cases.
InnoDB is the default storage engine for Cloud Databases. InnoDB enforces ACID transactions allowing for commit, rollback, and crash recovery capabilities to protect user data.
During a backup, a hot copy process is used on all tables. InnoDB tables record all transactions during the copy in order to replay them during a restore operation.
MyISAM tables are write-locked during the copy process in order to create a consistent backup. While the instance is being backed up you cannot add or delete databases, add or delete users, or delete, stop, or reboot the instance.
For more information about these engine types, see the MySQL documentation:
Details about maximum connections and access to my.cnf file settings per database size are listed in the following table:
|Size||Max connections||Max User Connections|
Instances can be provisioned with up to 64GB of memory and up to 300GB of disk storage. You can request additional storage by submitting a support ticket via the Cloud Control Panel.
Backups are currently not supported for HA instances for Cloud Databases. Rackspace will start supporting backups in a future release.
Resizing is not currently supported for HA instances for Cloud Databases. Rackspace will start supporting resizing for HA instances in a future release.
Technical architecture details are provided in the High Availability for Cloud Databases article.
Yes. Rackspace ensures that if the source database instance becomes unavailable, an automatic failover is initiated to the replicas within 10-30 seconds of downtime.
For the product introduction, Rackspace is charging the same price for HA instances as for single instances for a limited time. In the future, there will be an increase in the price of HA instances.
Rackspace currently supports MySQL 5.6, Percona 5.6, and MariaDB 10 for HA database instances.
You can add a maximum of two replicas to the primary source database instance. So you can have a maximum of three instances in the HA group, one primary and two replicas. In the future, we will increase the number of replicas that can be added to the HA group.
A Cloud Databases High Availability (HA) instance group includes a source database instance with one or two replicas. If the source database instance becomes unavailable, an automatic failover is initiated to one of the replicas. The automatic failover and promotion of the new instance is completed within a short downtime (approximately 10-30 seconds).
See the article High Availability for Cloud Databases.
You can choose any flavor from 1 GB to 64 GB for provisioning an HA instance group.
Yes. You can monitor replication using the monitoring agent installed on the instance. For more information, see Monitoring Read Replication in the API documentation.
No. You can only add replica of the same database type and version as your source database instance.
No. You can only add a replica in the same region as your source database instance.
When you add a replica to the source DB instance, the instance gets restarted. So your database will be unavailable until the instance restarts.
Each read replica added is charged the same way as a new instance.
Currently replication does not support auto failover. In case your database instance goes down and you would like to use replica instance for minimizing downtime, you will have to do a manual failover to the replica instances. For manual failover, you must detach the replica from the source instance and change the application endpoint to this new source database instance.
Replication is supported for MySQL 5.6, Percona 5.6, and MariaDB 10. We do not support replication for MySQL 5.1 as this is an older version of MySQL and there have been significant improvements for replication support in newer versions of MySQL. We highly recommend all users to upgrade from MySQL 5.1 to MySQL 5.6.
Pricing information is available at the Cloud Databases pricing page. Standard charges apply for any Cloud Servers, Cloud Load Balancers, or Cloud Sites that are used to access your Cloud Database instances.