-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cli: client side load balancing through proxy mode #24001
Comments
PostgreSQL driver already has this feature, at least the Java version.
Coupled with a pool connection (like HikariCP), you could have, by instance, 10 open connections dispatched between n nodes. |
Yes, but clients in other languages don't support multiple connections. Instead of implementing load balancing in all the client libraries it's easier to just run a local load balancer. Also, this way the load balancer knows about Cockroach's routing and could auto-discover nodes that are part of the cluster. |
RethinkDB used proxy nodes and one feature was offloading query processing to clients: Instead of just acting like a load balancer, could a cockroach proxy also offload some query planning to clients? |
@andreimatei in case you need a tracking issue for your work, this one already exists. |
We have marked this issue as stale because it has been inactive for |
We recommend haproxy and pgbouncer for this. |
FEATURE REQUEST
Ability for cockroach to run in a
proxy
mode, where it acts as a load balancer for the localhost machine to connect to the cluster. Instead of connecting to<node1 address>:26257/<database>
you would runcockroach proxy --join=<node1 address>:26257,<node2 address>:26257
then the client connects tolocalhost:26257/<database>
and it's queries are automatically load balanced to nodes in the cluster.Think of it like the current haproxy load balancing setup running locally on each client.
An extra bonus would be discovering all node addresses automatically from an initial subset of node addresses.
Related to cockroachdb/docs#978.
This is a Nice-to-have. Current work-around is using a single load balancer for all clients.
Jira issue: CRDB-6359
The text was updated successfully, but these errors were encountered: