Yes, replicating the ancillary files (e.g. elevate.xml) is contingent on the index changing. You wouldn't want these files copied down every time the slave polled the master, so the replication is part of index replication if (and only if) the index on the master has changed.
You could manually copy the files from the master to the slave perhaps? Best, Erick On Mon, Sep 5, 2016 at 7:49 AM, Georg Sorst <georg.so...@gmail.com> wrote: > Hi! > > According to > https://cwiki.apache.org/confluence/display/solr/Index+Replication#IndexReplication-ReplicatingConfigurationFiles > : > >> Solr replicates configuration files only when the index itself is > replicated. That means even if a configuration file is changed on the > master, that file will be replicated only after there is a new > commit/optimize on master's index. > > However, the behaviour of some components can be changed by just changing a > configuration file. A good example is the Query Elevation component, which > is configured through conf/elevate.xml. The component explicitly allows > configuration during runtime, ie. without changing the index, by just > modifying the config. > > How can I get the Query Elevation component to play nice with Master-Slave > replication? So far I've tried: > > * Manually calling commit() after updating the elevate.xml (that's seems to > be no-op when the index hasn't changed: "No uncommitted changes. Skipping > IW.commit.") > * Manually calling update() after updating the elevate.xml (that's seems to > be no-op when the index hasn't changed: "No uncommitted changes. Skipping > IW.commit.") > * Manually calling > http://slave_host:port/solr/core_name/replication?command=fetchindex (doesn't > do anything either) > > What can I do, short of inserting some dummy data into the index?
