Skip to content
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

recommended way to connect to headless service #78

Open
christiancadieux opened this issue Jan 26, 2022 · 0 comments
Open

recommended way to connect to headless service #78

christiancadieux opened this issue Jan 26, 2022 · 0 comments

Comments

@christiancadieux
Copy link

christiancadieux commented Jan 26, 2022

What is the recommended way to connect to for example the 3 pods of a yugabyte cluster when the client is in-cluster.
since the headless service offer multiple ip names for each pod, is it possible to enter all 3 ips in the host connection string.

  • is that supported, supported by yugabyte driver, by gorm (most likely not since gorm was made for postgres and postgres does not have active-active natively and relies on external services like pgpool or repmgr)
  • What happens when one of the pods goes away. who decide to stop using that ip-address.
  • Is it best to use pgpool.

Example of headless ips : yuga-sts-0.headless-svc:5432,yuga-sts-1.headless-svc:5432,yuga-sts-2.headless-svc:5432
for example, in the case of pgpool, these 3 ips are passed as env-vars if the target was a postgres cluster:

  • name: PGPOOL_BACKEND_NODES
    value: 0:postgres-sts-0.postgres-headless-svc:5432,1:postgres-sts-1.postgres-headless-svc:5432,2:postgres-sts-2.postgres-headless-svc:5432

it's not too hard to make a go client that tries to manage all this by itself (create 3 connections, use any of them for each transaction, recognize that a connection is down and use the other 2, watch the one that went down and try to use it again etc..) but it would be better it it was supported by yugabyte the way for example that redis allows to enter multiple ips in the connection string.

when I read about it, often the asnwer is to use an external load-balancer. but I think this is different - my question is for clients that are internal to the cluster. I think I am basically describing a smart load balancer (like pgpool) who knows where to send the writes and where to send the reads (for yugabyte, that is not needed since all nodes accept writes, but it still need to be smart and stop using pods that are not available..)
headless service solves most of this problem but the client still need to pg-ping each ip regularly make sure they all work, or just wait for an error and try the other ips. but I am just guessing, I would prefer to use the yugabyte-supported solution.

thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant