added script to validate vbmap rack awareness constraint

Change-Id: I17808d0e92470ee610ca4503b65e5059580f381f
Reviewed-on: http://review.couchbase.org/30854
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
Tested-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
Print for how many vbuckets rack constraints are broken.

Two kinds of violations are considered:

  1. Violation is "strict" when master resides on the same rack as any of
  its replicas.

  2. Violation is "weak" when master resides on a different rack, but some
  of the replicas reside on the same rack.

Change-Id: I7bcc52035bc56704cf38e711c82bb69f70bdf3bc
Reviewed-on: http://review.couchbase.org/30857
Tested-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-9652: avoid restarting net_kernel unless absolutely necessary

One cause of issues in the ticket appears to be net_kernel
shutdowns. In most common case of not assigning hostnames this is not
actually required. So we don't touch it in this cases.

It certainly doesn't address root of the problem (which is still
unknown at this time but is believed to be somewhere within erlang
itself). But at least this commit should buy us enough time to
investigate and fix/workaround it.

Change-Id: I246f7180e6c49552f338cfefdf746775c48b6778
Reviewed-on: http://review.couchbase.org/30873
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
Handle non kv-list error_logger reports.

Change-Id: I3cdf094eba418f7a4408b4cb8ce61e3c03bee768
Reviewed-on: http://review.couchbase.org/30874
Tested-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-9678: require rebalance after offline upgrade

After offline upgrade (as opposed to rebalance upgrade) we have all
buckets without map_opts_hash property. Which was causing our logic to
detect server group assignment changes to fail detecting that
rebalance is required.

Simplest possible solution is to simply always require rebalance if
map_opts_hash is undefined. Right after rebalance upgrade that would
be empty rebalance which is slightly suboptimal. But given it's so
much KISS-ful I'm more than ok with that small glitch.

Change-Id: I97002ac02fd6897c95b4dee4575306a5fb80eeb9
Reviewed-on: http://review.couchbase.org/30876
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-9679 Treat star and chain maps compatible if num_replicas=1.

Change-Id: Ifa8daa91271989fb0f81b1d5181c0412019d5574
Reviewed-on: http://review.couchbase.org/30877
Tested-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-9501: protocol column for ongoing replications list

Change-Id: If7d232e3f8a562a33fd3b917191c4622074e9197
Reviewed-on: http://review.couchbase.org/30713
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
added colons to replication advanced settings labels

Change-Id: I26c41b4ae614e920b2ebf674c50ca7981038e4df
Reviewed-on: http://review.couchbase.org/30714
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-6983: binary and decimal prefixes

extension of truncateTo3Digits is necessary because
we can get 1000K instead of 1M in some cases

Change-Id: Ib747e076e47d6e5f6b87deadd41ad26c247abfc7
Reviewed-on: http://review.couchbase.org/30214
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-9644: do not allow updating bucket during rebalance

Otherwise our attempt to request janitor run for possible update of
replicas count crashes rebalance.

Change-Id: Iadf03e117cb35e7ab311d353a1a252e771873857
Reviewed-on: http://review.couchbase.org/30878
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-100: log loaded replication documents

I.e. to make diagnosing issues like MB-9647 easier.

Change-Id: I35c5973367738a2c606b0812c4343e01d83b000a
Reviewed-on: http://review.couchbase.org/30879
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-9548 delete all replications from the bucket

... before deleting the bucket

Change-Id: I4fc0f81ed243ebbb2bed99cb79865bf403e68026
Reviewed-on: http://review.couchbase.org/30750
Tested-by: Artem Stemkovski <artem@couchbase.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-9663: add to bucket active vb table when starting vb replicator

Today when we start new vb replicator, we do not add it immediately
to the active vb table in bucket replicator, instead, after the vb
replicator finishes initialization, it would report status to bucket
replicator and an entry will be created in the active vb replicator
table within bucket replicator.

This small init time lag may cause issue in corner cases, e.g., when
a vbucket just has one mutation, we may lose this single notification
from couchdb (src_db_updated) because the corresponding vb replicator
has not finished initialization and bucket replicator cannot find its
Pid to relay the notification msg. As a result, this vb replicator
may not be wakened for a long time until next mutation to this vb
arrives. We also see msgs like "get src_db_udpated from vb 12, but
the vb replicator has not initialized yet" in logs.

This fix will add new vb replicator immediately to active vb rep
table in bucket replicator with an empty status entry (but including
the Pid of the new vb replicator). Then all subsequent src_db_updated
msg from couchdb will be captured and relayed to corresponding vb
replicator.

Change-Id: Iba2251065cd3def37d2bf7b3017d1767a23238f9
Reviewed-on: http://review.couchbase.org/30893
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-100: increased default autofailover timeout to 2 minutes

Because it turns out many folks dont have environments that can
reliably avoid false positives with 30 seconds.

Change-Id: I4119a31b29a0a647628a6d0957ae478b0dc90662
Reviewed-on: http://review.couchbase.org/30905
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Merge remote-tracking branch 'origin/for-rackaware'

* origin/for-rackaware:
  MB-100: increased default autofailover timeout to 2 minutes
  MB-9663: add to bucket active vb table when starting vb replicator
  MB-9548 delete all replications from the bucket
  MB-100: log loaded replication documents
  MB-9644: do not allow updating bucket during rebalance
  MB-6983: binary and decimal prefixes
  added colons to replication advanced settings labels
  MB-9501: protocol column for ongoing replications list
  MB-9679 Treat star and chain maps compatible if num_replicas=1.
  MB-9678: require rebalance after offline upgrade
  Handle non kv-list error_logger reports.
  MB-9652: avoid restarting net_kernel unless absolutely necessary
  Print for how many vbuckets rack constraints are broken.
  added script to validate vbmap rack awareness constraint

trivial merge

Change-Id: Ib8d0cef9e0c8642df2202041add1dd9e8f7c76d7