Replication For Continuity: Myths And Realities

Over the past several months, I've been receiving a lot of questions about replication for continuity and recovery. One thing I've noticed, however, is that there is a lot of confusion around replication and its uses. To combat this, my colleague Stephanie Balaouras and I recently put out a research report called "The Past, Present, And Future Of Replication" where we outlined the different types of replication and their use cases. In addition to that, I thought it would be good to get some of the misconceptions about replication cleared up:

Myth: Replication is the same as high availability
Reality: Replication can help to enable high availability and disaster recovery, but it is not a solution in and of itself. In the case of an outage, simply having another copy of the data at an alternate site isn't going to help if you don't have a failover strategy or solution. Some host-based replication products come with integrated failover and failback capabilities. 

Myth: Replication is too expensive
Reality: It's true that traditionally array-based replication has been expensive due to the fact that it requires like-to-like storage and additional licensing fees. However, two factors have mitigated this expense: 1) several storage vendors are no longer charging an extra licensing fee for replication; and 2) there are several alternatives to array-based replication that allow you to use heterogeneous storage and come at a significantly lower acquisition cost. Replication products fall into one of four categories (roughly from most to least expensive):

  1. Array-based, or storage replication: Data is replicated between sites at the storage volume level using the resources of the storage system. Array-based replication usually requires homogeneous storage, but is host-agnostic.
  2. Appliance replication: An appliance continuously captures and tracks all data changes and can re-create virtualized snapshots at any point in time — also known as continuous data protection (CDP). The time-stamped data is then replicated to one or more sites, providing traditional disaster recovery but also protecting against data corruption with a low recovery point objective — in addition, some replication appliances can facilitate application failover and failback. Appliance replication is storage agnostic, but is not as scalable as array-based replication.
  3. Host-based replication: An agent on the host captures updates at the file system or volume level and directs them to an in-memory buffer pool where they are scheduled for transmission to the remote host; there, the reverse process occurs. Host-based replication is storage-agnostic, but agents are specific to the operating system.
  4. Database replication: Database replication is either embedded in the database itself or available through third-party software from vendors. Embedded database replication is typically included at no additional cost, and it's tightly integrated with the database itself. Database replication is storage-agnostic, but only replicates the database environment.

Myth: Replication would require that we upgrade our network bandwidth
Reality: It's true that synchronous and storage replication require low latency, high bandwidth connectivity between sites, but this can be mitigated by installing a WAN optimization solution. Additionally, appliance and host-based replication require less bandwidth than array-based replication solutions because only changed data is replicated and the replication can be throttled up or down depending on recovery point objectives.

Are you using replication in your environment? Has it helped to improve your disaster recovery and/or high availability?

Comments

Good summary, Rachel.

Good summary, Rachel. Database replication (#4 in your reality counterpoint to the myth that replication is too expensive) is usually between two like databases (e.g. Oracle to Oracle) and is, as you say, tightly integrated with the database. But it’s probably worth mentioning that sometimes database replication is from a “producer” database to a “consumer” database. In this case, the replication is tightly integrated with the producer database, but open to any consumer database.

We (McObject) find this in embedded systems wherein data in a database on a device (where Oracle doesn’t play) needs to be replicated (in whole or in part) to the enterprise, and in real-time financial applications such as algorithmic trading, matching engines, etc, where a subset of the data in a super-fast in-memory database needs to be replicated to an enterprise database. In fact, we just added a feature called Data Relay to accomplish this kind of selective producer-consumer sharing of information; it’s called Data Relay and is part of the Transaction Logging edition of our eXtremeDB database system. (see http://www.mcobject.com/august10/2010)