Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0
-
Fix Version/s: 2.1.0
-
Component/s: documentation
-
Security Level: Public
-
Labels:
Description
This page: http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-admin-tasks-replica-backoff.html
-We really don't want to refer to "replica nodes" and "source nodes" because it creates a lot of confusion, especially since other technologies use a replica/slave topology. We have replica vbuckets that are spread across the cluster along with the active vbuckets.
-"By default replica nodes will send backoff messages to source nodes when the disk write queue on the replica node contains one million items"...it's actually 1M or 10%, whichever is higher...that's not just configurable, it's how it works.
-"Both the reads/writes as well as replicated data must wait in disk write queue to be written to disk"...reads don't wait in any queue, and reads have nothing to do with replication
-It would be very helpful to describe and/or link to a section on how to monitor the replication backoff when it is happening
-We really don't want to refer to "replica nodes" and "source nodes" because it creates a lot of confusion, especially since other technologies use a replica/slave topology. We have replica vbuckets that are spread across the cluster along with the active vbuckets.
-"By default replica nodes will send backoff messages to source nodes when the disk write queue on the replica node contains one million items"...it's actually 1M or 10%, whichever is higher...that's not just configurable, it's how it works.
-"Both the reads/writes as well as replicated data must wait in disk write queue to be written to disk"...reads don't wait in any queue, and reads have nothing to do with replication
-It would be very helpful to describe and/or link to a section on how to monitor the replication backoff when it is happening
-We really don't want to refer to "replica nodes" and "source nodes" because it creates a lot of confusion, especially since other technologies use a replica/slave topology. We have replica vbuckets that are spread across the cluster along with the active vbuckets.
[fixed by referring to "replica data" and "replicated data at another node"]
-"By default replica nodes will send backoff messages to source nodes when the disk write queue on the replica node contains one million items"...it's actually 1M or 10%, whichever is higher...that's not just configurable, it's how it works.
[Changed to]
By default replica nodes will send backoff messages to source
nodes when the disk write queue on the replica node contains one
million items or 10%. You can configure this default to be a given number so long as
this value is less than 10% of the total items currently in a
replica partition.
-"Both the reads/writes as well as replicated data must wait in disk write queue to be written to disk"...reads don't wait in any queue, and reads have nothing to do with replication
[Fixed]