Hi Hoss, we don't use autoCommit and autoSoftCommit. We don't use openSearcher. We don't use transaction log.
I can see it in the AdminGUI and with http://master_host:port/solr/replication?command=indexversion All files are replicated from master to slave, nothing lost. It is just that the gen/version differs and breaks our cronjobs which worked since solr 2.x. As you mentioned, it seams that the latest commit is fetched. Strange thing is, we start with a clean, empty index on master. With all commands we send a commit=true and, where applicable, an optimze=true. The master is always in state "optimzed and current" when replicating. How can it be that the searcher on master is referring to an older commit point if there is no such point. The logs show _AFTER_ the last optimize has finished a new searcher is started and the old one is closed. Also, we have replicateAfter startup, commit and optimize set but the AdminGUI and replication details only report replicateAfter commit and startup. Not really an error, but not that what is really set in the config! Very strange, I will try the patch. Regards Bernd Am 08.04.2013 20:12, schrieb Chris Hostetter: > : I know there was some effort to fix this but I must report > : that solr 4.2.1 has still problems with index version and > : index generation numbering in master/slave mode with replication. > ... > : RESULT: slave has different (higher) version number and is with generation > 1 ahead :-( > > Can you please provide more details... > > * are you using autocommit? with what settings? > * are you using openSearcher=false in any of your commits? > * where exactly are you looking that you see the master/slave out of sync? > * are you observing any actual problems, or just seeing that the > gen/version are reported as different? > > As Joel mentioned, there is an open Jira related purely to the *display* > of information about gen/version between master & slave, because in many > cases the "searcher" in use on the master may refer to an older commit > point, but it doesn't mean there is any actual problem in replication -- > the slave is still fetching & seraching the latest commit from the master > as intended.... > > https://issues.apache.org/jira/browse/SOLR-4661 > > > -Hoss >
