storage: eagerly replicate after splits only if not replicated

[petermattis]

---

This change is

[petermattis]

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, some commit checks pending.

---

storage/replica_command.go, line 2317 [r2] (raw file):

          r.store.replicateQueue.MaybeAdd(r, r.store.Clock().Now())
      }
      if len(split.NewDesc.Replicas) == 1 {

This is the key line which avoids replicating if we're also campaigning. Totally unclear to me why replicating while campaigning would be problematic. And note that the replica scanner could decide to replicate anyways so the bug seen in #7386 still exists without this PR, it is just much more rare.

@tschottdorf, @bdarnell I need your guidance here.

---

Comments from Reviewable

[petermattis]

PS I'm in no hurry to merge this.

---

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, some commit checks pending.

---

Comments from Reviewable

[tbg]

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.

---

storage/replica_command.go, line 2317 [r2] (raw file):

Previously, petermattis (Peter Mattis) wrote…

This is the key line which avoids replicating if we're also campaigning. Totally unclear to me why replicating while campaigning would be problematic. And note that the replica scanner could decide to replicate anyways so the bug seen in #7386 still exists without this PR, it is just much more rare.

@tschottdorf, @bdarnell I need your guidance here.

I'm looking.

---

Comments from Reviewable

[petermattis]

This is ready for another look. The first commit is revert of a revert.

---

Review status: 0 of 6 files reviewed at latest revision, 2 unresolved discussions, some commit checks pending.

---

storage/replica_command.go, line 2314 [r4] (raw file):

      // both new halves to speed up a potentially necessary replication. See
      // #7022.
      if len(split.UpdatedDesc.Replicas) == 1 {

I've decided to leave these restrictions in for now. The address @BramGrunier's concern that we're calling replicaQueue.MaybeAdd unnecessarily while still achieve fast replication of the initial ranges.

---

Comments from Reviewable

[tamird]

except for the "Fixes #7386" bit, since that underlying bug is still present.

---

Reviewed 6 of 6 files at r1, 1 of 1 files at r2, 1 of 1 files at r3, 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 2 unresolved discussions, all commit checks successful.

---

Comments from Reviewable

[petermattis]

Yeah, I'll remove that. #7386 was fixed by #7404.

---

Review status: all files reviewed at latest revision, 2 unresolved discussions, all commit checks successful.

---

Comments from Reviewable