Document Conflicts

[Eniep Yrekcaz]

We have an environment with two servers set to replicate one to the other in a master-master setup. We are getting document conflicts. While trying to work through how to handle this situation, I tried something very similar to what is posted here: https://ravendb.net/docs/server/scaling-out/replication/handling-conflicts
The problem I found is that the two resulting conflict documents({docid}/conflicts/{guid}) only reside on one of the servers. So the call to documentStore.DatabaseCommands.Get(e.ConflictedVersionIds[i]); only gave me two null documents. Is this a bug and if not, how can this be worked around?

Thanks!

[Eniep Yrekcaz]

Sorry forgot to mention, I'm using build 2230

[Oren Eini (Ayende Rahien)]

The conflict usually only ever happens on one end, yes.

You need to resolve it there, and master/master will propogate the fix.

--
You received this message because you are subscribed to the Google Groups "ravendb" 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/groups/opt_out.
 
 

[Eniep Yrekcaz]

If I have load balancing setup though, both servers recognize the conflict, but it can only be resolved on one of them? What if the load balancer is pointing to the server that doesn't contain the conflict?

[Chris Marisic]

My understanding is that you should not use load balancers with RavenDB, they're probably fine for slave servers, but not for master servers for this exact reason.

The other reason load balancers are problematic, what about replication? It could load balance away needed replication information. I assume you're using private addresses to bypass the balancers for replication?

[Eniep Yrekcaz]

Thanks for the response. Mr. Eini can you verify that load balancing is something that's not recommended to use in conjunction with RavenDB? If that is that case, then I assume the recommended strategy for handling large load would be sharding? Please advise.

Thanks!

[Oren Eini (Ayende Rahien)]

Load balancing RavenDB should be done through the RavenDB API (ReadFromAllServers). Under that scenario, writes only happen on one server and proprogate from there.

On Tue, Feb 26, 2013 at 5:21 PM, Eniep Yrekcaz <peinearyd...@gmail.com> wrote:

Thanks for the response. Mr. Eini can you verify that load balancing is something that's not recommended to use in conjunction with RavenDB? If that is that case, then I assume the recommended strategy for handling large load would be sharding? Please advise.

Thanks!

--

[Eniep Yrekcaz]

I can't tell from your documentation how this works. Could you show me a page or expand on this a little? Don't I need to point at a specific Raven instance? If that instance goes down, how does failover work? 

[Vlad Kosarev]

Raven is smart enough to know all instances within replication cluster. It will cache all of them and use them even if your primary server goes down. As long as it has been up once you have nothing to worry about. It's magic.

[Vlad Kosarev]

This is the page on replication - http://ravendb.net/docs/server/scaling-out/replication

There is also info on replication+sharding. It depends on your domain how you want to handle load.

Here are your failover choices for replication - https://github.com/ayende/ravendb/blob/master/Raven.Client.Lightweight/Document/FailoverBehavior.cs

[Eniep Yrekcaz]

Thanks for your reply. The ReadFromAllServers option is one that Mr. Eini mentioned earlier. So the client will need to know of all of the ips for the various servers and that flag will have to be set and each server will have to know of the other one for replication? So if we make any changes to our infrastructure, we will have to make changes to  the client and each server instance?

[Vlad Kosarev]

You set up replication through ravendb. All it is is a document with a pointer to your replica.

When client connects to the server it will get ALL the servers that replicate from your given server.

So in 2 server master-master setup you have

raven1 points to raven2

raven2 points to raven1

Let's say your client has raven1 as connection string. As soon as it connects to raven1 it will get information that raven1 replicates to raven2. At that point that information is cached. If you take your client down and raven1 down and then bring client up it will still know that raven2 was available and it will connect to it. So as long as you've connected once to all running replicas your client will be aware of all of them.

Now, if you do make changes to server infrastructure then you do need to update things because it can't magically know where you moved your servers. You can obviously mitigate it by using dns entries like raven1/raven2/etc and then for replication pointing to http://raven1 and http://raven2. Then IPs are irrelevant and you can switch where raven runs as long as dns entries are the same.

ReadFromAllServers is a client failover option. There are no server settings you need to do for it. It just means that your client will try to read from all servers to distribute the load. If any of the server replicas go down client will ignore them, if they come back up client will use them again. Raven is intelligent when it comes to failover.

[Oren Eini (Ayende Rahien)]

Vlad,
If you change you topology, just update the document inside raven1 (to point to raven3 as well, for example).

The client periodically check to see that the topology it has is still current. By default, it make that check every 5 minutes or so.

--

[Vlad Kosarev]

Right! So Eniep, you can update topology pretty much on the fly without having to restart any servers or clients.

I think MSNBC guys were showing some similar stuff off in that webcast where they would just click a button and spin nodes up and down.

[Eniep Yrekcaz]

Thanks so much for all of your help. Do happen to know the link to that MSNBC webcast? I would be interested in viewing it.

[Vlad Kosarev]

http://www.youtube.com/watch?v=04bLT5XQH2I