Solr
  1. Solr
  2. SOLR-4159

When we are starting a shard from rest, a leader should not consider it's last published state when deciding if it can be the new leader.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1, 6.0
    • Component/s: SolrCloud
    • Labels:
      None

      Description

      This makes it so that if a leader goes down before any replicas sync from it, one of the replicas won't take over. But because we wait a while for known replicas to come up and sync + pick the best leader, we should not need to be so strict in this protection and let a replica take a stab at being the leader - it may have been up to date and was only publishing through recovery phases to find that out.

        Activity

        Hide
        Commit Tag Bot added a comment -

        [trunk commit] Mark Robert Miller
        http://svn.apache.org/viewvc?view=revision&revision=1418790

        SOLR-4159: When we are starting a shard from rest, a potential leader should not consider it's last published state when deciding if it can be the new leader.

        Show
        Commit Tag Bot added a comment - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1418790 SOLR-4159 : When we are starting a shard from rest, a potential leader should not consider it's last published state when deciding if it can be the new leader.
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] Mark Robert Miller
        http://svn.apache.org/viewvc?view=revision&revision=1418791

        SOLR-4159: CHANGIES entry

        Show
        Commit Tag Bot added a comment - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1418791 SOLR-4159 : CHANGIES entry
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] Mark Robert Miller
        http://svn.apache.org/viewvc?view=revision&revision=1418793

        SOLR-4159: When we are starting a shard from rest, a potential leader should not consider it's last published state when deciding if it can be the new leader.

        Show
        Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1418793 SOLR-4159 : When we are starting a shard from rest, a potential leader should not consider it's last published state when deciding if it can be the new leader.
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] Mark Robert Miller
        http://svn.apache.org/viewvc?view=revision&revision=1418795

        SOLR-4159: CHANGES entry

        Show
        Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1418795 SOLR-4159 : CHANGES entry
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] Mark Robert Miller
        http://svn.apache.org/viewvc?view=revision&revision=1418795

        SOLR-4159: CHANGES entry

        Show
        Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1418795 SOLR-4159 : CHANGES entry
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] Mark Robert Miller
        http://svn.apache.org/viewvc?view=revision&revision=1418793

        SOLR-4159: When we are starting a shard from rest, a potential leader should not consider it's last published state when deciding if it can be the new leader.

        Show
        Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1418793 SOLR-4159 : When we are starting a shard from rest, a potential leader should not consider it's last published state when deciding if it can be the new leader.

          People

          • Assignee:
            Mark Miller
            Reporter:
            Mark Miller
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development