Revision tags: 6.6.3, 7.0.1, 7.0.0, 6.6.2, 6.0.5, 6.6.1, 6.5.2, 6.6.0, 6.5.1, 6.0.4, 6.5.0, 6.0.3, 5.5.6, 5.5.5, 5.5.4, 6.0.1, 5.5.3, 6.0.0, 5.5.2, 5.1.2, 5.5.1, 5.5.0, 4.6.5 |
|
#
c4dfe100 |
| 22-Feb-2018 |
Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> |
[copyright] Bulk update copyright headers. Change-Id: I9328252fbbb52d104b334fd6838f4cb9e8fa1e63 Reviewed-on: http://review.couchbase.org/89867 Reviewed-by: Aliaksey Artamonau <aliaks
[copyright] Bulk update copyright headers. Change-Id: I9328252fbbb52d104b334fd6838f4cb9e8fa1e63 Reviewed-on: http://review.couchbase.org/89867 Reviewed-by: Aliaksey Artamonau <aliaksey.artamonau@couchbase.com> Tested-by: Aliaksey Artamonau <aliaksey.artamonau@couchbase.com>
show more ...
|
Revision tags: 5.1.0, 5.0.1 |
|
#
49f1e23b |
| 04-Dec-2017 |
Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> |
MB-9321 New global name registry. As a replacement for global. It's not a general purpose name registry in that it uses certain assumptions about how we register global processes. Bu
MB-9321 New global name registry. As a replacement for global. It's not a general purpose name registry in that it uses certain assumptions about how we register global processes. But that makes the implementation much simpler. The assumptions being made: - processes are only registered on a master node - processes live long - there's no need to unregister processes - it's uncommon to look for a name that is not registered Brief summary of how things work. - Each node runs a leader_registry_server process. - Processes can only be registered on the master node (per mb_master determination). - On non-master nodes the registry processes simply keep a read through cache of known global processes. That is, on first miss, a request to the master node is sent. Then the result is cached. The cached process is monitored and removed from the cache if the process itself or the link to the master node dies. - Since processes cannot be unregistered, there's no need to do anything special about it. Cache invalidation relies on the regular Erlang monitors. Backward compatibility is dealt with by registering with both global and leader_registry_server until the cluster turns vulcan. Change-Id: Ied2d13e6a995882b6cd44187d24942d083819429 Reviewed-on: http://review.couchbase.org/86335 Tested-by: Aliaksey Artamonau <aliaksey.artamonau@couchbase.com> Reviewed-by: Artem Stemkovski <artem@couchbase.com>
show more ...
|
#
cba22b9b |
| 02-Feb-2018 |
Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> |
[copyright] Bulk update copyright headers. Change-Id: If14cc8b547ada138e5b44d05be7b946cd363a7e5 Reviewed-on: http://review.couchbase.org/88778 Reviewed-by: Aliaksey Artamonau <aliaks
[copyright] Bulk update copyright headers. Change-Id: If14cc8b547ada138e5b44d05be7b946cd363a7e5 Reviewed-on: http://review.couchbase.org/88778 Reviewed-by: Aliaksey Artamonau <aliaksey.artamonau@couchbase.com> Tested-by: Aliaksey Artamonau <aliaksey.artamonau@couchbase.com>
show more ...
|
Revision tags: 4.6.4, 5.0.0, 4.6.3, 4.6.2, 4.6.0, 4.1.2, 4.5.1, 3.1.6 |
|
#
3ea4b167 |
| 27-May-2016 |
Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> |
[rebuild_replicas] Sync ns_config before rebalance/bucket update. That minimizes the chances of conflicts even if mastership moves to a different node. Another source of config
[rebuild_replicas] Sync ns_config before rebalance/bucket update. That minimizes the chances of conflicts even if mastership moves to a different node. Another source of config conflicts is the fact, that repl_type is updated on the node executing the script, not the master. So this is also addressed. Change-Id: I696daf59c60e21934c385e9d7251ef9b7f3f888c Reviewed-on: http://review.couchbase.org/64546 Tested-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
show more ...
|
#
95628984 |
| 27-May-2016 |
Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> |
[rebuild_replicas] Sleep for 10 seconds after the rebalances. This is to prevent mb_master from restarting if the server doesn't have this fix:: http://review.couchbase.org/64083.
[rebuild_replicas] Sleep for 10 seconds after the rebalances. This is to prevent mb_master from restarting if the server doesn't have this fix:: http://review.couchbase.org/64083. mb_master_sup's restart policy is {one_for_one, 3, 10}, so just sleeping for 10 seconds after two ns_orchestrator crashes should prevent mb_master_sup from propagating the crash up to mb_master itself. Change-Id: I5649cc2d168a9796c3a4f8e30f7d34e466a22342 Reviewed-on: http://review.couchbase.org/64545 Tested-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
show more ...
|
Revision tags: 4.5.0 |
|
#
8e2160b4 |
| 16-May-2016 |
Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> |
Add rebuild_replicas.sh script. It drops all replicas for a particular vbucket and then recreates them from active copy. If vbucket was replicated using tap, then it will also update
Add rebuild_replicas.sh script. It drops all replicas for a particular vbucket and then recreates them from active copy. If vbucket was replicated using tap, then it will also update the replication to dcp. Use as follows: ./rebuild_replicas.sh <username> <password> <host:rest port> <bucket> <vbucket> Change-Id: I79cef80b48c46c07f8d43d7bfe4a58728467a979 Reviewed-on: http://review.couchbase.org/64085 Tested-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com> Reviewed-by: Artem Stemkovski <artem@couchbase.com>
show more ...
|