{
  "id": "terminology",
  "title": "Terminology in Redis Enterprise Software",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/references/terminology/",
  "summary": "Explains terms used in Redis Enterprise Software and its docs.",
  "content": "Here are explanations of some of the terms used in Redis Enterprise Software.\n\n## Node\n\nA _node_ is a physical machine, virtual machine, container or cloud\ninstance on which the RS installation package was installed and the\nsetup process was run in order to make the machine part of the cluster.\n\nEach node is a container for running multiple Redis\ninstances, referred to as \"shards\".\n\nThe recommended configuration for a production cluster is an uneven\nnumber of nodes, with a minimum of three. Note that in some\nconfigurations, certain functionalities might be blocked. For example,\nif a cluster has only one node you cannot enable database replication,\nwhich helps to achieve high availability.\n\nA node is made up of several components, as detailed below, and works\ntogether with the other cluster nodes.\n\n## Redis instance (shard)\n\nAs indicated above, each node serves as a container for hosting multiple\ndatabase instances, referred to as \"shards\".\n\nRedis Enterprise Software supports various database configurations:\n\n- **Standard Redis database** - A single Redis shard with no\n    replication or clustering.\n- **Highly available Redis database** - Every database master shard\n    has a replica shard, so that if the master shard fails the\n    cluster can automatically fail over to the replica with minimal impact. Master and replica shards are always placed on separate\n    nodes to ensure high availability.\n- **Clustered Redis database** - The data stored in the database is\n    split across several shards. The number of shards can be defined by\n    the user. Various performance optimization algorithms define where\n    shards are placed within the cluster. During the lifetime of the\n    cluster, these algorithms might migrate a shard between nodes.\n- **Clustered and highly available Redis database** - Each master shard\n    in the clustered database has a replica shard, enabling failover if\n    the master shard fails.\n\n## Proxy\n\nEach node includes one zero-latency, multi-threaded proxy\n(written in low-level C) that masks the underlying system complexity. The\nproxy oversees forwarding Redis operations to the database shards on\nbehalf of a Redis client.\n\nThe proxy simplifies the cluster operation, from the application or\nRedis client point of view, by enabling the use of a standard Redis\nclient. The zero-latency proxy is built over a cut-through architecture\nand employs various optimization methods. For example, to help ensure\nhigh-throughput and low-latency performance, the proxy might use\ninstruction pipelining even if not instructed to do so by the client.\n\n## Database endpoint\n\nEach database is served by a database endpoint that is part of and\nmanaged by the proxies. The endpoint oversees forwarding Redis\noperations to specific database shards.\n\nIf the master shard fails and the replica shard is promoted to master, the\nmaster endpoint is updated to point to the new master shard.\n\nIf the master endpoint fails, the replica endpoint is promoted to be the\nnew master endpoint and is updated to point to the master shard.\n\nSimilarly, if both the master shard and the master endpoint fail, then\nboth the replica shard and the replica endpoint are promoted to be the new\nmaster shard and master endpoint.\n\nShards and their endpoints do not\nhave to reside within the same node in the cluster.\n\nIn the case of a clustered database with multiple database shards, only\none master endpoint acts as the master endpoint for all master shards,\nforwarding Redis operations to all shards as needed.\n\n## Cluster manager\n\nThe cluster manager oversees all node management-related tasks, and the\ncluster manager in the master node looks after all the cluster related\ntasks.\n\nThe cluster manager is designed in a way that is totally decoupled from\nthe Redis operation. This enables RS to react in a much faster and\naccurate manner to failure events, so that, for example, a node failure\nevent triggers mass failover operations of all the master endpoints\nand master shards that are hosted on the failed node.\n\nIn addition, this architecture guarantees that each Redis shard is only\ndealing with processing Redis commands in a shared-nothing architecture,\nthus maintaining the inherent high-throughput and low-latency of each\nRedis process. Lastly, this architecture guarantees that any change in\nthe cluster manager itself does not affect the Redis operation.\n\nSome of the primary functionalities of the cluster manager include:\n\n- Deciding where shards are created\n- Deciding when shards are migrated and to where\n- Monitoring database size\n- Monitoring databases and endpoints across all nodes\n- Running the database resharding process\n- Running the database provisioning and de-provisioning processes\n- Gathering operational statistics\n- Enforcing license and subscription limitations\n\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00"
}