[jira] [Updated] (SOLR-11069) CDCR bootstrapping causes a core reload which loses the state of a bootstrap leading to infinite bootstrapping

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[jira] [Updated] (SOLR-11069) CDCR bootstrapping causes a core reload which loses the state of a bootstrap leading to infinite bootstrapping

JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/SOLR-11069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated SOLR-11069:
----------------------------------
    Summary: CDCR bootstrapping causes a core reload which loses the state of a bootstrap leading to infinite bootstrapping  (was: LASTPROCESSEDVERSION for CDCR is flawed when buffering is enabled)

> CDCR bootstrapping causes a core reload which loses the state of a bootstrap leading to infinite bootstrapping
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-11069
>                 URL: https://issues.apache.org/jira/browse/SOLR-11069
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public)
>          Components: CDCR
>    Affects Versions: 7.0
>            Reporter: Amrit Sarkar
>            Assignee: Erick Erickson
>
> {{LASTPROCESSEDVERSION}} (a.b.v. LPV) action for CDCR breaks down due to poorly initialised and maintained buffer log for either source or target cluster core nodes.
> If buffer is enabled for cores of either source or target cluster, it return {{-1}}, *irrespective of number of entries in tlog read by the {{leader}}* node of each shard of respective collection of respective cluster. Once disabled, it starts telling us the correct LPV for each core.
> Due to the same flawed behavior, Update Log Synchroniser may doesn't work properly as expected, i.e. provides incorrect seek to the {{non-leader}} nodes to advance at. I am not sure whether this is an intended behavior for sync but it surely doesn't feel right.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...