{
  "schema_version": 2,
  "id": "operate/rs/databases/configure/proxy-policy",
  "title": "Configure proxy policy",
  "url": "https://redis.io/docs/latest/operate/rs/7.4/databases/configure/proxy-policy/",
  "summary": "",
  "content": "Redis Enterprise Software (RS) provides high-performance data access\nthrough a proxy process that manages and optimizes access to shards\nwithin the RS cluster. Each node contains a single proxy process.\nEach proxy can be active and take incoming traffic or it can be passive\nand wait for failovers.\n\n## Proxy policies\n\nA database can have one of these proxy policies:\n\n| **Proxy Policy** | **Description** |\n|------------|-----------------|\n| Single | There is only a single proxy that is bound to the database. This is the default database configuration and preferable in most use cases. |\n| All Master Shards | There are multiple proxies that are bound to the database, one on each node that hosts a database master shard. This mode fits most use cases that require multiple proxies. |\n| All Nodes | There are multiple proxies that are bound to the database, one on each node in the cluster, regardless of whether or not there is a shard from this database on the node. This mode should be used only in special cases, such as [using a load balancer](https://redis.io/docs/latest/operate/rs/networking/cluster-lba-setup). |\n\n\u003e [!NOTE]\n\u003e Manual intervention is also available via the rladmin bind add and\n\u003e remove commands.\n\n## Database configuration\n\nA database can be configured with a proxy policy using rladmin bind.\n\nWarning: Any configuration update which causes existing proxies to be\nunbounded can cause existing client connections to get disconnected.\n\nYou can run rladmin to control and view the existing settings for proxy\nconfiguration.\n\nThe **info** command on cluster returns the existing proxy policy for\nsharded and non-sharded (single shard) databases.\n\n```sh\n$ rladmin info cluster\ncluster configuration:\n   repl_diskless: enabled\n   default_non_sharded_proxy_policy: single\n   default_sharded_proxy_policy: single\n   default_shards_placement: dense\n   default_shards_overbooking: disabled\n   default_fork_evict_ram: enabled\n   default_redis_version: 3.2\n   redis_migrate_node_threshold: 0KB (0 bytes)\n   redis_migrate_node_threshold_percent: 8 (%)\n   redis_provision_node_threshold: 0KB (0 bytes)\n   redis_provision_node_threshold_percent: 12 (%)\n   max_simultaneous_backups: 4\n   watchdog profile: local-network\n```\n\nYou can configure the proxy policy using the `bind` command in\nrladmin. The following command is an example that changes the bind\npolicy for a database named \"db1\" with an endpoint id \"1:1\" to \"All\nMaster Shards\" proxy policy.\n\n```sh\nrladmin bind db db1 endpoint 1:1 policy all-master-shards\n```\n\nThe next command performs the same task using the database id in place of the name.  The id of this database is \"1\".\n\n```sh\nrladmin bind db db:1 endpoint 1:1 policy all-master-shards\n```\n\n\u003e [!NOTE]\n\u003e You can find the endpoint id for the endpoint argument by running\n\u003e *status* command for rladmin. Look for the endpoint id information under\n\u003e the *ENDPOINT* section of the output.\n\n### Reapply policies after topology changes\n\nIf you want to reapply the policy after topology changes, such as node restarts,\nfailovers and migrations, run this command to reset the policy:\n\n```sh\nrladmin bind db db:\u003cID\u003e endpoint \u003cendpoint id\u003e policy \u003call-master-shards|all-nodes\u003e\n```\n\nThis is not required with single policies.\n\n#### Other implications\n\nDuring the regular operation of the cluster different actions might take\nplace, such as automatic migration or automatic failover, which change\nwhat proxy needs to be bound to what database. When such actions take\nplace the cluster attempts, as much as possible, to automatically change\nproxy bindings to adhere to the defined policies. That said, the cluster\nattempts to prevent any existing client connections from being\ndisconnected, and hence might not entirely enforce the policies. In such\ncases, you can enforce the policy using the appropriate rladmin\ncommands.\n\n## About multiple active proxy support\n\nRS allows multiple databases to be created. Each database gets an\nendpoint (a unique URL and port on the FQDN). This endpoint receives all\nthe traffic for all operations for that database. By default, RS binds\nthis database endpoint to one of the proxies on a single node in the\ncluster. This proxy becomes an active proxy and receives all the\noperations for the given database. (note that if the node with the\nactive proxy fails, a new proxy on another node takes over as part of\nthe failover process automatically).\n\nIn most cases, a single proxy can handle a large number of operations\nwithout consuming additional resources. However, under high load,\nnetwork bandwidth or a high rate of packets per second (PPS) on the\nsingle active proxy can become a bottleneck to how fast database\noperation can be performed. In such cases, having multiple active\nproxies, across multiple nodes, mapped to the same external database\nendpoint, can significantly improve throughput.\n\nWith the multiple active proxies capability, RS enables you to configure\na database to have multiple internal proxies in order to improve\nperformance, in some cases. It is important to note that, even though\nmultiple active proxies can help improve the throughput of database\noperations, configuring multiple active proxies may cause additional\nlatency in operations as the shards and proxies are spread across\nmultiple nodes in the cluster.\n\n\u003e [!NOTE]\n\u003e When the network on a single active proxy becomes the bottleneck,\n\u003e you might also look into enabling the multiple NIC support in RS. With\n\u003e nodes that have multiple physical NICs (Network Interface Cards), you\n\u003e can configure RS to separate internal and external traffic onto\n\u003e independent physical NICs. For more details, refer to [Manage IP addresses](https://redis.io/docs/latest/operate/rs/networking/multi-ip-ipv6).\n\nHaving multiple proxies for a database can improve RS's ability for fast\nfailover in case of proxy and/or node failure. With multiple proxies for\na database, there is no need for a client to wait for the cluster\nto spin up another proxy and a DNS change in most cases, the client\njust uses the next IP in the list to connect to another proxy.\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-10-21T09:46:20-07:00"
}