http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Martin, Indexes in Raven are built on the background, and they will return stale results (with the appropriate notification) http://ayende.com/4504/raven-replication-scenarios#comment16http://ayende.com/4504/raven-replication-scenarios#comment16Mon, 17 May 2010 05:58:48 GMTDokieboy , Raven actually returns 204 (No Content), that is a top on my part http://ayende.com/4504/raven-replication-scenarios#comment15http://ayende.com/4504/raven-replication-scenarios#comment15Mon, 17 May 2010 05:57:57 GMTQuestion about RavenDb. Couchdb takes the approach that views are not indexed until the view is requested (in order to save cpu cycles). Personally I disagree with this approach because because I would prefer that the view be ready for me so to speak. Also views in couch do not pass stale results by default unless you pass the stale:"ok" param. I would in the majority of cases prefer to have the stale results and then have the view index update async after the request. I'd be really interested to hear what approach are you taking with Raven and your thought process behind it? http://ayende.com/4504/raven-replication-scenarios#comment14http://ayende.com/4504/raven-replication-scenarios#comment14Mon, 17 May 2010 00:25:29 GMTMinor point. Should the DELETE scenario return a 200 (OK) instead of a 201 (Created)? http://ayende.com/4504/raven-replication-scenarios#comment13http://ayende.com/4504/raven-replication-scenarios#comment13Sun, 16 May 2010 23:17:31 GMTI'd have to agree there, I'd prefer (and expect) indexes to be replicated (their definitions at least, let each server calculate the data though). Simpler administration, and its expected behavior. Even on a backup server, I'd opt to have it replicated - it doesn't matter if it is or isn't surely. http://ayende.com/4504/raven-replication-scenarios#comment12http://ayende.com/4504/raven-replication-scenarios#comment12Sun, 16 May 2010 23:17:26 GMTAyende, I see one benefit in the high availability scenario: simpler administration. Since you need both machines identical to serve the same requests, if automatic replication of indices is not in place, you need to repeat all index creations and modifications in all servers manually. I'm not saying that all replicated servers must have the same indexes, but I think having the option to replicate index definitions to other server would be nice. http://ayende.com/4504/raven-replication-scenarios#comment11http://ayende.com/4504/raven-replication-scenarios#comment11Sun, 16 May 2010 21:07:52 GMTJesus, Because it remove the ability to have different indexes on different machines. It complicate things because we now have to track whatever an index was changed or not. It means that we need to track _when_ an index was changed, in case the user wanted to reforce an index re-fresh. I don't see the benefit http://ayende.com/4504/raven-replication-scenarios#comment10http://ayende.com/4504/raven-replication-scenarios#comment10Sun, 16 May 2010 20:31:40 GMTWhy not to replicate just index definitions? http://ayende.com/4504/raven-replication-scenarios#comment9http://ayende.com/4504/raven-replication-scenarios#comment9Sun, 16 May 2010 20:10:22 GMTThe expectation is that you'll setup the indexes on all machines as part of your initial setup. Raven's indexes are the closest thing to a schema that it has. It doesn't make sense to replicate the indexes, because you might not want to pay the indexing cost on a backup only copy, or might want to have different projections. Moving the index data is too costly when we can just recalcute it http://ayende.com/4504/raven-replication-scenarios#comment8http://ayende.com/4504/raven-replication-scenarios#comment8Sun, 16 May 2010 15:22:51 GMTBen, That helps, yes, although I was thinking about stuff lower down the stack. With the master / master approach, don't you find that you get conflicts? http://ayende.com/4504/raven-replication-scenarios#comment7http://ayende.com/4504/raven-replication-scenarios#comment7Sun, 16 May 2010 15:19:42 GMTWith CouchDB, I've been looking at using replication in two ways. 1) Using HAProxy as a load balancer, then using CouchDB to continuously replicate between the two loads in a master-master approach. This in affect creates a database cluster in a very cost effective fashion - try doing that in SQL Server... 2) Similar fashion to above by using HAProxy, but in a master-child approach. Master holds all the data, then each child holds a subset done via the Replication Filters. Thinking about using this for geo-location of catalog data between our different stores... Having everything geo-located would be expensive, having just the subset would solve that problem. If the node goes down, then HAProxy restores back to the master, or more ideally another node which holds the data. I've been meaning to write a blog post about it.... These the kind of scenarios you are looking for? Ben http://ayende.com/4504/raven-replication-scenarios#comment6http://ayende.com/4504/raven-replication-scenarios#comment6Sun, 16 May 2010 14:57:29 GMTRobert, No, indexes aren't replicated. This is because it is easier to just compute them than to send them on the wire http://ayende.com/4504/raven-replication-scenarios#comment5http://ayende.com/4504/raven-replication-scenarios#comment5Sun, 16 May 2010 14:53:27 GMTHave you tested replication of indexes as well? Are they stores as data? http://ayende.com/4504/raven-replication-scenarios#comment4http://ayende.com/4504/raven-replication-scenarios#comment4Sun, 16 May 2010 14:47:49 GMTAre you sure you have defeated your stupidity? I'm trying for thirty years with little effect... http://ayende.com/4504/raven-replication-scenarios#comment3http://ayende.com/4504/raven-replication-scenarios#comment3Sun, 16 May 2010 14:39:37 GMTAndrew, That is pretty meaningless, since Raven is transactional, and the replication system only operation on committed data. http://ayende.com/4504/raven-replication-scenarios#comment2http://ayende.com/4504/raven-replication-scenarios#comment2Sun, 16 May 2010 14:35:43 GMTI'd probably test the usual 'bank transfer' scenario, ensuring transactions are atomic across replication too? What about concurrent transactions, does replication update correctly there? http://ayende.com/4504/raven-replication-scenarios#comment1http://ayende.com/4504/raven-replication-scenarios#comment1Sun, 16 May 2010 14:24:22 GMT