> Maybe I didn't fully understood what you explained: but doesn't this mean > that you'll have one index per day? > Or are you overwriting, via replicating, every shard and the number of shard > is fixed? > And why are you replicating from the local replica to the next shard? (why > not directly from active to next shard?)
Yes, you can have one index per day (for us, our boundary is typically 1 month, so is less of an issue). The 'oldest' replica in the round robin is overwritten, yes. We use fixed shard numbers, but you don't have to. Does yours need to be once a day? We used our own round robin code because it was pre-Solr Cloud... I'm not too familiar with them, but I believe it's certainly worth having a look at Solr Cloud or Katta - could be useful here in dynamically allocating shards. Peter On Thu, Nov 18, 2010 at 5:41 PM, Peter Karich <peat...@yahoo.de> wrote: > Hi Peter! > >> * I believe the NRT patches are included in the 4.x trunk. I don't >> think there's any support as yet in 3x (uses features in Lucene 3.0). > > I'll investage how much effort it is to update to solr4 > >> * For merging, I'm talking about commits/writes. If you merge while >> commits are going on, things can get a bit messy (maybe on source >> cores this is ok, but I have a feeling it's not). > > ok > >> * For moving data to a an 'offline' read-only core, this is the trickiest >> bit. >> We do this today by using a round-robin chain of remote shards and 2 >> local cores. At the boundary time (e.g. 1 day), the 'active' core is >> replicated locally, then this local replica is replicated to the next >> shard in the chain. Once everything is complete, the local replica is >> discarded, and the 'active' core is cleaned, being careful not to >> delete any new data since the replicated commit point. > > Maybe I didn't fully understood what you explained: but doesn't this mean > that you'll have one index per day? > Or are you overwriting, via replicating, every shard and the number of shard > is fixed? > And why are you replicating from the local replica to the next shard? (why > not directly from active to next shard?) > > Regards, > Peter. >
