Couchbase Connection Pooling

Hi Team,

I am currently trying to understand how connection pooling works in Couchbase (CB).

Firstly, if I have a cluster of four nodes, should I include all four IPs in the connection string?
Secondly, if I have a cluster with four nodes and I provide all four IPs in the connection string, is there a possibility that this will result in the creation of more connections due to multiple IPs being specified?

I would appreciate any assistance, as I have not found sufficient documentation regarding Couchbase connections. The only information, I could locate pertains to defining IPs in the connection string.

Thanks,
Debasis

Yes. Specify all. If you only specify a subset of the nodes and all the nodes in the subset are down, the SDK will have nothing to connect to. Couchbase cannot connect to nodes it doesn’t know about, right?

Couchbase uses the connection string to get the cluster configuration from the cluster. From the cluster configuration, it decides what connections to make - including getting cluster configurations after the initial bootstrap. So additional hosts in the connection string does not result in extra connections after the initial bootstrap.

There are plenty of technical details in the rfcs GitHub - couchbaselabs/sdk-rfcs: SDK RFCs

The rfc for bootstrapping is sdk-rfcs/rfc/0048-sdk3-bootstrapping.md at master · couchbaselabs/sdk-rfcs · GitHub

Thanks @mreiche for explanation. Do not you think it will be an overhead for the development team whenever a node is added or removed from the cluster?
Each time this happens, they need to update the connection string in the application code.

One more thing that suppose I add a new node in cluster as part of scaling activity but forget to update in connection string in application code i:e it can not be take the incoming user connection?

Thanks,
Debasis

Thanks

It’s not absolutely necessary to have all the data nodes in the connection string, it just makes the deployment more robust.

To avoid updating the connection string, you can do the same thing that Capella does. Use the (abbreviated) name of a DNS SRV entry in the connection string, and then maintain the DNS SRV entry. The DNS SRV entry name must begin with _couchbases._tcp (for non-ssl _couchbase._tcp) for instance _couchbases._tcp.myname.mycompany.com and then specify myname.mycompany.com in the connection string (i.e. do not include the _couchbases._tcp. part in the connection string, the SDKs and SDK Doctor will add it) . Specify only the data nodes in the SRV entry. Use SDK Doctor to test. It tells you what DNS lookups it us doing. There is an option to do the DNS SRV lookup, but you don’t need to specify it - it is enabled by default.

If a node is added to the cluster, but not added to the connection string, the SDK will still use it for kv, query etc. Because it will be in the cluster config that is retrieved from another node during the initial bootstrapping. It can even be used for getting the cluster configuration after the initial bootstrapping. It just won’t use it for the initial bootstrapping.