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/07/20 22:06:31 UTC

[jira] Assigned: (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 reassigned SOLR-551:
------------------------------------------

    Assignee: Shalin Shekhar Mangar

> 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.3
>            Reporter: Noble Paul
>            Assignee: Shalin Shekhar Mangar
>
> 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.