Significant difference between replicated database document counts

[Jason Aminto]

We have one master and two slave databases:

• Master - 15704799 total documents - raven build #2750
• Slave1 - 11647557 total documents - raven build #2750
• Slave2 - 10377971 total documents - raven build #2916

The counts of documents in the same collection in raven studio differs between all servers.

The counts of results for the same indexes in raven studio differs between all servers.

There are no conflict documents on the master.   Both slaves are read only.

Replication is configured to both servers with "Changed only" on the master.

The replication statistics on the master says there are no failures, and everyone has up to date LastReplicatedLastModified timestamps.

Why don't we have the same data on all three servers?

Thanks.

[Jason Aminto]

Is it possible to do an export from the master and import to the slaves? Or will that mess up replication?

[Oren Eini (Ayende Rahien)]

No, that will mess up replication.

You can nuke the slaves and they will re-replicate.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Thu, Sep 18, 2014 at 3:26 AM, Jason Aminto <jason....@gmail.com> wrote:

Is it possible to do an export from the master and import to the slaves?   Or will that mess up replication?

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Bishop]

Build 2.5.2750 has an issue where delete operations that are performed with the DeleteByIndex API do not get propagated to the slave nodes correctly. If your master has fewer documents than the slaves, this could be the explanation.

Another thing you could do is setup an index in the slaves that will check for conflict documents, like this:

from doc in docs 

where ((bool)doc["@metadata"]["Raven-Replication-Conflict"]) == true && ((bool)doc["@metadata"]["Raven-Replication-Conflict-Document"]) == false 

select new { DocumentId = (string)doc["@metadata"]["@id"] }

Dan

[Jason Aminto]

Thanks, Oren.

Unfortunately, i've deleted the dbs and set up replication from scratch at least three times already.   One of these DBs is on a brand new installation.

If you bring a new slave online and it takes, say, days to completely replicate the initial data, would you expect that documents written to the master during that replication time period would show up on the slave before all of the data is replicated?   In other words, if i'm seeing docs that were written today to the master appear on the slave, does that mean that the initial sync is "done"?   Cuz i am, and the total doc counts are still off by a few million.

Thanks, Dan.

Our doc count is actually much higher on the master than the slaves....

And i added the index you suggested about 12 hours ago and though it's stale, it's been chugging all day with no results.

[Oren Eini (Ayende Rahien)]

What build are you using?

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

[Jason Aminto]

Master and one slave are 2750

One slave is 2916

I'm trying to upgrade to 2916 by first bringing a new slave online with 2916, then upgrading the master to 2916.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

[James Tan]

I believe 2750 has concurrency handling issue that may cause the skip document for replication. This was the issue on our database too. Also I think this issue is fixed in 2916, but you need to upgrade master.

[Oren Eini (Ayende Rahien)]

Yes, please upgrade master and try this again

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.