Managing your database with Cloud 66
About deploying databases
We currently support the following databases, with no need for additional configuration after deployment.
- MySQL (or Percona if configured via Manifest)
- SQLite (only in development environments)
For Rack-based stacks, Cloud 66 automatically detects whether your application relies on a database or not during your code analysis. This is based on a combination of your Gemfile and your
After you have analyzed your code, ensure that your desired database type is displayed in the About your app section of the analysis results. If you haven’t specified a username and password for your database, Cloud 66 will automatically generate these credentials for you. They will be available as environment variables and your application will be configured to use them.
Database deployment types
No database (external)
This option allows you to deploy your application without a database managed by Cloud 66, and is ideal if it is hosted externally. Please note that if there is no connectivity to your database, or your database host is not configured correctly, the deployment will fail.
This option deploys your chosen database to the same server as your web server - this is intended primarily for development, as running your database locally in production is not advised. In this case, your application database configuration will be amended to target your local database server. If you scale up your web server, these settings will also be amend automatically to reflect your database configuration.
This option will automatically create a new server for your database and configure your application accordingly.
Upgrading your database
Cloud 66 will not do in-place database upgrades, because this process may cause your application to stop working or may not be possible automatically. To upgrade your database through Cloud 66, we recommend that you create a new stack (at which point Cloud 66 will deploy the newer database version).
Once the new stack is created, you can migrate data from your old stack to your new stack.
Control your Rails database migrations
Cloud 66 chooses a server to perform the migrations - all other servers will wait until the migrations are finished before continuing with deployment. You can see which server performs the migrations in the Stack Information page, and change it using the
c66.migrations.run reserved tag.
You can control your Rails database migrations by setting
run.deploy.command option through Stack settings via
Toolbelt which gives you the option of running migrations or not.
$ cx settings set -s my_stack run.deploy.command true
When you have disabled
run.deploy.command in Stack settings , you still have the option to run migrations on a one-off deployment by clicking Deploy -> Deploy with options and selecting Run database migrations.
Customize your database configuration
You can customize the database configuration on your servers using CustomConfig. CustomConfig is available for MySQL, PostgreSQL, Redis and MongoDB.
Editing and committing your database CustomConfig will perform the following steps on every database server in your stack, one by one, sequentially:
- Check your template for Liquid syntax errors
- Determine the correct server configuration and prepare general variables
- Prepare custom variables for your database type (eg. server_state)
- Compile the database configuration based on the information from the server and database type
- Upload the configuration to the server
- Restart your database
A bad database configuration might stop your database from working. Take extra care to make sure the configuration is correct.
Database customization variables
There are a number of variables available for use in your database CustomConfig. Some are general for all database types, while others are database specific.
The following variables are available to any database CustomConfig.
|server||Hash||Hash containing information about your server|
|memory||integer||Server memory size (bytes)|
|core||integer||Server core count|
The following variables are only available in the MySQL CustomConfig.
|server_state||string||Value can be stand_alone, mysql_master or mysql_slave based on your server status|
|server_id||integer||An ID used by MySQL replication to identify your server*|
*It is 0 for standalone servers, 1 for master servers and a number greater than 1 for slave servers
The following variables are only available in the PostgreSQL CustomConfig.
|server_state||string||Value can be stand_alone, pg_master or pg_slave based on your server status|
The following variables are only available in the Redis CustomConfig.
|server_state||string||Value can be stand_alone, redis_master or redis_slave based on your server status|
|master_address||string||IP address of replication master (empty string if server is stand alone or master)|
|master_port||integer||Will be 6379 when server is redis_slave , otherwise it is 0|