CDCR doesn't do this yet but WDYT about an option where the target collection was _assumed_ to be the same as the source?
You're right, SOLR-8389 (and associated) should address this but I don't know what the progress is on that. Seems like a reasonable default in any case. Erick On Mon, Dec 18, 2017 at 9:29 AM, Elaine Cario <etca...@gmail.com> wrote: > We've recently been exploring options for disaster recovery, and took a > look at CDCR for our SolrCloud(s). It seems to meet our needs, but we've > stumbled into a couple of issues with configuration. > > The first issue is that currently CDCR is configured as a request handler > in solrconfig, but because we will use the same SolrConfig for collections > in different environments (e.g. development, qa, production), the config > will not always be deployed in an environment that has CDCR. As a last > resort, we are thinking we can drop back to an old-school xml include, and > configure different includes for different environments. This isn't > particularly elegant, but workable. Wondering if anyone has done it some > other way? > > The 2nd issue I haven't found a work-around for is the collection name > mapping within the cdcr request handler configuration. For some of our > applications, we "share" the same Solr config with many collections. When > deploying, we just "upconfig" to ZK, and either create a new collection > against that same config (config name != collection name). I'm not sure > with the collection name "baked into" the config how I would manage that, > except to switch to using a dedicated config for each collection. > > SOLR-8389 looks like it might solve some of these issues, or at least make > them easier to manage. Is this on the roadmap at all? > > Any ideas would be appreciated. Thanks!
