Documentation - Redise Pack

A guide to Redise Pack installation, operation and administration

open all | close all

Geo-Distributed Active-Active Redis Applications with Conflict-free Replicated Databases (CRDB)

Note: This page only pertains to Redis Enterprise Pack v5.0 Preview.

Developing globally distributed applications can be challenging, as developers have to think about race conditions and complex combinations of events under geo-failovers and cross-region write conflicts. CRDBs simplify developing such applications by directly using built-in smarts for handling conflicting writes based on the data type in use. Instead of depending on just simplistic “last-writer-wins” type conflict resolution, geo-distributed CRDBs combines techniques defined in CRDT (conflict-free replicated data types) research with Redis types to provide smart and automatic conflict resolution based on the data types intent.

CRDB is a globally distributed database that spans multiple Redis Enterprise Pack clusters. Each CRDB can have many member CRDBs (member is a CRDB in each cluster that is participating in a global CRDBs) come with added smarts for handling globally distributed writes using the proven CRDT approach. CRDT research describes a set of techniques for creating systems that can handle conflicting writes. CRDBs are powered by Multi-Master Replication (MMR) provides a straightforward and effective way to replicate your data between regions and simplify development of complex applications that can maintain correctness under geo-failovers and concurrent cross-region writes to the same data.

geo replication world map

CRDBs replicate data between multiple Redis Enterprise Pack clusters. Common uses for CRDBs include disaster recovery, geographically redundant applications, and keeping data closers to your user’s locations. MMR is always multi-directional amongst the clusters configured in the CRDB. For unidirectional replication, please see the ReplicaOf capabilities in Redis Enterprise Pack.

Example of synchronization

In the example below, database writes are concurrent at the point in times t1 and t2 and happen before a sync can communicate the changes. However, writes at times t4 and t6 are not concurrent as a sync happened in between.

Time Member CRDB1 Member CRDB2
t1 SET key1 “a”
t2 SET key1 “b”
t3 — Sync —
 t4 SET key1 “c”
t5 — Sync —
t6 SET key1 “d”

Learn more about synchronization for each supported data type and how to develop with them on RP.

Terminology

  1. Global conflict-free replicated database (CRDB): refers to a new type of Redis Enterprise Pack database that spans clusters. There can be one or more member databases across many clusters that form a conflict-free replicated database (CRDB)s. Each local database can have different shard count, replica count, and other database options but contain identical information in steady-state.
  2. Member conflict-free replicated database (mCRDB): is a “member database” instance of a global CRDB which is made up of master and slave shards spanning a single cluster. A mCRDB can participate in only one (CRDB) scheme.
  3. Multi-master Replication (MMR): is the multi-directional replication that power the efficient replication required to achieve active-active concurrent writes in CRDBs.
  4. Conflict-free Replicated Data Types (CRDT): is the underlying research that describes techniques used by Redis data types in CRDBs that smartly handle conflicting concurrent writes across member CRDBs.
  5. Participating Clusters: refers to clusters participating in the multi-master replication of a conflict-free replicated database (CRDB).
  6. Concurrent Writes or Concurrent Updates: Concurrency or updates and writes refer to more than events that happen at the same wall clock time across member CRDBs. Concurrent updates refer to the fact that updates happen in between sync events that catch up member CRDBs with updates that happened on other member CRDBs.