Synchronizing solrconfig is not a very desired behavior. Typically the solrconfigs of master and slaves tend to differ. For instance we may disable the UpdateHandler in slaves and there may be tuning done in master to optimize indexing etc etc. The index data is not dependent on the config itself.
Checking timestamps of schema is not done to optimize data transfer. New schema means recreating the core, which is expensive. --Noble On Fri, Apr 25, 2008 at 4:15 AM, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > I think that sounds correct. Why not also include solrconfig.xml? Also, why > bother with checking timestamps of those .xml files - they are small enough > that it's not worth complicating scripts to save a few KB of xfer only when > those files change. But maybe you want that to detect their change easily? > > > In any case, this would be a nice improvement! > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > > ----- Original Message ---- > > From: Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]> > > To: solr-dev@lucene.apache.org > > Sent: Wednesday, April 23, 2008 4:54:28 AM > > Subject: replication should include the schema also > > > > The current Solr replication just copy the data directory . So if the > > schema changes and I do a re-index it will blissfully copy the index > > and the slaves will fail because of incompatible schema. > > > > So the steps we follow are > > * Stop rsync on slaves > > * Update the master with new schema > > * re-index data > > * forEach slave > > ** Kill the slave > > ** clean the data directory > > ** install the new schema > > ** restart > > ** do a manual snappull > > > > The amount of work the admin needs to do is quite significant > > (depending on the no:of slaves). These are manual steps and very error > > prone > > > > The solution : > > Make the replication mechanism handle the schema replication also. So > > all I need to do is to just change the master and the slaves synch > > automatically > > > > What is a good way to implement this? > > > > We have an idea along the following lines > > > > This should involve changes to the snapshooter and snappuller scripts > > and the snapinstaller components > > > > Everytime the snapshooter takes a snapshot it must keep the timestamps > > of schema.xml and elevate.xml (all the files which might affect the > > runtime behavior in slaves) > > For subsequent snapshots if the timestamps of any of them is changed > > it must copy the all of them also for replication. > > > > The snappuller copies the new directory as usual > > > > The snapinstaller checks if these config files are present , > > > > if yes, > > * It can create a temporary core > > * install the changed index and configuration > > * load it completely and swap it out with the original core > > > > --Noble > >
