ec2-3-8-153-151.eu-west-2.compute.amazonaws.

com app server

---------------
ec2-3-10-206-150.eu-west-2.compute.amazonaws.com
ec2-3-8-198-205.eu-west-2.compute.amazonaws.com
ec2-18-134-181-136.eu-west-2.compute.amazonaws.com
ec2-35-178-154-190.eu-west-2.compute.amazonaws.com
ec2-18-134-179-93.eu-west-2.compute.amazonaws.com
ec2-18-130-230-190.eu-west-2.compute.amazonaws.com
ec2-18-133-248-251.eu-west-2.compute.amazonaws.com
ec2-52-56-89-33.eu-west-2.compute.amazonaws.com

->How to suggest sizing for application teams?

->LIst of background processses in couchbase, what each one will do
->difference between node failover and remove?
->I heard what ever failover it was , couchbase will treat it as a new node when it
joins back, is it true?
->I see, in an uni-directional replication,although app team is updating the
document, it is not replicated in target side(document exists without any change)
->all of suddent couchbase-ui is not loading for GCP hosted nodes
->new features pertaining to administration in latest version?
->incase a cluster is having so many indexes/views what is the best way to reduce
rebalance time for maintenance activities like OS Patch/Cluster upgrade, why the
indexes/views will rebuild during rebalance?
->is there a way to update the XDCR filter in version 6.0, instead of drop and
recreate?
->how to handle timeout issues? what to suggest in case domain team asks us to
increase timeout?
-->xdcr full encryption, client key and certificate
-->

Key Points:
-----------

Notice the 2nd message: “I'm the only node, so I'm the master.” This essentially
means that Node #1 is the Couchbase Orchestrator. The orchestrator node in
Couchbase manages the rebalance process.This examines the current vBucket map and
then combines that information with the node additions and removals in order to
create a new vBucket map. The process is only started by the orchestrator - the
nodes themselves are responsible for actually performing the movement of data
between the nodes

Views within Couchbase process the information stored in the Couchbase database,
allowing you to index and query your data. A view creates an index on the stored
information according to the format and structure defined within the view.

if you go inside bucket data directory, you can see 1024 vbuckets (shards) created
like below
/opt/couchbase/var/lib/couchbase/data/beer-sample
0.couch.1
1.couch.1
You should see about 1030 items(under beer-sample bucket). There will be 1024
couchbase partitions (vBucket files) along with a back index, metadata files, etc.

If you want to read the content of a vbucket , you can do that using "couch_dbdump"
sudo /opt/couchbase/bin/couch_dbdump
/opt/couchbase/var/lib/couchbase/data/beer-sample/0.couch.1 | head -20
 Dumping "/opt/couchbase/var/lib/couchbase/data/beer-sample/0.couch.1":
Doc seq: 1
id: (collection:0x0:default) drake_s_brewing-jolly_roger
rev: 1
content_meta: 128
size (on disk): 156
cas: 1603198845455106048, expiry: 0, flags: 33554432, datatype: 0x01
(json)
size: 154
data: (snappy)
{"abv":9.0,"brewery_id":"drake_s_brewing","description":"","ibu":0.0,"name":"Jolly
Roger","srm":0.0,"type":"beer","upc":0,"updated":"2010-07-22 20:00:20"}
Doc seq: 2

You can also print information about the data file with the couch_dbinfo command:
sudo /opt/couchbase/bin/couch_dbinfo
/opt/couchbase/var/lib/couchbase/data/beer-sample/0.couch.1

DB Info (/opt/couchbase/var/lib/couchbase/data/beer-sample/0.couch.1) -
header at 16384
file format version: 12
update_seq: 9
purge_seq: 0
crc: CRC-32C
doc count: 9
deleted doc count: 0
data size: 6.8 kB
B-tree size: 1.2 kB
total disk size: 16.1 kB

Warmup is a process a restarted server must undergo before it can serve data.
During this process the server loads items persisted on disk into RAM. One approach
to load data is to do sequential loading of items from disk into RAM;

Rebalancing moves both the data stored in RAM, and the data stored on disk for each
bucket, and for each node, within the cluster