Thanks Walter and Mike. In our use case we have same schema on both source and target sites. The idea is if we can avoid mysql replication on the target site for a particular table in our mysql schema. Currently, we index some of the fields in that table in solr, we want to move all the fields to solr and index some of them and so store only for others.
On Wed, May 10, 2017 at 10:09 AM, Bharath Kumar <bharath.mvku...@gmail.com> wrote: > Yes Mike we have CDCR replication as well. > > On Wed, May 10, 2017 at 1:15 AM, Mike Drob <md...@apache.org> wrote: > >> > The searching install will be able to rebuild itself from the data >> storage install when that >> is required. >> >> Is this a use case for CDCR? >> >> Mike >> >> On Tue, May 9, 2017 at 6:39 AM, Shawn Heisey <apa...@elyograg.org> wrote: >> >> > On 5/9/2017 12:58 AM, Bharath Kumar wrote: >> > > Thanks Hrishikesh and Dave. We use SOLR cloud with 2 extra replicas, >> > will that not serve as backup when something goes wrong? Also we use >> latest >> > solr 6 and from the documentation of solr, the indexing performance has >> > been good. The reason is that we are using MySQL as the primary data >> store >> > and the performance might not be optimal if we write data at a very >> rapid >> > rate. Already we index almost half the fields that are in MySQL in solr. >> > >> > A replica is protection against data loss in the event of hardware >> > failure, but there are classes of problems that it cannot protect >> against. >> > >> > Although Solr (Lucene) does try *really* hard to never lose data that it >> > hasn't been asked to delete, it is not designed to be a database. It's >> > a search engine. Solr doesn't offer the same kinds of guarantees about >> > the data it contains that software like MySQL does. >> > >> > I personally don't recommend trying to use Solr as a primary data store, >> > but if that's what you really want to do, then I would suggest that you >> > have two complete Solr installs, with multiple replicas on both. One of >> > them will be used for searching and have a configuration you're already >> > familiar with, the other will be purely for data storage -- only certain >> > fields like the uniqueKey will be indexed, but every other field will be >> > stored only. >> > >> > Running with two separate Solr installs will allow you to optimize one >> > for searching and the other for data storage. The searching install >> > will be able to rebuild itself from the data storage install when that >> > is required. If better performance is needed for the rebuild, you have >> > the option of writing a multi-threaded or multi-process program that >> > reads from one and writes to the other. >> > >> > Thanks, >> > Shawn >> > >> > >> > > > > -- > Thanks & Regards, > Bharath MV Kumar > > "Life is short, enjoy every moment of it" > -- Thanks & Regards, Bharath MV Kumar "Life is short, enjoy every moment of it"
