Turns out I already created a JIRA in 4.0-alpha... SOLR-3397
Added comments here to that JIRA. On Mon, Sep 23, 2013 at 6:39 PM, Shawn Heisey <[email protected]> wrote: > On 9/23/2013 2:06 PM, Erick Erickson wrote: >> >> Let's say a configuration is running SolrCloud _and_ has <lst >> name="master"> or <lst name="slave"> bits defined in the replication >> handler. Is it valid? Taken care of? Is it worth a JIRA to barf if we >> detect that condition? >> >> Because it strikes me as something that's at worst undefined behavior, >> at best ignored and somewhere in the middle does replications as well >> as peer synchs as well as distributed updates. >> >> Under any circumstances it doesn't seem like the user is doing the right >> thing. > > > Initial thought: Yes, detect and explode. > > Second thought: Allowing replication config for the expert user (possibly > for backup purposes) might be useful. > > Third thought: Yes, detect and explode. If someone wanted to write an > application that used the handler as a direct API rather than through > solrconfig.xml configuration, that would work with no problem. SolrCloud > basically requires that the /replication handler be enabled, but not > configured. > > Is the replication API fully documented anywhere? It might be nice to > provide a skeletal example java application that talks to the replication > API for simple index backup purposes. It would be particularly nice if it > used CloudSolrServer (or the ZK client classes) and showed how to back up > and restore multiple shards. If I had any idea how to write such an > application, I would have already gotten started on it. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
