Description
build 1682
unidirection, 1 bucket, 1.1M items + doc ops with mcsoda during rebalance
I've tried some scenarios with rebalance in/out on both src and destination clusters, the last one was:
src:
[10.3.3.92]
[10.3.3.93]
[10.3.3.99] - remove
dest:
[10.3.3.82]
[10.3.3.91]
[10.3.3.97] - remove
[10.3.3.94] - remove
on the destination cluster rebalance is failed with error: Rebalance stopped by janitor
[ns_server:debug,2012-09-05T18:04:45.428,ns_1@10.3.3.91:ns_config_log:ns_config_log:log_common:111]config change:
rebalance_status ->
[ns_server:debug,2012-09-05T18:04:45.428,ns_1@10.3.3.91:'capi_ddoc_replication_srv-bucket':cb_generic_replication_srv:handle_info:144]doing replicate_newnodes_docs
[couchdb:info,2012-09-05T18:04:45.462,ns_1@10.3.3.91:<0.14869.17>:couch_log:info:39]10.3.3.92 - - HEAD /bucket%2f10%3becc51e94f4bf4d90dec9edb70d52a6b7/ 200
[ns_server:debug,2012-09-05T18:04:45.487,ns_1@10.3.3.91:'capi_ddoc_replication_srv-bucket':cb_generic_replication_srv:handle_info:144]doing replicate_newnodes_docs
[ns_server:debug,2012-09-05T18:04:45.488,ns_1@10.3.3.91:ns_config_log:ns_config_log:log_common:111]config change:
rebalancer_pid ->
undefined
then I see a number of reports that show that the master has changed several times:
Haven't heard from a higher priority node or a master, so I'm taking over.
Somebody thinks we're master. Not forcing mastership takover over ourselves
Changing master from undefined to 'ns_1@10.3.3.82'