CDP:DB Replication Pattern

From AWS-CloudDesignPattern
Revision as of 00:34, 28 November 2012 by Cdpadmin (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Architect

Replicating Online Databases

Contents

Problem to Be Solved

The basic technique for saving data that is important to the system is that of storing it in a database. Recently the use of database replication functions has been becoming increasingly widespread. While replication is performed relatively commonly, in the past this has usually been limited to being within a given datacenter, due to the costs involved. However, it is important to think about cases where the entire datacenter may be damaged. (Major disasters, such as the Great Eastern Japan Earthquake, have actually caused such cases.)

Explanation of the Cloud Solution/Pattern

This is a pattern that lets you perform replication crossing geographic locations. This pattern lets you prevent data loss and maintain data access availability. While this is a pattern that was used even before Cloud technology, the use of cloud technology enables inexpensive use of multiple geographic locations, making such distribution a practical option.

Implementation

In AWS, there are the concepts of "regions" and "Availability Zones" (AZs). A "region" is the broader concept, where there are multiple AZs within the Tokyo Region, for example. In consideration of this point, you can locate EC2 instances transparently in different datacenters, enabling database replication to those different datacenters. You can use a Multi-AZ Amazon Relational Database Service (RDS) to achieve replication across AZs with ease. Of course, databases may be installed in EC2 instances to achieve this instead.

  • Locate two EC2 instances in AZs of different geographic locations.
  • Install Relational Database Management Systems (RDBMS) in each of the EC2 instances and set up the replication.

Configuration

2XNdewVsgellO3x8-4DA5B.png

Benefits

  • This makes it possible to continue the operations without loss of data, even in the case of a disaster or failure.
  • Switching the access destination to the replicated database lets you apply a patch to a database without shutting down the system.

Cautions

  • While this makes fail-over to the slave possible when a failure has occurred in the master database, be aware that the fail-over will require some downtime.

Other

  • For the purposes of disaster recovery, set up replication for databases to locations that are far apart geographically (in different regions).
  • When replicating to a database in another region, there may be some loss in performance when synchronous replication is used. In this case, consider asynchronous replication or periodic replication.
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox