Details
-
Task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.5.1
-
None
-
Security Level: Public
-
build 3508 running cbc-n1qlback
Description
start a cluster with 2 query nodes
start cbc-n1qlback with some query
add a new query node to the cluster and rebalance
observe the request/sec per node
expected: topology changes should eb automatically picked up by the clients. after rebalance the new query node needs to be part of the round robin requests being sent to the cluster. however new node does not start taking traffic even after a long wait.
if the load is stopped and restarted, the requests do go to the newly added node as well. However this means topology changes would require a restart of the app servers. that does cause admin overhead and possibly failed requests for the app and downtime.
Attachments
Issue Links
- relates to
-
CCBC-760 C fast failover support
-
- Resolved
-
Activity
Field | Original Value | New Value |
---|---|---|
Description |
start a cluster with 2 query nodes
start cbc-n1qlback with some query add a new query node to the cluster and rebalance observe the request/sec per node expected: after rebalance the new query node needs to be part of the round robin requests being sent to the cluster. however new node does not start taking traffic even after a long wait. if the load is stopped and restarted, the requests do go to the newly added node as well. However this means adding a new node would require a restart of the app servers. |
start a cluster with 2 query nodes
start cbc-n1qlback with some query add a new query node to the cluster and rebalance observe the request/sec per node expected: after rebalance the new query node needs to be part of the round robin requests being sent to the cluster. however new node does not start taking traffic even after a long wait. if the load is stopped and restarted, the requests do go to the newly added node as well. However this means topology changes would require a restart of the app servers. that does cause admin overhead and possibly failed requests for the app and downtime. |
Description |
start a cluster with 2 query nodes
start cbc-n1qlback with some query add a new query node to the cluster and rebalance observe the request/sec per node expected: after rebalance the new query node needs to be part of the round robin requests being sent to the cluster. however new node does not start taking traffic even after a long wait. if the load is stopped and restarted, the requests do go to the newly added node as well. However this means topology changes would require a restart of the app servers. that does cause admin overhead and possibly failed requests for the app and downtime. |
start a cluster with 2 query nodes
start cbc-n1qlback with some query add a new query node to the cluster and rebalance observe the request/sec per node expected: topology changes should eb automatically picked up by the clients. after rebalance the new query node needs to be part of the round robin requests being sent to the cluster. however new node does not start taking traffic even after a long wait. if the load is stopped and restarted, the requests do go to the newly added node as well. However this means topology changes would require a restart of the app servers. that does cause admin overhead and possibly failed requests for the app and downtime. |
Status | New [ 10003 ] | Resolved [ 5 ] |
Status | Resolved [ 5 ] | Reopened [ 4 ] |
Fix Version/s | 2.5.1 [ 12808 ] |
Summary | clients don't utilize a newly added node to the cluster | Poll regularly for config updates |
Fix Version/s | .future [ 11337 ] |
Fix Version/s | 2.7.5 [ 14404 ] | |
Fix Version/s | .future [ 11337 ] |
Labels | n1ql | fast_failover n1ql |
Status | Reopened [ 4 ] | In Progress [ 3 ] |
Resolution | Fixed [ 1 ] | |
Status | In Progress [ 3 ] | Resolved [ 5 ] |
Workflow | Couchbase SDK Workflow [ 50052 ] | Couchbase SDK Workflow with Review [ 249998 ] |
Workflow | Couchbase SDK Workflow with Review [ 249998 ] | Couchbase SDK Workflow [ 262010 ] |
Workflow | Couchbase SDK Workflow [ 262010 ] | Couchbase SDK Workflow with Review [ 263766 ] |
Workflow | Couchbase SDK Workflow with Review [ 263766 ] | SDK Workflow with Review NG [ 265289 ] |
Preemptively 'auto-detecting' new nodes is not supported via CCCP (memcached) bootstrap; only via the HTTP 'streaming' config, which is disabled by default for the library.
You can specify `bootstrap_on=http` in the connection string to use old, 'streaming-style' config updates which will notify the client whenever there is a configuration change. Otherwise the client only checks if there is a new configuration in the case of an error.
Considering that most deployments of the library would be using a combination of KV and query operations, this is not considered an issue at the moment. For those running 'query-only' workloads, they can specify the extra option in the connection string.
Note that this same problem appears in 'view-only' connections, but in practice does not seem to be a common deployment configuration on the client.