You've pretty much nailed getting back in sync, although there's a third way, just re-index all the changed content to M1 since M1 went down. Whether this is viable depends a lot on your particular situation. You'd want to disable replication while the reindexing happened.
Note that you have one other problem: any data that was either uncommitted on the master or didn't replicated to M2 will have to be re-indexed on M2. Actually, there's a 4th way. Just let M2 become the new primary master permanently (depends on M2 being comparable to M1) and when M1 gets repaired, it now becomes your master backup. Making the masters slaves of each other is just *asking* for trouble. I guess my summary is that there's no magic to allow that to happen, although we'll see with the SolrCloud stuff. Best Erick On Thu, Nov 10, 2011 at 12:35 PM, Robert Stewart <bstewart...@gmail.com> wrote: > If I have 2 masters in a master-master setup, where one master is the > live master and the other master acts as backup in slave mode, and > then during failover the slave master accepts new documents, such that > indexes become out of sync, how can original live master index get > back into sync with the slave master index? > > To be more clear: > > M1 - master SOLR server in master mode accepting all new document posts > M2 - master SOLR server in slave mode pulling index replicas from M1 > > M1 fails, so that new documents are posted to M2. > > M1 comes back to live, but now has index without new documents added > to M1 index. > > How do I get M1 index back in sync with M2 index? > > Of course, it can be some manual copy of index directory from M2 to > M1, or a re-config of M1 as a slave to pull replicas from M2 and then > re-configure, etc. > > Is there a better or simpler way that is automatic or some other best > practice? Is it possible for both M1 and M2 be configured as slaves > of each other so that they try to keep indexes in sync between > themselves? I am not sure how index "versioning" works with > replication. > > Thanks > Bob >
