You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Shalin Shekhar Mangar (JIRA)" <ji...@apache.org> on 2008/08/09 23:02:44 UTC
[jira] Updated: (SOLR-551) Solr replication should include the
schema also
[ https://issues.apache.org/jira/browse/SOLR-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shalin Shekhar Mangar updated SOLR-551:
---------------------------------------
Fix Version/s: 1.4
Affects Version/s: (was: 1.3)
1.4
Summary: Solr replication should include the schema also (was: SOlr replication should include the schema also)
> Solr replication should include the schema also
> -----------------------------------------------
>
> Key: SOLR-551
> URL: https://issues.apache.org/jira/browse/SOLR-551
> Project: Solr
> Issue Type: Improvement
> Components: replication
> Affects Versions: 1.4
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.