;>>>retries in the event of failure?
>>>>>
>>>>>Best,
>>>>>Erick
>>>>>
>>>>>On Mon, Apr 25, 2016 at 6:13 AM, tedsolr wrote:
>>>>>> I've done a bit of reading - found some other posts with similar
>>>>>> questions.
>>>>>> So I gather "Optimizing" a collection is rarely a good idea. It does not
>>>>>> need to be condensed to a single segment. I also read that it's up to the
>>>>>> client to keep track of updates in case commits don't happen on all the
>>>>>> replicas. Solr will commit and return success as long as one replica gets
>>>>>> the update.
>>>>>>
>>>>>> I have a state where the two replicas for one collection are out of sync.
>>>>>> One has some updates that the other does not. And I don't have log data
>>>>>> to
>>>>>> tell me what the differences are. This happened during a maintenance
>>>>>> window
>>>>>> when the servers got restarted while a large index job was running.
>>>>>> Normally
>>>>>> this doesn't cause a problem, but it did last Thursday.
>>>>>>
>>>>>> What I plan to do is select the replica I believe is incomplete and
>>>>>> delete
>>>>>> it. Then add a new one. I was just hoping Solr had a solution for this -
>>>>>> maybe using the ZK transaction logs to replay some updates, or force a
>>>>>> resync between the replicas.
>>>>>>
>>>>>> I will also implement a fix to prevent Solr from restarting unless one of
>>>>>> its config files has changed. No need to bounce Solr just for kicks.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
>>>>>> Sent from the Solr - User mailing list archive at Nabble.com.
>>>>
posts with similar
>>>>> questions.
>>>>> So I gather "Optimizing" a collection is rarely a good idea. It does not
>>>>> need to be condensed to a single segment. I also read that it's up to the
>>>>> client to keep track of up
27;t have log data to
>>>> tell me what the differences are. This happened during a maintenance window
>>>> when the servers got restarted while a large index job was running.
>>>> Normally
>>>> this doesn't cause a problem, but it did last Thursday.
>>>>
>>>> What I plan to do is select the replica I believe is incomplete and delete
>>>> it. Then add a new one. I was just hoping Solr had a solution for this -
>>>> maybe using the ZK transaction logs to replay some updates, or force a
>>>> resync between the replicas.
>>>>
>>>> I will also implement a fix to prevent Solr from restarting unless one of
>>>> its config files has changed. No need to bounce Solr just for kicks.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
>>>> Sent from the Solr - User mailing list archive at Nabble.com.
>>
gt;> What I plan to do is select the replica I believe is incomplete and delete
>>> it. Then add a new one. I was just hoping Solr had a solution for this -
>>> maybe using the ZK transaction logs to replay some updates, or force a
>>> resync between the replicas.
>>>
>>> I will also implement a fix to prevent Solr from restarting unless one of
>>> its config files has changed. No need to bounce Solr just for kicks.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
>>> Sent from the Solr - User mailing list archive at Nabble.com.
>
aybe using the ZK transaction logs to replay some updates, or force a
>> resync between the replicas.
>>
>> I will also implement a fix to prevent Solr from restarting unless one of
>> its config files has changed. No need to bounce Solr just for kicks.
>>
>>
>>
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
ut to fix the current situation, deleting a replica is the way to go? It
happens to be very small - lucky me.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272721.html
Sent from the Solr - User mailing list archive at Nabble.com.
just hoping Solr had a solution for this -
> maybe using the ZK transaction logs to replay some updates, or force a
> resync between the replicas.
>
> I will also implement a fix to prevent Solr from restarting unless one of
> its config files has changed. No need to bounce Solr ju
n context:
http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236p4272602.html
Sent from the Solr - User mailing list archive at Nabble.com.
hain definition:
indexationtime
/Jimi
From: tedsolr
Sent: Friday, April 22, 2016 8:48 PM
To: solr-user@lucene.apache.org
Subject: Replicas for same shard not in sync
I have a SolrCloud setup with v5.2.1 - just two hosts. A ZK ensemble of 3
hosts. Just today, cust
for
> the one shard? Or reload the collection? Do I need to delete the replica and
> build a new one?
>
> Thanks!
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Replicas-for-same-shard-not-in-sync-tp4272236.html
> Sent from the Solr - User mailing list archive at Nabble.com.
27;s the proper way to re-sync? Should I restart
the host with the out of sync collection? Or click the "optimize" button for
the one shard? Or reload the collection? Do I need to delete the replica and
build a new one?
Thanks!
--
View this message in context:
http://lucene.472066.n3
11 matches
Mail list logo
