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

Every item sent twice in bi-directional XDCR

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: 3.0
    • Component/s: XDCR
    • Security Level: Public
    • Labels:
      None

      Description

      From my understanding, the XDCR replication code does not yet have the ability to distinguish incoming data from a remote cluster versus incoming application data.

      What this means is that every mutation sent from the remote cluster is attempted to be sent back. No data problems are encountered because of our conflict resolution, but this presents a significant performance and bandwidth limitation.

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

        Activity

        Hide
        junyi Junyi Xie (Inactive) added a comment -

        Let me make it clear, we do not send item twice during bi-directional xdcr. The destination will only send getMeta request back to source for each key. The bounce-back traffic is key and metadata only, not the document body.

        The reason behind this, during bi-dir xdcr, the replicator at destination side got notified about every persisted mutation from storage, but it has no idea where this mutation came from (say, from front-end workload, from source cluster, or from another cluster). Therefore, it just tried to replicate it to every destination which has been configured by user, including the source cluster if bi-dir xdcr.

        Compared with uni-dir xdcr, the bandwidth cost we pay in bi-dir xdcr is just key+metadata in returning traffic from destination back to source.

        Show
        junyi Junyi Xie (Inactive) added a comment - Let me make it clear, we do not send item twice during bi-directional xdcr. The destination will only send getMeta request back to source for each key. The bounce-back traffic is key and metadata only, not the document body. The reason behind this, during bi-dir xdcr, the replicator at destination side got notified about every persisted mutation from storage, but it has no idea where this mutation came from (say, from front-end workload, from source cluster, or from another cluster). Therefore, it just tried to replicate it to every destination which has been configured by user, including the source cluster if bi-dir xdcr. Compared with uni-dir xdcr, the bandwidth cost we pay in bi-dir xdcr is just key+metadata in returning traffic from destination back to source.
        Hide
        junyi Junyi Xie (Inactive) added a comment -

        Link to discussion on CBSE-291

        Show
        junyi Junyi Xie (Inactive) added a comment - Link to discussion on CBSE-291
        Hide
        perry Perry Krug added a comment -

        Thanks for the clarification Junyi. I understand that we're not sending the document body, but let's take a quick example of 800M items (which is what a customer is testing right now).

        800M items at 120bytes each just for the metadata (not even including the key) is another 90GB of bandwidth being used. That is pure dollars down the drain for the customer. At 70byte keys, that's another 50GB of data sent...

        Show
        perry Perry Krug added a comment - Thanks for the clarification Junyi. I understand that we're not sending the document body, but let's take a quick example of 800M items (which is what a customer is testing right now). 800M items at 120bytes each just for the metadata (not even including the key) is another 90GB of bandwidth being used. That is pure dollars down the drain for the customer. At 70byte keys, that's another 50GB of data sent...
        Hide
        dipti Dipti Borkar added a comment -

        this is what allows us to have a purely multi-master system with conflict resolution. eventually it will help adding conflict management as well.
        This request simply falls into optimizing XDCR for performance. and will be folded into those bugs.

        Show
        dipti Dipti Borkar added a comment - this is what allows us to have a purely multi-master system with conflict resolution. eventually it will help adding conflict management as well. This request simply falls into optimizing XDCR for performance. and will be folded into those bugs.
        Hide
        dipti Dipti Borkar added a comment -

        this behaviorimplementation specific. the requirement is to reduce latency and network traffic and this is something which is being worked using different approaches.

        Show
        dipti Dipti Borkar added a comment - this behaviorimplementation specific. the requirement is to reduce latency and network traffic and this is something which is being worked using different approaches.

          People

          • Assignee:
            dipti Dipti Borkar
            Reporter:
            perry Perry Krug
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes