MySQL Replication Tutorial For Disaster Recovery

This blog post is a step by step tutorial on how to set up MySQL Replication between AWS regions. This is an essential part of our disaster recovery plan at Engine Yard. A previous blog post gives a higher level overview on disaster recovery.

Read More

The Importance of Testing Database Backups

Catching some attention in technology headlines this week, GitLab suffered a major loss of database data and had a long and difficult recovery due to a combination of failing and untested backup and recovery strategies. We commend their openness in responding to this incident and several members of our team benefitted from joining the public livestream of their recovery efforts.

Observing this unfold in realtime encouraged us to take a step back and think about our backup and recovery strategies, and whether we are really doing enough to encourage our customers to test and understand this critical part of their application services. This also was a driving force behind the development of a brand new tool, eyrestore, which is designed to make the restoration of logical backups easier between different Engine Yard environments.

Read More

Stable V5 Is Now The Default Stack

As mentioned in a previous announcement, Engine Yard has released our latest stack, stable v5. With many feature enhancements and stabilization in the past three months, we are thrilled to announce that we have made stable v5 the default stack for the Engine Yard PaaS platform.

Read More

Faster Database Transfers

Sometimes it becomes necessary to move your database from one environment to another. Common reasons for this include:

  • Updating a Testing or Development environment with Production data
  • Migrating from one stack version to another (e.g. Stable-v4 -> Stable-v5)
  • Upgrading to a newer major version of your database (e.g. MySQL 5.5 -> MySQL 5.6 or Postgres 9.2 -> Postgres 9.4)
  • Upgrading storage to Encrypted EBS
  • Upgrading the filesystem to EXT4

The traditional method involves three database related steps:

  1. Creating an on-demand backup in the source environment.
  2. Downloading the most recent backup in the source environment.
  3. Transferring and Restoring the backup from the source to the target environment.

This results in some time and processing inefficiency since using eybackup uploads the backup to s3 and then it needs to be downloaded as a separate operation. For a small database this works just fine; unfortunately, for large databases this extra step could add hours to your migration plan. A better way to approach this would be to use the database-native backup tools to backup the source database to a file, and then transfer that file to the destination for restore.

Read More

Subscribe Here!