Please help me!..About three-node clustering and failover

[Bowen]

Hello! I would like to ask a question. Currently, I have a cluster with three nodes, and I simulated a failure in one of the nodes (192.168.11.110). At this moment, is it the only option to manually press Failover and Rebalance on the Web UI?

Regarding the Java SDK, is it unable to automatically connect to the functioning node during the failure period of (192.168.11.110)?

I currently have three nodes. How can I set up failover on the Web UI?

environment

my settings

my program

package ecomshop;

import java.time.Duration;



import com.couchbase.client.core.deps.io.netty.handler.ssl.util.InsecureTrustManagerFactory;
import com.couchbase.client.java.Bucket;
import com.couchbase.client.java.Cluster;
import com.couchbase.client.java.ClusterOptions;
import com.couchbase.client.java.Collection;
import com.couchbase.client.java.Scope;
import com.couchbase.client.java.env.ClusterEnvironment;
import com.couchbase.client.java.json.JsonObject;
import com.couchbase.client.java.kv.GetResult;
import com.couchbase.client.java.kv.MutationResult;
import com.couchbase.client.java.query.QueryResult;

public class ClusterDBConfig {

     static final String connectionString="192.168.11.110,192.168.11.107,192.168.11.111"; //ok
	 static final String username="Admin";
	 static final String password="ecom@168";
	 static final String bucketName="Test";
	 static final String scopeName="Commerce";
	 static final String collectionName="customers";
	
	public static void main(String[] args) {
		Cluster cluster = null;
		
		try {

			
			cluster = Cluster.connect(connectionString, ClusterOptions.clusterOptions(username, password));
		    cluster.waitUntilReady(Duration.ofSeconds(10));
			Bucket customerBucket = cluster.bucket(bucketName);
			Scope customerScope = customerBucket.scope(scopeName);
			Collection customerCollection= customerScope.collection(collectionName);
			 
			 
			 //查詢資料
			 GetResult queryResult = customerCollection.get("a0001");
			 System.out.println(queryResult.contentAsObject());
			 

			 
			 
			 
			 
		} catch (Exception e) {
			e.printStackTrace();
		}finally {
			if(cluster!=null) {
				cluster.disconnect();
			}
		}
	
	}

}

[mreiche]

Failover is described in Failover | Couchbase Docs

@Bowen

Regarding the Java SDK, is it unable to automatically connect to the functioning node during the failure period of (192.168.11.110)?

I assume you stimulated the failure by killing the couchbase processes, shutting down the machine or by disconnecting it from the network. In all those cases, the couchbase processes on the node would not be reachable from any external process.

[mreiche]

@Bowen

How can I set up failover on the Web UI?

Automatic Failover | Couchbase Docs

[Bowen]

1. thank you.
   As of the current situation, my application side doesn’t need to modify the code. It only
   requires configuration in the Couchbase Web UI, correct?

2. I don’t know why?
   I have another question regarding what is mentioned on the official website and in the API
   documentation. In a production environment, the documentation suggests providing multiple
   nodes to prevent a single node failure and automatically redirecting to a connectable node. Is
   this completely accurate, or are there some prerequisites for this?

This is what we recommend in production:
Cluster cluster = Cluster.connect(“host1,host2,host3”, “user”, “password”); // recommended in production

Managing Connections | Couchbase Docs

Cluster (Couchbase Java SDK 3.5.0 API)

[mreiche]

1. The SDK will automatically use the new (failed over and rebalanced) configuration if and when it is possible. Failover and rebalance need to complete for the new configuration to be completely usesble. Before failover and rebalance complete, the SDK will use the remaining nodes for query and kv operations. This means that active documents on the failed node(s) will not be accessible until failover and rebalance completed. Document replicas on remaining nodes (of documents that were on the failed nide(s)) will be readable via getReplica() APIs.

2. Specifying multiple nodes in the connection string is a good idea because if the SDK ever goes back to the original connection string, and it is only “host1”, and host1 had failed, the SDK will have no place to get the cluster configuration from. That’s the only reason. Specifying multiple hosts does not give automatic failover or rebalance or anything else. It just gives the SDK multiple places to get the cluster configuration from