RE: CDCR

: 01 December 2020 11:49 To: solr-user@lucene.apache.org Subject: RE: CDCR Hi Shalin, I did try to do that but it hadn't made any difference, the remote clusters did not update. Autocommit is already set on the remote clusters as follows: ${solr.autoCommit.maxTime:15

RE: CDCR

@lucene.apache.org Subject: Re: CDCR EXTERNAL EMAIL - Be cautious of all links and attachments. If you manually issue a commit operation on the remote clusters, do you see any updates? If yes, then you should set autoCommit on the remote clusters. If no, then check the logs on the cluster which

Re: CDCR

If you manually issue a commit operation on the remote clusters, do you see any updates? If yes, then you should set autoCommit on the remote clusters. If no, then check the logs on the cluster which is receiving the indexing operations and see if there are any errors. On Wed, Nov 25, 2020 at

Re: CDCR stress-test issues

Instead of CDCR you may simply duplicate the pipeline across both data centers. Then there is no need at each step of the pipeline to replicate (storage to storage, index to index etc.). Instead both pipelines run in different data centers in parallel. > Am 24.06.2020 um 15:46 schrieb Oakley,

RE: CDCR stress-test issues

Yes, I saw that yesterday. I guess that I was not the only one who noticed the unreliability after all. -Original Message- From: Ishan Chattopadhyaya Sent: Friday, July 17, 2020 1:17 AM To: solr-user Subject: Re: CDCR stress-test issues FYI, CDCR support, as it exists in Solr today

Re: CDCR stress-test issues

FYI, CDCR support, as it exists in Solr today, has been deprecated in 8.6. It suffers from serious design flaws and it allows such things to happen that you observe. While there may be workarounds, it is advisable to not rely on CDCR in production. Thanks, Ishan On Thu, 2 Jul, 2020, 1:12 am

RE: CDCR stress-test issues

For the record, it is not just Solr7.4 which has the problem. When I start afresh with Solr8.5.2, both symptoms persist. With Solr8.5.2, tlogs accumulate endlessly at the non-Leader nodes of the Source SolrCloud and are never released regardless of maxNumLogsToKeep setting And with Solr8.5.2,

Re: CDCR stress-test issues

On Wed, Jun 24, 2020 at 9:46 AM Oakley, Craig (NIH/NLM/NCBI) [C] wrote: > > In attempting to stress-test CDCR (running Solr 7.4), I am running into a > couple of issues. > > One is that the tlog files keep accumulating for some nodes in the CDCR > system, particularly for the non-Leader nodes

RE: CDCR behaviour

be greatly appreciated. Thanks, Daniel -Original Message- From: Jason Gerlowski Sent: 05 June 2020 12:18 To: solr-user@lucene.apache.org Subject: Re: CDCR behaviour Hi Daniel, Just a heads up that attachments and images are stripped pretty aggressively by the mailing list - none

Re: CDCR behaviour

Hi Daniel, Just a heads up that attachments and images are stripped pretty aggressively by the mailing list - none of your images made it through. You might more success linking to the images in Dropbox or some other online storage medium. Best, Jason On Thu, Jun 4, 2020 at 10:55 AM

Re: CDCR cpu usage 100% with some errors

I just saw this article. https://issues.apache.org/jira/browse/SOLR-13349 Can my issue be related to this? -- Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: cdcr replicator NPE errors

Thanks Shawn! Can any of the committers comment about the CDCR error that I posted above? Thanks Jay On Fri, Oct 25, 2019 at 2:56 PM Shawn Heisey wrote: > On 10/25/2019 3:22 PM, Jay Potharaju wrote: > > Is there a solr slack channel? > > People with @apache.org email addresses can readily

Re: cdcr replicator NPE errors

On 10/25/2019 3:22 PM, Jay Potharaju wrote: Is there a solr slack channel? People with @apache.org email addresses can readily join the ASF workspace, I do not know whether it is possible for others. That workspace might be only for ASF members. https://the-asf.slack.com In that

