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
>> target data center, CDCR wil
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 at
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
LinkedIn:
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
co
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 the
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 wrote:
>
> Anyone have
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
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" lin
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 ques
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 t
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 b
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 do
12 matches
Mail list logo
