{
  "id": "clustering",
  "title": "Database clustering",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/databases/durability-ha/clustering/",
  "summary": "Clustering to allow customers to spread the load of a Redis process over multiple cores and the RAM of multiple servers.",
  "content": "Source available [Redis](https://redislabs.com/redis-features/redis) is a single-threaded process\nto provide speed and simplicity.\nA single Redis process is bound by the CPU core that it is running on and available memory on the server.\n\nRedis Enterprise Software supports database clustering to allow customers\nto spread the load of a Redis process over multiple cores and the RAM of multiple servers.\nA database cluster is a set of Redis processes where each process manages a subset of the database keyspace.\n\nThe keyspace of a Redis Enterprise cluster is partitioned into database shards.\nEach shard resides on a single node and is managed by that node.\nEach node in a Redis database cluster can manage multiple shards.\nThe key space in the shards is divided into hash slots.\nThe slot of a key is determined by a hash of the key name or part of the key name.\n\nDatabase clustering is transparent to the Redis client that connects to the database.\nThe Redis client accesses the database through a single endpoint that automatically routes all operations to the relevant shards.\nYou can connect an application to a single Redis process or a clustered database without any difference in the application logic.\n\n## Terminology\n\nIn clustering, these terms are commonly used:\n\n- Tag or Hash Tag - A part of the key that is used in the hash calculation.\n- Slot or Hash Slot - The result of the hash calculation.\n- Shard - Redis process that is part of the Redis clustered database.\n\n## When to use clustering (sharding)\n\nClustering is an efficient way of scaling Redis that should be used when:\n\n- The dataset is large enough to benefit from using the RAM resources of more than one node.\n    When a dataset is more than 25 GB (50 GB for RoF), we recommend that you enable clustering to create multiple shards of the database\n    and spread the data requests across nodes.\n- The operations performed against the database are CPU-intensive, resulting in performance degradation.\n    By having multiple CPU cores manage the database's shards, the load of operations is distributed among them.\n\n## Number of shards\n\nWhen enabling database clustering, you can set the number of database\nshards. The minimum number of shards per database is 2 and the maximum\ndepends on the subscription you purchased.\n\nAfter you enable database clustering and set the number of shards, you cannot deactivate database clustering or reduce the number of\nshards. You can only increase the number of shards by a multiple of the\ncurrent number of shards. For example, if the current number of shards\nis 3, you can increase the number of shards to 6, 9, or 12. \n\n## Supported hashing policies\n\n### Standard hashing policy\n\nWhen using the standard hashing policy, a clustered Redis Enterprise database behaves similarly to a standard [Redis Open Source cluster](#hash-tags), except when using multiple hash tags in a key's name. We recommend using only a single hash tag in a key name for hashing in Redis Enterprise.\n\n- **Keys with a hash tag**: a key's hash tag is any substring between\n    `{` and `}` in the key's name. When a key's name\n    includes the pattern `{...}`, the hash tag is used as input for the\n    hashing function.\n    \n    For example, the following key names have the same\n    hash tag and map to the same hash slot: `foo{bar}`,\n    `{bar}baz`, and `foo{bar}baz`.\n\n- **Keys without a hash tag**: when a key does not contain the `{...}`\n    pattern, the entire key's name is used for hashing.\n\nYou can use a hash tag to store related keys in the same hash\nslot so multi-key operations can run on these keys. If you do not use a hash tag in the key's name, the keys are distributed evenly across the keyspace's shards.\nIf your application does not perform multi-key operations, you do not\nneed to use hash tags.\n\n### Custom hashing policy\n\nYou can configure a custom hashing policy for a clustered database. A\ncustom hashing policy is required when different keys need to be kept\ntogether on the same shard to allow multi-key operations. The custom\nhashing policy is provided through a set of Perl Compatible Regular\nExpressions (PCRE) rules that describe the dataset's key name patterns.\n\nTo configure a custom hashing policy, enter the regular expression\n(RegEx) rules that identify the substring in the key's name - hash tag\n-- on which hashing is done. The hash tag is denoted in the\nRegEx by the use of the \\`tag\\` named subpattern. Different keys that\nhave the same hash tag are stored and managed in the same slot.\n\nAfter you enable the custom hashing policy, the following default RegEx\nrules are implemented. Update these rules to fit your specific logic:\n\n|  RegEx Rule | Description |\n|  ------ | ------ |\n|  .\\*{(?\\\u003ctag\\\u003e.\\*)}.\\* | Hashing is done on the substring between the curly braces. |\n|  (?\\\u003ctag\\\u003e.\\*) | The entire key's name is used for hashing. |\n\nYou can modify existing rules, add new ones, delete rules, or change\ntheir order to suit your application's requirements.\n\n### Custom hashing policy notes and limitations\n\n1. You can define up to 32 RegEx rules, each up to 256 characters.\n2. RegEx rules are evaluated in order, and the first rule matched\n    is used. Therefore, you should place common key name patterns at the\n    beginning of the rule list.\n3. Key names that do not match any of the RegEx rules trigger an\n    error.\n4. The '.\\*(?\\\u003ctag\\\u003e)' RegEx rule forces keys into a single slot\n    because the hash key is always empty. Therefore, when used,\n    this should be the last, catch-all rule.\n5. The following flag is enabled in the regular expression parser:\n    PCRE_ANCHORED: the pattern is constrained to match only at the\n    start of the string being searched.\n\n## Change the hashing policy\n\nThe hashing policy of a clustered database can be changed. However,\nmost hashing policy changes trigger the deletion (FLUSHDB) of the\ndata before they can be applied.\n\nExamples of such changes include:\n\n- Changing the hashing policy from standard to custom or conversely,\n    custom to standard.\n- Changing the order of custom hashing policy rules.\n- Adding new rules in the custom hashing policy.\n- Deleting rules from the custom hashing policy.\n\n\nThe recommended workaround for updates that are not enabled,\nor require flushing the database,\nis to back up the database and import the data to a newly configured database.\n\n\n## Multi-key operations {#multikey-operations}\n\nOperations on multiple keys in a clustered database are supported with\nthe following limitations:\n\n- **Multi-key commands**: Redis offers several commands that accept\n    multiple keys as arguments. In a clustered database, most multi-key\n    commands are not allowed across slots. The following multi-key\n    commands **are allowed** across slots: DEL, MSET, MGET, EXISTS, UNLINK, TOUCH\n\n    In Active-Active databases, multi-key write commands (DEL, MSET, UNLINK) can only be run on keys that are in the same slot. However, the following multi-key commands **are allowed** across slots in Active-Active databases: MGET, EXISTS, and TOUCH.\n\n    Commands that affect all keys or keys that match a specified pattern are allowed\n    in a clustered database, for example: FLUSHDB, FLUSHALL, KEYS\n\n    \nWhen using these commands in a sharded setup,\nthe command is distributed across multiple shards\nand the responses from all shards are combined into a single response.\n    \n\n- **Geo commands**: For the [GEORADIUS]() and\n    [GEORADIUSBYMEMBER]() commands, the\n    STORE and STOREDIST options can only be used when all affected keys\n    reside in the same slot.\n- **Transactions**: All operations within a WATCH / MULTI / EXEC block\n    should be performed on keys that are mapped to the same slot.\n- **Lua scripts**: All keys used by a Lua script must be mapped to the same\n    slot and must be provided as arguments to the EVAL / EVALSHA commands\n    (as per the Redis specification). Using keys in a Lua script that\n    were not provided as arguments might violate the sharding concept\n    but do not result in the proper violation error being returned.\n- **Renaming/Copy keys**: The use of the RENAME / RENAMENX / COPY commands is\n    allowed only when the key's original and new values are mapped to\n    the same slot.\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00"
}