2

In Couchbase documentation: https://developer.couchbase.com/documentation/server/current/concepts/distributed-data-management.html

There is no concept of master nodes, slave nodes, config nodes, name nodes, head nodes, etc, and all the software loaded on each node is identical

But in my logs I get the message found in post: https://forums.couchbase.com/t/havent-heard-from-a-higher-priority-node-or-a-master-so-im-taking-over/5924

Haven't heard from a higher priority node or a master, so I'm taking over.  mb_master 000   ns_1@10.200.0.10    1:07:38 AM Tue Feb 7, 2017

and

Somebody thinks we're master. Not forcing mastership takover over ourselves mb_master 000   ns_1@10.200.0.10    1:07:28 AM Tue Feb 7, 2017

I am having trouble finding what the master does, because any search about a master results in the comment of couchbase not having a master node.

Jim Clam
  • 117
  • 11

2 Answers2

3

The error messages seem to originate from the cluster management which should look like this (I didn't manage to find the Couchbase implementation of it). The link points to the implementation of membase which is the predecessor of Couchbase.

While all nodes are equal in Couchbase this is not the case when there is some redistribution of data. As described in detail in this document a master is chosen to manage the redistribution. The log messages you get are caused by this process.

Community
  • 1
  • 1
Robin Ellerkmann
  • 2,083
  • 4
  • 29
  • 34
1

The Master Node in the cluster manager is also known as the orchestrator.

Straight from the Couchbase Server 4.6 documentation, https://developer.couchbase.com/documentation/server/4.6/concepts/distributed-data-management.html

Although each node runs its own local Cluster Manager, there is only one node chosen from among them, called the orchestrator, that supervises the cluster at a given point in time. The orchestrator maintains the authoritative copy of the cluster configuration, and performs the necessary node management functions to avoid any conflicts from multiple nodes interacting. If a node becomes unresponsive for any reason, the orchestrator notifies the other nodes in the cluster and promotes the relevant replicas to active status. This process is called failover, and it can be done automatically or manually. If the orchestrator fails or loses communication with the cluster for any reason, the remaining nodes detect the failure when they stop receiving its heartbeat, so they immediately elect a new orchestrator. This is done immediately and is transparent to the operations of the cluster.

Ian McCloy
  • 306
  • 3
  • 2