The idea is to ensure that the replicated index should be in sync with the rest of the system. As I see it schema.xml is the only configuration that the index depends on.
If you look at replication mechanisms of Databases, they replicate the schema (DDL) also, without which the replicated data will be inconsistent.But database replications will not replicate the server configurations . For starters we can assume that schema replication is good enough. --Noble On Fri, Apr 25, 2008 at 10:17 PM, Bill Au <[EMAIL PROTECTED]> wrote: > Synchronizing solrconfig.xml is definitely not a good idea. Typically the > master has a post commit/optimize hook to execute > snapshooter. > > Solr's replication is meant for replicating the Lucene index. One can argue > that the schema is part of the Solr index > so it should be included in the replication. But I don't think it would be > use to do software installation. I don't think > we should use it to distribute configuration files, just like we shouldn't > use it to distribute updated to the Solr binaries. > > Bill > > On Fri, Apr 25, 2008 at 4:48 AM, Guillaume Smet <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Apr 25, 2008 at 6:05 AM, Noble Paul നോബിള് नोब्ळ् > > <[EMAIL PROTECTED]> wrote: > > > 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. > > > > +1 for not synchronizing the solrconfig.xml itself. > > > > But perhaps we could have a solrconfig.slave.xml which could be > > synchronized with slaves' solrconfig.xml if present? > > > > -- > > Guillaume > > >
