Oracle Cloud Infrastructure Documentation

Sharded Clusters

OCI Cache supports two cluster modes, sharded clusters and non-sharded clusters.

Non-sharded clusters are configured with one primary node, and one or more replica nodes, with the data duplicated on each node. With this cluster mode, the data you can store is limited by amount of memory configured for the node, with a maximum of 500 GB of memory per node.

Sharded clusters have three or more shards, with the data split across the shards in the cluster, so that each shard holds part of the data. Each shard is like a cluster, with one primary node, and up to four replica nodes. Sharded clusters supports scenarios where you need to store more data than the 500 GB limit, because while these clusters are still limited to the 500 GB of memory per node, it's really 500 GB per shard.

Sharded clusters don't have primary or replica endpoints at the cluster level like non-sharded clusters do. Instead, each shard has a private endpoint you can use to when connecting to the cluster, see Getting a Sharded Cluster's Connection Details for more information.

Limitations and Considerations for Sharded Clusters

  • The number of nodes configured per shard must be from 1 to 5, with 100 nodes as the maximum number of nodes per cluster.
  • The number of shards per cluster must be an uneven number from 3 to 99, though the maximum number of shards depends on the number of nodes configured per shard.

  • The amount of memory per node must be between 2 to 500 GB.

  • Any Redis client libraries that you use to connect to a sharded cluster must support Redis CLUSTER MODE with hostname support.
  • OCI Cache clusters created as non-sharded clusters can't be converted to sharded clusters and vice versa. OCI Cache doesn't provide an automated way to move data between these cluster types.

  • Lua script isn't supported for sharded clusters.

Configuring Sharded Clusters

When configuring a sharded cluster, you need to consider the requirements to help you decide about the balance between the number of shards, number of nodes per shard, and amount of memory per node. Increasing the number of nodes per shard is a good strategy to increase a cluster's read capacity, but it doesn't help with a cluster's storage, unless you increase the amount of memory per node. It also doesn't help with a cluster's write capacity. To impact a cluster's write capacity, increase the number of shards.

For example, compare the following two scenarios:

  1. The cluster needs to store a large amount of data, but not handle a large amount of writes.
  2. The cluster needs to handle a lot of writes, but not store a large amount of data.

In scenario 1, you would configure the cluster to have a fewer number of shards, with more memory per node, compared to scenario 2. For scenario 2, you would configure the cluster to have a greater number of shards, with less memory per node.

Most of the procedures for working with sharded clusters are the same as for working with non-sharded clusters, however some procedures are different. See the following for details specific to sharded clusters: