|
1 | 1 | --- |
2 | | -Title: Active-Active geo-distributed Redis |
| 2 | +Title: Active-Active Redis |
3 | 3 | alwaysopen: false |
4 | 4 | categories: |
5 | 5 | - docs |
6 | 6 | - operate |
7 | | -- rs |
8 | | -- kubernetes |
9 | | -description: Overview of the Active-Active database in Redis Enterprise Software |
| 7 | +- rc |
| 8 | +description: Overview of the Active-Active feature for Redis Cloud. |
| 9 | +weight: 43 |
10 | 10 | hideListLinks: true |
11 | | -linktitle: Active-Active |
12 | | -weight: 40 |
| 11 | +aliases: |
| 12 | + - /operate/rc/databases/configuration/active-active-redis/ |
13 | 13 | --- |
14 | | -In Redis Enterprise, Active-Active geo-distribution is based on [CRDT technology](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type). |
15 | | -The Redis Enterprise implementation of CRDT is called an Active-Active database (formerly known as CRDB). |
16 | | -With Active-Active databases, applications can read and write to the same data set from different geographical locations seamlessly and with latency less than one millisecond (ms), |
17 | | -without changing the way the application connects to the database. |
18 | 14 |
|
19 | | -Active-Active databases also provide disaster recovery and accelerated data read-access for geographically distributed users. |
| 15 | +Active-Active databases store data across multiple regions and availability zones. This improves scalability, performance, and availability, especially when compared to standalone databases. |
20 | 16 |
|
| 17 | +To create Active-Active databases, you need a Redis Cloud Pro subscription that enables Active-Active Redis and defines the regions for each copy of your databases. See [Create an Active-Active database]({{< relref "/operate/rc/databases/create-database/create-active-active-database" >}}) for instructions. |
21 | 18 |
|
22 | | -## High availability |
| 19 | +Active-Active databases are distributed across multiple regions (geo-distribution). This improves performance by reducing latency for nearby users and improves availability by protecting against data loss in case of network or resource failure. |
23 | 20 |
|
24 | | -The [high availability]({{< relref "/operate/rs/databases/durability-ha/" >}}) that Active-Active replication provides is built upon a number of Redis Enterprise Software features (such as [clustering]({{< relref "/operate/rs/databases/durability-ha/clustering.md" >}}), [replication]({{< relref "/operate/rs/databases/durability-ha/replication.md" >}}), and [replica HA]({{< relref "/operate/rs/databases/configure/replica-ha.md" >}})) as well as some features unique to Active-Active ([multi-primary replication]({{<relref "#multi-primary-replication/">}}), [automatic conflict resolution]({{<relref "#conflict-resolution/">}}), and [strong eventual consistency]({{<relref "#strong-eventual-consistency/">}})). |
| 21 | +Active-Active databases allow read and write operations in each copy. Each copy eventually reflects changes made in other copies ([eventual consistency]({{< relref "/glossary#eventual-consistency" >}})). Conflict-free data types (CRDTs) synchronize read and write operations between copies. CRDTs ensure consistency and resolve conflicts. |
25 | 22 |
|
26 | | -Clustering and replication are used together in Active-Active databases to distribute multiple copies of the dataset across multiple nodes and multiple clusters. As a result, a node or cluster is less likely to become a single point of failure. If a primary node or primary shard fails, a replica is automatically promoted to primary. To avoid having one node hold all copies of certain data, the [replica HA]({{< relref "/operate/rs/databases/configure/replica-ha.md" >}}) feature (enabled by default) automatically migrates replica shards to available nodes. |
| 23 | +Active-Active databases use TLS to synchronize data between regions. You can also use TLS to encrypt client connections. See [Transport Layer Security (TLS)]({{< relref "/operate/rc/security/database-security/tls-ssl.md" >}}) for more information. |
27 | 24 |
|
28 | | -## Multi-primary replication |
29 | | - |
30 | | -In Redis Enterprise Software, replication copies data from primary shards to replica shards. Active-Active geo-distributed replication also copies both primary and replica shards to other clusters. Each Active-Active database needs to span at least two clusters; these are called participating clusters. |
31 | | - |
32 | | -Each participating cluster hosts an instance of your database, and each instance has its own primary node. Having multiple primary nodes means you can connect to the proxy in any of your participating clusters. Connecting to the closest cluster geographically enables near-local latency. Multi-primary replication (previously referred to as multi-master replication) also means that your users still have access to the database if one of the participating clusters fails. |
| 25 | +When developing for Active-Active databases, you need to consider some important differences. See [Develop applications with Active-Active databases]({{< relref "/operate/rc/databases/active-active/develop/_index.md" >}}) for related information. |
33 | 26 |
|
34 | 27 | {{< note >}} |
35 | | -Active-Active databases do not replicate the entire database, only the data. |
36 | | -Database configurations, LUA scripts, and other support info are not replicated. |
| 28 | +Active-Active subscriptions on Redis Cloud are limited to a maximum of 10 regions and 10 databases. |
37 | 29 | {{< /note >}} |
38 | 30 |
|
39 | | -## Syncer |
40 | | - |
41 | | -Keeping multiple copies of the dataset consistent across multiple clusters is no small task. To achieve consistency between participating clusters, Redis Active-Active replication uses a process called the [syncer]({{< relref "/operate/rs/databases/active-active/syncer" >}}). |
42 | | - |
43 | | -The syncer keeps a [replication backlog]({{< relref "/operate/rs/databases/active-active/manage#replication-backlog/" >}}), which stores changes to the dataset that the syncer sends to other participating clusters. The syncer uses partial syncs to keep replicas up to date with changes, or a full sync in the event a replica or primary is lost. |
| 31 | +## Active-Active geo-distributed replication highlights |
44 | 32 |
|
45 | | -## Conflict resolution |
| 33 | +### Multi-zone |
46 | 34 |
|
47 | | -Because you can connect to any participating cluster to perform a write operation, concurrent and conflicting writes are always possible. Conflict resolution is an important part of the Active-Active technology. Active-Active databases only use [conflict-free replicated data types (CRDTs)](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type). These data types provide a predictable conflict resolution and don't require any additional work from the application or client side. |
| 35 | +Geo-distributed replication maintains copies of both primary and replica shards in multiple clusters. These clusters can be spread across multiple availability zones. Active-Active Redis uses zone awareness to spread your primary and replica shards across zones, which helps protect against data loss from regional outages. |
48 | 36 |
|
49 | | -When developing with CRDTs for Active-Active databases, you need to consider some important differences. See [Develop applications with Active-Active databases]({{< relref "/operate/rs/databases/active-active/develop/_index.md" >}}) for related information. |
| 37 | +### Local latency with unique endpoints |
50 | 38 |
|
| 39 | +Applications can connect to a specific copy of an Active-Active database using its unique endpoint. For local latency, configure your application to use a database endpoint in the closest region. |
51 | 40 |
|
52 | | -## Strong eventual consistency |
| 41 | +### Conflict resolution |
53 | 42 |
|
54 | | -Maintaining strong consistency for replicated databases comes with tradeoffs in scalability and availability. Redis Active-Active databases use a strong eventual consistency model, which means that local values may differ across replicas for short periods of time, but they all eventually converge to one consistent state. Redis uses vector clocks and the CRDT conflict resolution to strengthen consistency between replicas. You can also enable the causal consistency feature to preserve the order of operations as they are synchronized among replicas. |
| 43 | +Active-Active databases use special data types called conflict-free data types (CRDT). These automatically resolve conflicts that occur when writes are made to different clusters at the same time. |
55 | 44 |
|
56 | | -Other Redis Enterprise Software features can also be used to enhance the performance, scalability, or durability of your Active-Active database. These include [data persistence]({{< relref "/operate/rs/databases/configure/database-persistence.md" >}}), [multiple active proxies]({{< relref "/operate/rs/databases/configure/proxy-policy.md" >}}), [distributed synchronization]({{< relref "/operate/rs/databases/active-active/synchronization-mode.md" >}}), [OSS Cluster API]({{< relref "/operate/rs/databases/configure/oss-cluster-api.md" >}}), and [rack-zone awareness]({{< relref "/operate/rs/clusters/configure/rack-zone-awareness.md" >}}). |
| 45 | +### Failover handling |
57 | 46 |
|
58 | | -## Next steps |
| 47 | +After a failure at the process, node, or zone level, Active-Active databases automatically promote replica shards to replace failed primaries, copy data to new replica shards, and migrate shards to new nodes as needed. This reduces downtime and makes the most of your computing resources, even in the event of a failure. |
59 | 48 |
|
60 | | -- [Plan your Active-Active deployment]({{< relref "/operate/rs/databases/active-active/planning.md" >}}) |
61 | | -- [Get started with Active-Active]({{< relref "/operate/rs/databases/active-active/get-started.md" >}}) |
62 | | -- [Create an Active-Active database]({{< relref "/operate/rs/databases/active-active/create.md" >}}) |
| 49 | +Active-Active also provides a failover opportunity in case an entire cluster fails. Applications should redirect traffic to another cluster in the Active-Active deployment if a connected cluster fails. After the original cluster recovers, applications can direct traffic back to the original cluster. Redirecting traffic to alternate clusters is not handled automatically by Active-Active, so you must add redirection logic to the application. However, data automatically syncs to a recovered cluster when it returns to a healthy state. |
0 commit comments