Re: cdcr replicator NPE errors

Is there a solr slack channel? Thanks Jay Potharaju On Fri, Oct 25, 2019 at 9:00 AM Jay Potharaju wrote: > Hi, > I am frequently seeing cdcr-replicator null pointer exception errors in > the logs. > Any suggestions on how to address this? > *Solr version: 7.7.2* > > ExecutorUtil > Uncaught

RE: CDCR tlog corruption leads to infinite loop

We also see an accumulation of tlog files on the target solrs. One of our production clouds crashed due to too many open files 2019-09-11 15:59:39.570 ERROR (qtp1355531311-81540) [c:bioreliance-catalog-testarticle-20190713 s:shard2 r:core_node8

Re: [CAUTION] Re: [CAUTION] Re: CDCR Queues API invocation with CloudSolrclient

I tried Shawn's suggestion to use SolrQuery Object instead of QT , still it is the same issue. Regards, Rajeswari On 7/24/19, 4:54 PM, "Natarajan, Rajeswari" wrote: Please look at the below test which tests CDCR OPS Api. This has "BadApple" annotation (meaning the test fails

Re: [CAUTION] Re: CDCR Queues API invocation with CloudSolrclient

Please look at the below test which tests CDCR OPS Api. This has "BadApple" annotation (meaning the test fails intermittently) https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/cloud/cdcr/CdcrOpsAndBoundariesTest.java#L73 This also is because of sometimes the

Re: CDCR Queues API invocation with CloudSolrclient

Btw , the code is copied from solr 7.6 source code. Thanks, Rajeswari On 7/24/19, 4:12 PM, "Natarajan, Rajeswari" wrote: Thanks Shawn for the reply. I am not saying it is bug. I just would like to know how to get the "lastTimestamp" by invoking CluodSolrClient reliabily.

Re: CDCR Queues API invocation with CloudSolrclient

Thanks Shawn for the reply. I am not saying it is bug. I just would like to know how to get the "lastTimestamp" by invoking CluodSolrClient reliabily. Regards, Rajeswari On 7/24/19, 3:14 PM, "Shawn Heisey" wrote: On 7/24/2019 3:50 PM, Natarajan, Rajeswari wrote: > Hi, > >

Re: CDCR Queues API invocation with CloudSolrclient

On 7/24/2019 3:50 PM, Natarajan, Rajeswari wrote: Hi, With the below API , the QueryResponse , sometimes have the "lastTimestamp" , sometimes not. protected static QueryResponse getCdcrQueue(CloudSolrClient client) throws SolrServerException, IOException { ModifiableSolrParams params =

Re: [CDCR]Unable to locate core

Thanks Amrith. Created a bug https://issues.apache.org/jira/browse/SOLR-13481 Regards, Rajeswari On 5/19/19, 3:44 PM, "Amrit Sarkar" wrote: Sounds legit to me. Can you create a Jira and list down the problem statement and design solution there. I am confident it will attract

Re: [CDCR]Unable to locate core

Sounds legit to me. Can you create a Jira and list down the problem statement and design solution there. I am confident it will attract committers' attention and they can review the design and provide feedback. Amrit Sarkar Search Engineer Lucidworks, Inc. 415-589-9269 www.lucidworks.com Twitter

Re: [CDCR]Unable to locate core

Thanks Amrith for creating a patch. But the code in the LBHttpSolrClient.java needs to be fixed too, if the for loop to work as intended. Regards Rajeswari public Rsp request(Req req) throws SolrServerException, IOException { Rsp rsp = new Rsp(); Exception ex = null; boolean

Re: CDCR one source multiple targets

Thanks, Arnold, Is the documentation not clear with the manner multiple CDCR targets can be configured? Amrit Sarkar Search Engineer Lucidworks, Inc. 415-589-9269 www.lucidworks.com Twitter http://twitter.com/lucidworks LinkedIn: https://www.linkedin.com/in/sarkaramrit2 Medium:

Re: CDCR - shards not in sync

Hi Jay, Can you look at the logs and identify if there are any exceptions occurring at particular Solr nodes the lagging shard is hosted? Amrit Sarkar Search Engineer Lucidworks, Inc. 415-589-9269 www.lucidworks.com Twitter http://twitter.com/lucidworks LinkedIn:

Re: [CDCR]Unable to locate core

Here is my close analysis: SolrClient request goes to the below method "request " in the class LBHttpSolrClient.java There is a for loop to try different live servers , but when doRequest method (in the request method below) sends exception there is no catch , so next re-try is not done.

Re: [CDCR]Unable to locate core

Hi We are using solr 7.6 and trying out bidirectional CDCR and I also hit this issue. Stacktrace INFO (cdcr-bootstrap-status-17-thread-1) [ ] o.a.s.h.CdcrReplicatorManager CDCR bootstrap successful in 3 seconds

Re: [CDCR]Unable to locate core

I am also facing this issue. Any resolution found on this issue, Please update. Thanks On 2/7/19, 10:42 AM, "Tim" wrote: So it looks like I'm having an issue with this fix: https://issues.apache.org/jira/browse/SOLR-11724 So I've messed around with this for a while and every

Re: CDCR one source multiple targets

This had a very simple solution if anybody else is wondering about the same issue.I had to define separate replica elements inside cdcr. Following is an example. target1:2181 techproducts techproducts target2:2181 techproducts techproducts 8 1000 128 1000disabled On Thu, Mar 21,

Re: CDCR issues

This sounds worthy of a jira. Especially if you can cite steps to reproduce. On Fri, Mar 22, 2019, 10:51 PM Jay Potharaju wrote: > This might be causing the high CPU in 7.7.x. > > >

Re: CDCR issues

This might be causing the high CPU in 7.7.x. https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5 That is related to this JDK bug https://bugs.openjdk.java.net/browse/JDK-8129861. Thanks Jay Potharaju On Thu, Mar 21, 2019

Re: CDCR one source multiple targets

I see a similar question asked but no answers there too. http://lucene.472066.n3.nabble.com/CDCR-Replication-from-one-source-to-multiple-targets-td4308717.html OP there is using multiple cdcr request handlers but in my case I am using multiple zkhost strings. It will be pretty limiting if we

Re: [CDCR]Unable to locate core

So it looks like I'm having an issue with this fix: https://issues.apache.org/jira/browse/SOLR-11724 So I've messed around with this for a while and every time the leader to leader replica portion works fine. But the Recovery portion (implemented as part of the fix above) fails. I've run a few

RE: [EXTERNAL] Re: [CDCR]Unable to locate core

successful as it was not able to locate s2r6 on targetServer1. Unsure of a fix at this time. -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Saturday, February 2, 2019 9:56 AM To: solr-user Subject: [EXTERNAL] Re: [CDCR]Unable to locate core CDCR does _not_

Re: [CDCR]Unable to locate core

Thank you for the reply. Sorry I did not include more information in the first post. So maybe there's some confusion here from my end. So both the target and source clusters are running in cloud mode. So I think you're correct that it is a different issue. So it looks like the source leader to

Re: [CDCR]Unable to locate core

CDCR does _not_ replicate to followers, it is a leader<->leader replication of the raw document. Once the document has been forwarded to the target's leader, then the leader on the target system should forward it to followers on that system just like any other update. The Solr JIRA is unlikely

Re: [CDCR]Unable to locate core

After some more investigation it seems that we're running into the same bug found here . However if my understanding is correct that bug in 7.3 was patched out. Unfortunately we're running into the same behavior in 7.5 CDCR is replicating

Re: CDCR "all" collections

Bram: Hmmm You can't do that OOB right now, but it might not be a hard thing to add. The current configuration allows the source collection to have a different name than the target collection so if you could make the assumption that the two collections always had the same name, it might be

Re: CDCR documentation typo

Thanks, but I think that section has been reworked, that typo isn't in the current documentation. It's doubtful that we'll re-release that reference guide. Best, Erick On Thu, Jul 19, 2018 at 3:14 AM, Yair Yotam wrote: > Hi, > > CDCR documentation page for v 7.1: >

Re: CDCR documentation typo

Thank you for sharing this with others. For documentation, it looks like it had been refactored and fixed already: https://lucene.apache.org/solr/guide/7_4/cdcr-config.html Regards, Alex. On 19 July 2018 at 06:14, Yair Yotam wrote: > Hi, > > CDCR documentation page for v 7.1: >

Re: CDCR traffic

Hi, In the case of CDCR, assuming both the source and target clusters are SSL > enabled, can we say that the source clusters’ shard leaders act as clients > to the target cluster and hence the data is encrypted while its transmitted > between the clusters? Yes, that is correct. SSL and

Re: CDCR traffic

Amrit, Further to the below conversation: As I understand, Solr supports SSL encryption between nodes within a Solr cluster and as well communications to and from clients. In the case of CDCR, assuming both the source and target clusters are SSL enabled, can we say that the source clusters’

Re: CDCR Custom Document Routing

Solr cdcr : https://issues.apache.org/jira/browse/SOLR-12380 deletebyid: https://issues.apache.org/jira/browse/SOLR-8889 Thanks Jay Potharaju On Mon, Jul 2, 2018 at 5:41 PM Jay Potharaju wrote: > Hi Amrit, > I am using a curl command to send a request to solr for deleting > documents. That

Re: CDCR Custom Document Routing

Hi Amrit, I am using a curl command to send a request to solr for deleting documents. That is because deleteById does not work for collections setup with implicit routing. curl http:/localhost:8983/solr/test_5_replica2/update/json/ -H 'Content-type:application/json/docs' -d '{ "delete":

Re: CDCR Custom Document Routing

Jay, Can you sample delete command you are firing at the source to understand the issue with Cdcr. On Tue, 3 Jul 2018, 4:22 am Jay Potharaju, wrote: > Hi > The current cdcr setup does not work if my collection uses implicit > routing. > In my testing i found that adding documents works without

Re: CDCR traffic

Hi Rajeswari, No it is not. Source forwards the update to the Target in classic manner. Amrit Sarkar Search Engineer Lucidworks, Inc. 415-589-9269 www.lucidworks.com Twitter http://twitter.com/lucidworks LinkedIn: https://www.linkedin.com/in/sarkaramrit2 Medium: https://medium.com/@sarkaramrit2

Re: CDCR setup with Custom Document Routing

Setups using implicit routers are not considered in the design so I don't think they will work today. That being said, it should be a simple enhancement to the CdcrReplicator to add the shard name to the UpdateRequest object. But ensure that both target and source have the exact same number and

Re: CDCR Bootstrap

Thanks, Tom. Is that correct that i have to execute this for each shard? On Thu, Apr 26, 2018 at 10:19 AM, Tom Peters wrote: > I'm not sure under what conditions it will be automatically triggered, but > if you manually wanted to trigger a CDCR Bootstrap you need to issue

Re: CDCR Bootstrap

I'm not sure under what conditions it will be automatically triggered, but if you manually wanted to trigger a CDCR Bootstrap you need to issue the following query to the leader in your target data center. /solr//cdcr?action=BOOTSTRAP= The masterUrl will look something like (change the

Re: CDCR Bootstrap

Anybody has idea how to trigger Solr CDCR BOOTSTRAP or under what condition it gets triggered ? Thanks, Susheel On Tue, Apr 24, 2018 at 12:34 PM, Susheel Kumar wrote: > Hello, > > I am wondering under what different conditions does that CDCR bootstrap > process gets

Re: CDCR broken for Mixed Replica Collections

Pardon, * I have added extensive tests for both the use-cases. Amrit Sarkar Search Engineer Lucidworks, Inc. 415-589-9269 www.lucidworks.com Twitter http://twitter.com/lucidworks LinkedIn: https://www.linkedin.com/in/sarkaramrit2 Medium: https://medium.com/@sarkaramrit2 On Thu, Apr 26, 2018 at

Re: CDCR broken for Mixed Replica Collections

Webster, I have patch uploaded to both Cdcr supporting Tlog: https://issues.apache.org/jira/browse/SOLR-12057 and core not getting failed while initializing for Pull type replicas: https://issues.apache.org/jira/browse/SOLR-12071 and awaiting feedback from open source community. The solution for

Re: CDCR broken for Mixed Replica Collections

CDCR won't really ever make sense for PULL replicas since the PULL replicas have no tlog and don't do any indexing and can't ever become a leader seamlessly. As for plans to address TLOG replicas, patches are welcome if you have a need. That's really how open source works, people add

Re: CDCR performance issues

Thanks for responding. My responses are inline. > On Mar 23, 2018, at 8:16 AM, Amrit Sarkar wrote: > > Hey Tom, > > I'm also having issue with replicas in the target data center. It will go >> from recovering to down. And when one of my replicas go to down in the >>

Re: CDCR performance issues

Yea, Amrit. to clarify we have 30 sec soft commit on target data center and for the test when we use Documents tab, the default Commit Within=1000 ms which makes the commit quickly on source and then we just wait for it to appear on target data center per commit strategy. On Fri, Mar 23, 2018

Re: CDCR performance issues

Susheel, That is the correct behavior, "commit" operation is not propagated to target and the documents will be visible in the target as per commit strategy devised there. Amrit Sarkar Search Engineer Lucidworks, Inc. 415-589-9269 www.lucidworks.com Twitter http://twitter.com/lucidworks

Re: CDCR performance issues

Just a simple check, if you go to source solr and index single document from Documents tab, then keep querying target solr for the same document. How long does it take the document to appear in target data center. In our case, I can see document show up in target within 30 sec which is our soft

Re: CDCR performance issues

Hey Tom, I'm also having issue with replicas in the target data center. It will go > from recovering to down. And when one of my replicas go to down in the > target data center, CDCR will no longer send updates from the source to > the target. Are you able to figure out the issue? As long as

Re: CDCR Invalid Number on deletes

Hi Chris, Sorry I was off work for few days and didn't follow the conversation. The link is directing me to https://issues.apache.org/jira/projects/SOLR/issues/SOLR-12063. I think we have fixed the issue stated by you in the jira, though the symptoms were different than yours. Amrit Sarkar

Re: CDCR Invalid Number on deletes

Nevermind I found itthe link you posted links me to SOLR-12036 instead of SOLR-12063 for some reason. On Tue, Mar 20, 2018 at 1:51 PM, Chris Troullis wrote: > Hey Amrit, > > Did you happen to see my last reply? Is SOLR-12036 the correct JIRA? > > Thanks, > > Chris > >

Re: CDCR Invalid Number on deletes

Hey Amrit, Did you happen to see my last reply? Is SOLR-12036 the correct JIRA? Thanks, Chris On Wed, Mar 7, 2018 at 1:52 PM, Chris Troullis wrote: > Hey Amrit, thanks for the reply! > > I checked out SOLR-12036, but it doesn't look like it has to do with CDCR, > and

Re: CDCR performance issues

I'm also having issue with replicas in the target data center. It will go from recovering to down. And when one of my replicas go to down in the target data center, CDCR will no longer send updates from the source to the target. > On Mar 12, 2018, at 9:24 AM, Tom Peters

Re: CDCR performance issues

Anyone have any thoughts on the questions I raised? I have another question related to CDCR: Sometimes we have to reindex a large chunk of our index (1M+ documents). What's the best way to handle this if the normal CDCR process won't be able to keep up? Manually trigger a bootstrap again? Or is

Re: CDCR performance issues

John: _What_ did you try and how did it fail? Please follow the instructions here: http://lucene.apache.org/solr/community.html#mailing-lists-irc . You must use the _exact_ same e-mail as you used to subscribe. If the initial try doesn't work and following the suggestions at the "problems"

Re: CDCR performance issues

please unsubscribe i tried to manaually unsubscribe On 3/9/2018 12:59 PM, Tom Peters wrote: Thanks. This was helpful. I did some tcpdumps and I'm noticing that the requests to the target data center are not batched in any way. Each update comes in as an independent update. Some follow-up

Re: CDCR performance issues

Thanks. This was helpful. I did some tcpdumps and I'm noticing that the requests to the target data center are not batched in any way. Each update comes in as an independent update. Some follow-up questions: 1. Is it accurate that updates are not actually batched in transit from the source to

RE: CDCR performance issues

These are general guidelines, I've done loads of networking, but may be less familiar with SolrCloud and CDCR architecture. However, I know it's all TCP sockets, so general guidelines do apply. Check the round-trip time between the data centers using ping or TCP ping. Throughput tests may

Re: CDCR performance issues

So I'm continuing to look into this and not making much headway, but I have additional questions now as well. I restarted the nodes in the source data center to see if it would have any impact. It appeared to initiate another bootstrap with the target. The lag and queueSize were brought back

Re: CDCR Invalid Number on deletes

Hey Amrit, thanks for the reply! I checked out SOLR-12036, but it doesn't look like it has to do with CDCR, and the patch that is attached doesn't look CDCR related. Are you sure that's the correct JIRA number? Thanks, Chris On Wed, Mar 7, 2018 at 11:21 AM, Amrit Sarkar

Re: CDCR Invalid Number on deletes

Hey Chris, I figured a separate issue while working on CDCR which may relate to your problem. Please see jira: *SOLR-12063* . This is a bug got introduced when we supported the bidirectional approach where an extra flag in tlog entry

Re: cdcr replication of new collection doesn't replicate

It looks like CDCR is entirely broken in 7.2.0 We have been using CDCR to replicate data from our on Prem systems to solrclouds hosted in Google Cloud. We used the lucene index upgrade to do an in place upgrade of the indexes in all our systems In at least one case we deleted all the rows from a

Re: CDCR configuration in solrconfig

Thanks everyone for your suggestions - I will definitely take a look at the Config API. We are building more automation into our deployment processes, and I think we could fit API calls into that. On Mon, Dec 18, 2017 at 4:16 PM, Webster Homer wrote: > We also have the

Re: CDCR configuration in solrconfig

We also have the same configurations used in different environments. We upload the configset to zookeeper and use the Config API to overlay environment specific settings in the solrconfig.xml. We have avoided having collections share the same configsets, basically for this reason. If CDCR

Re: CDCR configuration in solrconfig

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

Re: CDCR does not work

Pretty much what Webster and Erick mentioned, else please try the pdf I attached. I followed the official documentation doing that. Amrit Sarkar Search Engineer Lucidworks, Inc. 415-589-9269 www.lucidworks.com Twitter http://twitter.com/lucidworks LinkedIn:

Re: CDCR does not work

If Webster's idea doesn't solve it, the next thing to check is your tlogs on the source cluster. If you have a successful connection to the target and it's operative, the tlogs should be regularly pruned. If not, they'll collect updates forever. Also, your Solr logs should show messages as CDCR

Re: CDCR does not work

Check that you have autoCommit enabled in the target schema. Try sending a commit to the target collection. If you don't have autoCommit enabled then the data could be replicating but not committed so not searchable On Thu, Sep 28, 2017 at 1:57 AM, Jiani Yang wrote: > Hi, > >

RE: CDCR - how to deal with the transaction log files

k.hoef...@polarisalpha.com>> Date: Friday, Jul 28, 2017, 4:01 PM To: solr-user@lucene.apache.org <solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>> Cc: jmy...@wayfair.com <jmy...@wayfair.com<mailto:jmy...@wayfair.com>> Subject: [EXTERNAL] RE: CDCR - how to deal w

RE: CDCR - how to deal with the transaction log files

rit Sarkar [mailto:sarkaramr...@gmail.com] Sent: Friday, July 21, 2017 7:21 AM To: solr-user@lucene.apache.org Cc: jmy...@wayfair.com Subject: Re: CDCR - how to deal with the transaction log files Patrick, Yes! You created default UpdateLog which got written to a disk and then you chan

Re: CDCR - how to deal with the transaction log files

Message- > From: jmyatt [mailto:jmy...@wayfair.com] > Sent: Wednesday, July 12, 2017 4:49 PM > To: solr-user@lucene.apache.org > Subject: Re: CDCR - how to deal with the transaction log files > > glad to hear you found your solution! I have been combing over this post >

RE: CDCR - how to deal with the transaction log files

e Engineer (Direct)  719-452-7371 (Mobile) 719-210-3706 patrick.hoef...@polarisalpha.com PolarisAlpha.com  -Original Message- From: jmyatt [mailto:jmy...@wayfair.com] Sent: Wednesday, July 12, 2017 4:49 PM To: solr-user@lucene.apache.org Subject: Re: CDCR - how to deal with the transaction

Re: CDCR - how to deal with the transaction log files

I just voted for https://issues.apache.org/jira/browse/SOLR-11069 to get it resolved, as we are discussing to start using CDCR soon. On Fri, Jul 14, 2017 at 5:21 PM, Varun Thacker wrote: > https://issues.apache.org/jira/browse/SOLR-11069 is tracking why is >

Re: CDCR - how to deal with the transaction log files

https://issues.apache.org/jira/browse/SOLR-11069 is tracking why is LASTPROCESSEDVERSION=-1 on the source cluster always On Fri, Jul 14, 2017 at 11:46 AM, jmyatt wrote: > Thanks for the suggestion - tried that today and still no luck. Time to > write a script to naively /

Re: CDCR - how to deal with the transaction log files

Thanks for the suggestion - tried that today and still no luck. Time to write a script to naively / blindly delete old logs and run that in cron. *sigh* -- View this message in context: http://lucene.472066.n3.nabble.com/CDCR-how-to-deal-with-the-transaction-log-files-tp4345062p4346138.html

Re: CDCR - how to deal with the transaction log files

and tlogs again. -- Thank you Sean From: jmyatt <jmy...@wayfair.com<mailto:jmy...@wayfair.com>> Date: Wednesday, Jul 12, 2017, 6:58 PM To: solr-user@lucene.apache.org <solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>> Subject: [EXTERNAL] Re: CDCR - how to d

Re: CDCR - how to deal with the transaction log files

glad to hear you found your solution! I have been combing over this post and others on this discussion board many times and have tried so many tweaks to configuration, order of steps, etc, all with absolutely no success in getting the Source cluster tlogs to delete. So incredibly frustrating.

Re: CDCR - how to deal with the transaction log files

"Michael McCarthy" <michael.mccar...@gm.com> > wrote: > > > > We have been experiencing this same issue for months now, with > version > > 6.2. No solution to date. > > > > -

Re: CDCR - how to deal with the transaction log files

s now, with > version > > 6.2. No solution to date. > > > > -Original Message- > > From: Xie, Sean [mailto:sean@finra.org] > > Sent: Sunday, July 09, 2017 9:41 PM > > To: solr-user@lucene.apache.org > >

Re: CDCR - how to deal with the transaction log files

> From: Xie, Sean [mailto:sean@finra.org] > Sent: Sunday, July 09, 2017 9:41 PM > To: solr-user@lucene.apache.org > Subject: [EXTERNAL] Re: CDCR - how to deal with the transaction log > files > > Did another round of testing

Re: CDCR - how to deal with the transaction log files

olution to date. > > -Original Message- > From: Xie, Sean [mailto:sean@finra.org] > Sent: Sunday, July 09, 2017 9:41 PM > To: solr-user@lucene.apache.org > Subject: [EXTERNAL] Re: CDCR - how to deal with the transaction log > files > >

RE: CDCR - how to deal with the transaction log files

this same issue for months now, with version 6.2. No solution to date. -Original Message- From: Xie, Sean [mailto:sean@finra.org] Sent: Sunday, July 09, 2017 9:41 PM To: solr-user@lucene.apache.org Subject: [EXTERNAL] Re: CDCR - how to deal with the trans

RE: CDCR - how to deal with the transaction log files

09, 2017 9:41 PM To: solr-user@lucene.apache.org Subject: [EXTERNAL] Re: CDCR - how to deal with the transaction log files Did another round of testing, the tlog on target cluster is cleaned up once the hard commit is triggered. However, on source cluster, the tlog files stay there and never

RE: CDCR - how to deal with the transaction log files

We have been experiencing this same issue for months now, with version 6.2. No solution to date. -Original Message- From: Xie, Sean [mailto:sean@finra.org] Sent: Sunday, July 09, 2017 9:41 PM To: solr-user@lucene.apache.org Subject: [EXTERNAL] Re: CDCR - how to deal

Re: CDCR - how to deal with the transaction log files

Did another round of testing, the tlog on target cluster is cleaned up once the hard commit is triggered. However, on source cluster, the tlog files stay there and never gets cleaned up. Not sure if there is any command to run manually to trigger the updateLogSynchronizer. The

Re: CDCR - how to deal with the transaction log files

I have monitored the CDCR process for a while, the updates are actively sent to the target without a problem. However the tlog size and files count are growing everyday, even when there is 0 updates to sent, the tlog stays there: Following is from the action=queues command, and you can see

Re: CDCR - how to deal with the transaction log files

This should not be the case if you are actively sending updates to the target cluster. The tlog is used to store unsent updates, so if the connection is broken for some time, the target cluster will have a chance to catch up. If you don't have the remote DC online and do not intend to bring it

Re: cdcr replication only 1 node gets data

We too often end up with a shard looking like: { "name": "shard2", "range": "0-7fff", "state": "active", "replicas": [ { "name": "core_node1", "core": "sial-catalog-gene_shard2_replica2", "baseUrl": "http://uc1f-ecom-msc01:8983/solr;, "nodeName": "uc1f-ecom-msc01:8983_solr", "state":

Re: cdcr bootstrap errors

restarting the zookeeper on the source cloud seems to have helped On Tue, Jul 4, 2017 at 3:42 PM, Webster Homer wrote: > Another strange error message I'm seeing > 2017-07-04 18:59:40.585 WARN (cdcr-replicator-110-thread- > 4-processing-n:dfw-pauth-msc02:8983_solr) [

Re: cdcr bootstrap errors

Another strange error message I'm seeing 2017-07-04 18:59:40.585 WARN (cdcr-replicator-110-thread-4-processing-n:dfw-pauth-msc02:8983_solr) [ ] o.a.s.h.CdcrReplicator Failed to forward update request to target: sial-catalog-product org.apache.solr.common.SolrException: Could not load collection

Re: CDCR Alias support?

The CDCR request handler doesn't support aliases. The source and target collections listed in the replica must be collections, nothing happens if they are aliases for a collection. No errors anywhere, just nothing. If a non-existent collection is listed I see errors, with an alias it just doesn't

  1   2   >