Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-7612

Docs: Improve replication backoff discussion

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.1.0
    • Component/s: None
    • 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

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        kzeller kzeller added a comment -

        Changed below:

        -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]

        Show
        kzeller kzeller added a comment - Changed below: -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]
        Hide
        kzeller kzeller added a comment -

        Chiyoung:

        I'm working this ticket and fixed most of these. However I need this information to finish/close this:

        -It would be very helpful to describe and/or link to a section on how to monitor the replication backoff when it is happening

        Is there a command line option/stat you can watch to monitor replication backoff?

        Let me know, provide and example and assign back to me to document.

        Regards,

        Karen

        Show
        kzeller kzeller added a comment - Chiyoung: I'm working this ticket and fixed most of these. However I need this information to finish/close this: -It would be very helpful to describe and/or link to a section on how to monitor the replication backoff when it is happening Is there a command line option/stat you can watch to monitor replication backoff? Let me know, provide and example and assign back to me to document. Regards, Karen
        Hide
        mikew Mike Wiederhold added a comment -

        There is a stat that is displayed in the Admin Console that shows the tap backoff rate. It is under the tap queues section and this can be monitored in by an administrator. Please let me know if you have any other questions.

        Show
        mikew Mike Wiederhold added a comment - There is a stat that is displayed in the Admin Console that shows the tap backoff rate. It is under the tap queues section and this can be monitored in by an administrator. Please let me know if you have any other questions.
        Hide
        mikew Mike Wiederhold added a comment -

        See my comment above.

        Show
        mikew Mike Wiederhold added a comment - See my comment above.
        Hide
        kzeller kzeller added a comment -

        Added final fix on monitoring backoff:

        <para> For more information about changing this setting, see <xref
        linkend="couchbase-admin-cmdline-cbepctl"/>. You can also monitor the progress of this
        backoff operation in Couchbase Web Console under Tap Queue Statistics | back-off rate. For more information,
        see <xref linkend="couchbase-admin-web-console-data-buckets-tapqueues" />.</para>

        Show
        kzeller kzeller added a comment - Added final fix on monitoring backoff: <para> For more information about changing this setting, see <xref linkend="couchbase-admin-cmdline-cbepctl"/>. You can also monitor the progress of this backoff operation in Couchbase Web Console under Tap Queue Statistics | back-off rate. For more information, see <xref linkend="couchbase-admin-web-console-data-buckets-tapqueues" />.</para>
        Hide
        kzeller kzeller added a comment -

        Added final fix on monitoring backoff:

        <para> For more information about changing this setting, see <xref
        linkend="couchbase-admin-cmdline-cbepctl"/>. You can also monitor the progress of this
        backoff operation in Couchbase Web Console under Tap Queue Statistics | back-off rate. For more information,
        see <xref linkend="couchbase-admin-web-console-data-buckets-tapqueues" />.</para>

        Show
        kzeller kzeller added a comment - Added final fix on monitoring backoff: <para> For more information about changing this setting, see <xref linkend="couchbase-admin-cmdline-cbepctl"/>. You can also monitor the progress of this backoff operation in Couchbase Web Console under Tap Queue Statistics | back-off rate. For more information, see <xref linkend="couchbase-admin-web-console-data-buckets-tapqueues" />.</para>

          People

          • Assignee:
            kzeller kzeller
            Reporter:
            perry Perry Krug
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes