Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of saasira@gmail.com designates
 209.85.213.172 as permitted sender)
MIME-Version: 1.0
From: Samba <saasira@gmail.com>
Date: Tue, 17 Apr 2012 21:06:23 +0530
Message-ID: 
 <CAKgWO9LZF0u_PYXjqt4B1-1prF8Ti5mP6JBKgGDc-LoU6VCp4Q@mail.gmail.com>
Subject: Multi Master replication : rejoining a node after split network
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=e89a8f643316b95f2604bde1b425

--e89a8f643316b95f2604bde1b425
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

We are evaluating Cassandra for a geographically distributed deployment
that requires multi master replication.

We have a few questions regarding how replication is handled in Cassandra,
like:


   1. Which mechanism is used to replicate the changes from one system to
   another: statement distribution or recording the changeset via triggers or
   storing the changeset in transaction log?
   2. Since replication is continuous copying of changes from one node to
   another, these changes would have to be snapshotted in order to sustain
   temporary network failures so that replication can resume after the network
   problem is healed. is there a mechanism to define how long we can
   store/archive the snaphotted changes before we discard and would demand a
   recreation of node from the scratch rather than rejoin
   3. What options are available for conflict resolution since we are
   talking about master-master replication across tens of nodes?
   4. If a node is rejoined after a split network where same records would
   have been modified on multiple nodes, is there a mechanism to merge the
   data, resolve conflicts and eventually reach to a consistent state?

Thanks and Regards,
Samba

--e89a8f643316b95f2604bde1b425
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<br><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">=
We are evaluating Cassandra for a geographically distributed deployment tha=
t requires multi master replication.<br><br>We have a few questions regardi=
ng how replication is handled in Cassandra, like:<br>

<br><ol><li>Which mechanism is used to replicate the changes from one syste=
m to another: statement distribution or recording the changeset via trigger=
s or storing the changeset in transaction log?</li><li>Since replication is=
 continuous copying of changes from one node to another, these changes woul=
d have to be snapshotted in order to sustain temporary network failures so =
that replication can resume after the network problem is healed. is there a=
 mechanism to define how long we can store/archive the snaphotted changes b=
efore we discard and would demand a recreation of node from the scratch rat=
her than rejoin</li>

<li>What options are available for conflict resolution since we are talking=
 about master-master replication across tens of nodes?</li><li>If a node is=
 rejoined after a split network where same records would have been modified=
 on multiple nodes, is there a mechanism to merge the data, resolve conflic=
ts and eventually reach to a consistent state?</li>

</ol></blockquote>Thanks and Regards,<br>Samba

--e89a8f643316b95f2604bde1b425--