New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Sequence Numbers to write operations #10708

Open
bleskes opened this Issue Apr 21, 2015 · 15 comments

Comments

Projects
None yet
8 participants
@bleskes
Member

bleskes commented Apr 21, 2015

Introduction

An Elasticsearch shard can receive indexing, update, and delete commands. Those changes are applied first on the primary shard, maintaining per doc semantics and are then replicated to all the replicas. All these operations happen concurrently. While we maintain ordering on a per doc basis, using versioning support there is no way to order them with respect to each other. Having such a per shard operation ordering will enable us to implement higher level features such as Changes API (follow changes to documents in a shard and index) and Reindexing API (take all data from a shard and reindex it into another, potentially mutating the data). Internally we could use this ordering to speed up shard recoveries, by identifying which specific operations need to be replayed to the recovering replica instead of falling back to a file based sync.

To get such ordering, each operation will be assigned a unique and ever increasing Sequence Number (in short, seq#). This sequence number will be assigned on the primary and replicated to all replicas. Seq# are to be indexed in Lucene to allow sorting, range filtering etc.

Warning, research ahead

What follows in this ticket is the current thinking about how to best implement this feature. It may change in subtle or major ways as the work continues. Is is important to implement this infrastructure in a way that is correct, resilient to failures, and without slowing down indexing speed. We feel confident with the approach described below, but we may have to backtrack or change the approach completely.

What is a Sequence

Applying an operation order on a primary is a simple question of incrementing a local counter for every operation. However, this is not sufficient to guarantee global uniqueness and monotonicity under error conditions where the primary shard can be isolated by a network partition. For those, the identity of the current primary needs to be baked into each operation. For example, late to arrive operations from an old primary can be detected and rejected.

In short, each operation is assigned two numbers:

  • a term - this number is incremented with every primary assignment and is determined by the cluster master. This is very similar to the notion of a term in Raft, a view-number in Viewstamped Replication or an epoch in Zab.
  • a seq# - this number is incremented by the primary with each operation it processes.

To achieve ordering, when comparing two operations , o1 & o2, we say that o1 < o2 if and only if s1.seq# < s2.seq# or (s1.seq# == s2.seq# and s1.term < s2.term). Equality and greater than are defined in a similar fashion.

For reasons explained later on, we maintain for each shard copy two special seq#:

  1. local checkpoint# - this is the highest seq# for which all lower seq# have been processed . Note that this is not the highest seq# the shard has processed due to the concurrent indexing, which means that some changes can be processed while previous more heavy ones can still be on going.
  2. global checkpoint# (or just checkpoint#) - the highest seq# for which the local shard can guarantee that all previous (included) seq# have been processed on all active shard copies (i.e., primary and replicas).

Those two numbers will be maintained in memory but also persisted in the metadata of every lucene commit.

Changes to indexing flow on primaries

Here is a sketch of the indexing code on primaries. Much of it is identical to the current logic. Changes or additions are marked in bold .

  1. Validate write consistency based on routing tables.
  2. Incoming indexing request is parsed first (rejected upon mapping/parsing failures)
  3. Under uid lock:
    1. Versioning is resolved to a fixed version to be indexed.
    2. Operation is assigned a seq# and a term
    3. Doc is indexed into Lucene.
    4. Doc is put into translog.
  4. Replication
    1. Failures in step 3 above are also replicated (eg due to failure of lucene tokenization)
    2. Send docs to all assigned replicas.
    3. Replicas respond with their current local checkpoint#.
    4. When all respond (or have failed), send answer to client.
  5. Checkpoint update:
    1. Update the global `checkpoint# to the highest seq# for which all active replicas have processed all lower seq# (inclusive). This is based on information received in 4.3 .
    2. If changed, send new global checkpoint# to replicas (can be folded into a heartbeat/next index req).

Changes to indexing flow on replicas

As above, this is sketch of the indexing code on replicas. Changes with the current logic are marked as bold.

  1. Validate request
    1. Seq#'s term is >= locally known primary term.
  2. Under uid lock:
    1. Index into Lucene if seq# > local copy and doesn't represent an error on primary.
    2. Add to local translog.
  3. Respond with the current local checkpoint#

Global Checkpoint# increment on replicas

The primary advances its global checkpoint# based on its knowledge of its local and replica's local checkpoint#. Periodically it shares its knowledge with the replicas

  1. Validate source:
    1. source's primary term is == locally known primary term.
  2. Validate correctness:
    1. Check that all sequence# below the new global checkpoint# were processed and local checkpoint# is of the same primary term. If not, fail shard.
  3. Set the shard’s copy of global checkpoint#, if it's lower than the incoming global checkpoint.

Note that the global checkpoint is a local knowledge of that is update under the mandate of the primary. It may be that the primary information is lagging compared to a replica. This can happen when a replica is promoted to a primary (but still has stale info).

First use case - faster replica recovery

Have an ordering of operations allows us to speed up the recovery process of an existing replica and synchronization with the primary. At the moment, we do file based sync which typically results in over-copying of data. Having a clearly marked checkpoint# allows us to limit the sync operation to just those documents that have changed subsequently. In many cases we expect to have no documents to sync at all. This improvement will be tracked in a separate issue.

Road map

Basic infra

  • Introduce Primary Terms (#14062)
  • Introduce Seq# and index them (#14651)
  • Introduce local checkpoints (#15390)
  • Introduce global checkpoints (#15485)
  • Replicated failed operations for which a seq# was assigned (@areek) #23314
  • Create testing infrastructure to allow testing replication as a unit test, but with real IndexShards (#18930)
  • Persist local and global checkpoints (#18949)
  • Update to Lucene 6.0 (#20793)
  • Persist global checkpoint in translog commits (@jasontedor) #21254
  • Reading global checkpoint from translog should be part of translog recovery (@jasontedor) #21934
  • transfer global checkpoint after peer recovery (@jasontedor) #22212
  • add translog no-op (@jasontedor) #22291
  • Handle retry on primary exceptions in shard bulk action; we currently potentially reuse the answers of the previous primary. This is needed for versioned operations and mapping conflicts (we process ops, the third op needs a mapping change, we reach out to the master, the master already processed that change from another shard and responds with nothing to do, we reparse the op but the node doesn't have the mapping changes yet, we throw a retry and re-run the previous ops as well, potentiall running into conflicts) (@bleskes)
  • Don't fail shards as stale if they fail a global check point sync - this will happen all the time when a primary is started and wants to sync the global checkpoint. To achieve this we agreed to change default behavior of shard failures for replication operations (with the exception of write operations, see later). If an operation fails on a replica, the primary shouldn't fail the replica or mark it as stale. Instead it should report this to the user by failing the entire operation. Write Replication Operation (i.e., sub classes of TransportWriteAction) should keep the current behavior. (@dakrone) #22874
  • Transfer sequence number "primary context" (i.e., in sync shards, tracked local checkpoints etc) upon primary relocation AND don't allow the old primary to operate as primary anymore (see IndexShard#verifyPrimary) (@jasontedor, #25122)

Replica recovery (no rollback)

A best effort doc based replica recovery, based on local last commit. By best effort we refer to having no guarantees on the primary
translog state and the likelihood of doc based recovery to succeed and not requiring a file sync

  • Move local checkpoint to max seq# in commit when opening engine #22212
    We currently have no guarantee that all ops above the local checkpoint baked into the commit will be replayed. That means that delete operations with a seq# > local checkpoint will not be replayed. To work around it (for now), we will move the local checkpoint artificially (at the potential expense of correctness) (@jasontedor)
  • Review correctness of POC and extract requirements for the primary side (@jasontedor) replaced with TLA+ work
  • Use seq# checkpoints for replica recovery (#22484 , @jasontedor)

Translog seq# based API

Currently translog keeps all operations that are not persisted into the last lucene commit. This doesn't imply that it can serve all operations from a given seq# and up. We want to move seq# based recovery where a lucene commit indicates what seq# a fully baked into it and the translog recovers from there.

  • Add min/max seq# to translog generations. (#22822, @jasontedor)
  • Add a smaller maximum generation size and automatically create new generations. Note that the total translog size can still grow to 512MB. However, dividing this in smaller pieces will allow a lucene commit will be able to trim the translog, even though we may need some operations from the non-current generation (see next bullet point). (#23606, @jasontedor)
  • Move translog trimming to use lastCommittedLocalCheckpoint and use that for recovering operations when opening a lucene index. BWC aspects (a replica on new node operating without seq#) TBD. (#24015, @jasontedor)
  • Adapt snapshots to dedup sequence numbers by primary term (by reading in reverse) (#27268, @dnhatn)
  • Allow to trim all ops above a certain seq# with a term lower than X (#30176 @vladimirdolzhenko)

Primary recovery (no rollback)

  • After recovering from the translog, the primary should close any gaps in its history by indexing no ops into the missing seq# (@s1monw, #24238)
  • After recovering, a primary should update its knowledge of its own local checkpoint (@ywelsch, #25468)

Primary promotion

  • Implement a clean transition between replica operations on the shard (with an older term) and operations with the new term.
  • Should trigger a translog role over (so operations from the new primary will always have a higher translog generation than any operation they may conflict with) (#24825 @bleskes)
  • Should close gaps in history. Note that this doesn't imply this information will be transferred to the replicas. That is the job of the primary/replica sync. (#24945 @jasontedor)

Live replica/primary sync (no rollback)

  • Add a task that streams all operations from the primary's global checkpoint to all shards. (@ywelsch #24858)

    • fails the shard on other failures (double think about shard closing)
    • triggers update of primary term on replica if needed
    • transfers shard's local checkpoint back to the new primary
    • progress reporting via the task manager infrastructure
  • When a replica shard increases its primary term under the mandate of a new primary, it should also update its global checkpoint; this gives us the guarantee that its global checkpoint is at least as high as the new primary and gives a starting point for the primary/replica resync (@ywelsch, #25422)

  • Replicas should throw their local checkpoint to the global checkpoint when detected a new primary. (@jasontedor, #25452)

Primary recovery with rollback

Needed to deal with discrepancies between translog and commit point that can result of failure during primary/replica sync

  • Make sure the translog keeps data based on the oldest commit (#24950)
  • A custom deletion policy to keep old commits around (@dnhatn, #27606)
  • Roll back before starting to recover from translog (lucene's deletion policy can clean commits before opening)(@dnhatn #27804)
  • Clean up commits once they are no longer needed. Lucene only calls the deletion policy upon commit. Since we keep older commit around based on the advancement of the global checkpoint, we can trim data earlier, i.e., once the global checkpoint has advanced enough(@dnhatn #28140).

Replica recovery with rollback

Needed to throw away potential wrong doc versions that ended up in lucene. Those "wrong doc versions" may still be in the translog of the replica but since we ignore the translog on replica recovery they will be removed.

  • Only use "valid" commit points as the basis for file based recovery (i.e., commit points below the global check point)(@dnhatn #28038)
  • Only use "valid" commit points as the basis for ops based recovery (lucene's deletion policy can clean commits before opening)(@dnhatn #28181)

Live replica/primary sync with rollback

  • Allow a shard to rollback to a seq# from before last known checkpoint# based on NRT readers
  • Index all operations missing from the rollback point up to the global checkpoint from local translog

Seq# as versioning

  • Change InternalEngine to to resolve collision based on seq# on replicas and recovery (@bleskes, #24060)
  • Change write API to allow specifying desired current seq# for the operation to succeed
  • Make doc level versioning an opt in feature (mostly for external versioning)

Shrunk indices

Shrunk indices have mixed histories.

  • The primary term of the new index should be higher than the source. (@jasontedor, #25307)
  • When recovering the primary shard we need to set it's maximum seqNo to the max of all the source shards. (@jasontedor, #25321)
  • (PS - while we're at it we can also transfer the max max_unsafe_auto_id_timestamp @jasontedor, #25356)

Adopt Me

  • Properly store seq# in lucene: we expect to use the seq# for sorting, during collision checking and for doing range searches. The primary term will only be used during collision checking when the seq# of the two document copies is identical. Mapping this need to lucene means that the seq# it self should be stored both as a numeric doc value and as numerical indexed field (BKD). The primary term should be stored as a doc value field and doesn't need an indexed variant. We also considered the alternative of encoding both term and seq# into a single numeric/binary field as it may save on a the disk lookup implied by two separate fields. Since we expect the primary term to be rarely retrieved, we opted for the simplicity of the two doc value fields solution. We also expect it to mean better compression. (@dakrone) #21480
  • Add primary term to DocWriteResponse (@jasontedor) #24171
  • how do we deal with the BWC aspects in the case that - a primary is running on a new node will one replica is on an old node and one replica is on a new one. In that case the primary will maintain seq# and checkpoints for itself and the replica on the new node. However if the primary fails it may be the case that the old replica is elected as primary. That means that the other replica will suddenly stop receiving sequence numbers. It is not clear if this really a problem and if so what the best approach to solve it. (@dakrone, #25277)
  • Introduce new shard states to indicated an ongoing primary sync on promotion. See #24841 (review) . We now have an alternative plan for this - see #28004 (comment)
  • Delay primary relocation if primary has not yet synced with replicas . See #24841 (review)

TBD

  • A primary that's allocated when in sync replicas aren't can advance the global checkpoint to a region that's unsafe - the primary doesn't about if it's local ops, which are above the global checkpoint actually exists on the other replicas (@ywelsch #25468).
  • File based recovery (both local and remote) can recreate deleted docs. If a delete is out of order with a previous index operation, we may replay the index operation on recovery, but not the delete. This has to do with the fact that we trim the translog/capture a starting point at an arbitrary generation, and replay all of it. Current solution - change the indexing plan on non-primary origin to never index to lucene below the local checkpoint (5.x is addressed in #25592)
  • How to deal with failures to sync the global check point? this is interesting as we will rely on the checkpoint to be eventually updated on all shard copies.
  • Throwing back local checkpoint to global checkpoint may leave us in a situation we don't have all ops in the translog to do primary/replica sync. This is because we don't have (yet) any guarantee that the translog has all ops above the global checkpoint. That shard will be problematic when promoted to primary (it doesn't have the data to do a sync), causing replica's local checkpoints to get stuck. This will change when we have a custom deletion policy but we may want to double check that and fail the primary if it can't sync it's replica.
  • When indexing stops, sync global checkpoint faster (now we wait on idle shard) (@jasontedor, #26591)
  • Make local check point storage lazy intitialized to protect against memory usage during recovery (@jasontedor, #27179)
  • Snapshot and restore may create a primary that violates all our checkpointing logic. We should quantify the scenarios this can happen and discuss appropriate solutions. A similar issue occurs with force allocate empty & stale primaries.
  • When indexing on a replica InternalEngine loads the primary term to resolve a potential conflict between two indexing operations to the same doc with the same seq#. Once we have proper rollbacks that should never be needed. Instead we should assert that the term is identical (and potentially that the doc it self is identical).

Completed Miscellaneous

  • Review feasibility of old indices (done and implemented in #22185 ) (@bleskes)
  • Remove Shadow replicas (@dakrone #23906)
  • If minimum of all local checkpoints is less than global checkpoint on the primary, do we fail the shard? No, this can happen when replicas pull back their local checkpoints to their version of the global checkpoint
  • Failed shards who's local checkpoint is lagging with more than 10000 (?) ops behind the primary . This is a temporary measure to allow merging into master without closing translog gaps during primary promotion on a live shard. Those will require the replicas to pick them up, which will take a replica/primary live sync
@shikhar

This comment has been minimized.

Show comment
Hide comment
@shikhar

shikhar May 5, 2015

Contributor

First use case - faster replica recovery

I'd argue the first use case is making replication semantics more sound :)

Contributor

shikhar commented May 5, 2015

First use case - faster replica recovery

I'd argue the first use case is making replication semantics more sound :)

bleskes added a commit that referenced this issue Oct 21, 2015

Introduce Primary Terms
Every shard group in Elasticsearch has a selected copy called a primary. When a primary shard fails a new primary would be selected from the existing replica copies. This PR introduces `primary terms` to track the number of times this has happened. This will allow us, as follow up work and among other things, to identify operations that come from old stale primaries. It is also the first step in road towards sequence numbers.

Relates to #10708
Closes #14062

bleskes added a commit that referenced this issue Nov 19, 2015

Add Sequence Numbers and enforce Primary Terms
Adds a counter to each write operation on a shard. This sequence numbers is indexed into lucene using doc values, for now (we will probably require indexing to support range searchers in the future).

On top of this, primary term semantics are enforced and shards will refuse write operation coming from an older primary.

Other notes:
- The add SequenceServiceNumber is just a skeleton and will be replaced with much heavier one, once we have all the building blocks (i.e., checkpoints).
- I completely ignored recovery - for this we will need checkpoints as well.
- A new based class is introduced for all single doc write operations. This is handy to unify common logic (like toXContent).
- For now, we don't use seq# as versioning. We could in the future.

Relates to #10708
Closes #14651

bleskes added a commit to bleskes/elasticsearch that referenced this issue Nov 22, 2015

Set an newly created IndexShard's ShardRouting before exposing it to …
…operations

The work for #10708 requires tighter integration with the current shard routing of a shard. As such, we need to make sure it is set before the IndexService exposes the shard to external operations.

bleskes added a commit that referenced this issue Nov 23, 2015

Set an newly created IndexShard's ShardRouting before exposing it to …
…operations

The work for #10708 requires tighter integration with the current shard routing of a shard. As such, we need to make sure it is set before the IndexService exposes the shard to external operations.

Closes #14918

bleskes added a commit that referenced this issue Nov 23, 2015

Set an newly created IndexShard's ShardRouting before exposing it to …
…operations

The work for #10708 requires tighter integration with the current shard routing of a shard. As such, we need to make sure it is set before the IndexService exposes the shard to external operations.

Closes #14918

bleskes added a commit that referenced this issue Dec 15, 2015

Introduce Local checkpoints
This PR introduces the notion of a local checkpoint on the shard level. A local check point is defined as a the highest sequence number for which all previous operations (i.e. with a lower seq#) have been processed.

relates to #10708

Closes #15390

formatting
@rkonda

This comment has been minimized.

Show comment
Hide comment
@rkonda

rkonda Mar 8, 2016

It's not clear as to what would happen in the following split brain scenario (scenario-1):

  1. split occurs, forming two networks
  2. the network that didn't have a master, elects a master (call this network-2)
  3. the master will elect a new primary (in network-2)
  4. the primary in network-2 now has incremented term value (say 11). The primary in network-1 continues to have the same term value (10 in this example)
  5. The connection between the networks is re-established.

In this case we need a strategy for reconciling the differences in the indexes, if there were change operations in both the networks. Does a strategy like that exist today? So far it seems like this situation is preventable by using min_master_nodes. However in case min_master_nodes is not set appropriately, some default strategy should come into effect I would think.

An example strategy could be:

  1. Keep logs of write operations in both networks for a configurable amount of time. If the networks' connectivity is restored within this time period: (a) Drop all nodes in network-2 to read-only replica status (b) Attempt to reconcile the differences, and use network-1's state if the differences are not reconcilable. (c) Remove read-only status
    If the connectivity isn't restored within that time, when connection is restored, all indices in network-2 that have competing primaries in network-1 will lose their shards, and replicas are created from network-1.

Another interesting situation (scenario-2) to consider:

  1. Continuing with the scenario described above until (4) ...
  2. network-1 has another split, creating network-1 and network-1a. Network-1a gives term value of 11 to the new primary in that network.
  3. network-1 completely fails, and connectivity between network-1a and network-2 are restored. Now we may have a scenario where the subsequent change operations might not fail but still lead to different indexes in the replicas, with some operations failing some of the time, creating a messy situation.

This would happen if there is no reconciliation strategy in effect.

I do see that the sequence numbering method will keep shards that have connectivity to both the networks, in integral state, in the case of scenario-1. In the case of scenario-2, it is possible that the same shard gets operations with same term values from multiple primaries, and that again could create faulty index in that replica.

I am still trying to understand Elasticsearch's cluster behavior. It's possible that I might have made assumptions that aren't correct.

rkonda commented Mar 8, 2016

It's not clear as to what would happen in the following split brain scenario (scenario-1):

  1. split occurs, forming two networks
  2. the network that didn't have a master, elects a master (call this network-2)
  3. the master will elect a new primary (in network-2)
  4. the primary in network-2 now has incremented term value (say 11). The primary in network-1 continues to have the same term value (10 in this example)
  5. The connection between the networks is re-established.

In this case we need a strategy for reconciling the differences in the indexes, if there were change operations in both the networks. Does a strategy like that exist today? So far it seems like this situation is preventable by using min_master_nodes. However in case min_master_nodes is not set appropriately, some default strategy should come into effect I would think.

An example strategy could be:

  1. Keep logs of write operations in both networks for a configurable amount of time. If the networks' connectivity is restored within this time period: (a) Drop all nodes in network-2 to read-only replica status (b) Attempt to reconcile the differences, and use network-1's state if the differences are not reconcilable. (c) Remove read-only status
    If the connectivity isn't restored within that time, when connection is restored, all indices in network-2 that have competing primaries in network-1 will lose their shards, and replicas are created from network-1.

Another interesting situation (scenario-2) to consider:

  1. Continuing with the scenario described above until (4) ...
  2. network-1 has another split, creating network-1 and network-1a. Network-1a gives term value of 11 to the new primary in that network.
  3. network-1 completely fails, and connectivity between network-1a and network-2 are restored. Now we may have a scenario where the subsequent change operations might not fail but still lead to different indexes in the replicas, with some operations failing some of the time, creating a messy situation.

This would happen if there is no reconciliation strategy in effect.

I do see that the sequence numbering method will keep shards that have connectivity to both the networks, in integral state, in the case of scenario-1. In the case of scenario-2, it is possible that the same shard gets operations with same term values from multiple primaries, and that again could create faulty index in that replica.

I am still trying to understand Elasticsearch's cluster behavior. It's possible that I might have made assumptions that aren't correct.

@bleskes

This comment has been minimized.

Show comment
Hide comment
@bleskes

bleskes Mar 8, 2016

Member

In this case we need a strategy for reconciling the differences in the indexes, if there were change operations in both the networks. Does a strategy like that exist today?

The current strategy, which seq# will keep enforcing but in easier/faster way, is that all replicas are "reset" to be an exact copy of the primary currently chosen by the master. As you noted, this falls apart when there are two residing masters in the cluster. Indeed, the only way to prevent this is by setting minimum master nodes - which is the number one most important setting to set in ES (tell it what the expected cluster size is)

If min master nodes is not set and a split brain occurs, resolution will come when one of the masters steps down (either by manual intervention or by detecting the other one). In that case all replicas will "reset" to the primary designated by the left over master.

Drop all nodes in network-2 to read-only replica status

This is similar to what ES does - nodes with no master will only serve read requests and block writes (by default, it can be configured to block reads).

it is possible that the same shard gets operations with same term values from multiple primaries, and that again could create faulty index in that replica.

If the term is the same from both primaries, the replica will accept them according to the current plan. The situation will be resolved when the network restores and the left over primary and replica sync but indeed there are potential troubles there. I have some ideas on how to fix this specific secondary failure (split brain is the true issue, after which all bets are off) but there are bigger fish to catch first :)

Member

bleskes commented Mar 8, 2016

In this case we need a strategy for reconciling the differences in the indexes, if there were change operations in both the networks. Does a strategy like that exist today?

The current strategy, which seq# will keep enforcing but in easier/faster way, is that all replicas are "reset" to be an exact copy of the primary currently chosen by the master. As you noted, this falls apart when there are two residing masters in the cluster. Indeed, the only way to prevent this is by setting minimum master nodes - which is the number one most important setting to set in ES (tell it what the expected cluster size is)

If min master nodes is not set and a split brain occurs, resolution will come when one of the masters steps down (either by manual intervention or by detecting the other one). In that case all replicas will "reset" to the primary designated by the left over master.

Drop all nodes in network-2 to read-only replica status

This is similar to what ES does - nodes with no master will only serve read requests and block writes (by default, it can be configured to block reads).

it is possible that the same shard gets operations with same term values from multiple primaries, and that again could create faulty index in that replica.

If the term is the same from both primaries, the replica will accept them according to the current plan. The situation will be resolved when the network restores and the left over primary and replica sync but indeed there are potential troubles there. I have some ideas on how to fix this specific secondary failure (split brain is the true issue, after which all bets are off) but there are bigger fish to catch first :)

@rkonda

This comment has been minimized.

Show comment
Hide comment
@rkonda

rkonda Mar 8, 2016

Thank you very much for your clarification. I rather enjoy all these discussions and your comments.

The current strategy, which seq# will keep enforcing but in easier/faster way, is that all replicas are "reset" to be an exact copy of the primary currently chosen by the master.

The situation will be resolved when the network restores and the left over primary and replica sync

I would like to clearly understand the reset/sync scenarios. What triggers reset/sync?

I can think of a couple of "normal" operation scenarios

  1. I would think that whenever a node joins a network, the master would initiate a sync/reset.
  2. If a replica fails for a request, I suppose the primary should keep attempting a sync/reset, otherwise the replica might keep diverging, and at some point the master has to decommission that replica, otherwise the reads would be inconsistent.

In the case of split brain, with multi-network replicas (assuming min master nodes is set), primary-1 has been assuming that this replica R (on this third node, say N-3) has been failing (because of its allegiance to primary-2 ) but still is in the network. Hence it would attempt sync/reset. How does this protocol work? Should master-1 attempt to decommission R at some point, going by assumption (2)?

This problem will occur in a loop if R is decommissioned but another replica is installed on N-3 in its place, by the same protocol. There will be contention on N-3 for "reset"-ing replica shards by both the masters.

I suppose one way to resolve this is by letting a node choose a master if there are multiple masters. If we did this, then whenever a node loses its master, it would choose the other master, and there will be a sync/reset and all is well.

However if the node chooses its master, the other master will lose quorum, and hence cease to exist, which is a good resolution for this issue in my opinion.

rkonda commented Mar 8, 2016

Thank you very much for your clarification. I rather enjoy all these discussions and your comments.

The current strategy, which seq# will keep enforcing but in easier/faster way, is that all replicas are "reset" to be an exact copy of the primary currently chosen by the master.

The situation will be resolved when the network restores and the left over primary and replica sync

I would like to clearly understand the reset/sync scenarios. What triggers reset/sync?

I can think of a couple of "normal" operation scenarios

  1. I would think that whenever a node joins a network, the master would initiate a sync/reset.
  2. If a replica fails for a request, I suppose the primary should keep attempting a sync/reset, otherwise the replica might keep diverging, and at some point the master has to decommission that replica, otherwise the reads would be inconsistent.

In the case of split brain, with multi-network replicas (assuming min master nodes is set), primary-1 has been assuming that this replica R (on this third node, say N-3) has been failing (because of its allegiance to primary-2 ) but still is in the network. Hence it would attempt sync/reset. How does this protocol work? Should master-1 attempt to decommission R at some point, going by assumption (2)?

This problem will occur in a loop if R is decommissioned but another replica is installed on N-3 in its place, by the same protocol. There will be contention on N-3 for "reset"-ing replica shards by both the masters.

I suppose one way to resolve this is by letting a node choose a master if there are multiple masters. If we did this, then whenever a node loses its master, it would choose the other master, and there will be a sync/reset and all is well.

However if the node chooses its master, the other master will lose quorum, and hence cease to exist, which is a good resolution for this issue in my opinion.

@bleskes

This comment has been minimized.

Show comment
Hide comment
@bleskes

bleskes Mar 8, 2016

Member

The two issues you mention indeed trigger a primary/replica sync. I'm not sure I follow the rest, I would like to ask you to continue the discussion on discuss.elastic.co . We try to keep github for issues and work items. Thx!

Member

bleskes commented Mar 8, 2016

The two issues you mention indeed trigger a primary/replica sync. I'm not sure I follow the rest, I would like to ask you to continue the discussion on discuss.elastic.co . We try to keep github for issues and work items. Thx!

@rkonda

This comment has been minimized.

Show comment
Hide comment
@makeyang

This comment has been minimized.

Show comment
Hide comment
@makeyang

makeyang Apr 5, 2016

Contributor

any plan to release this?
it seems after this release, u guys will make ES a AP system? will u provide config paramters to allow users to control ES to be a AP or CP system eventually?

Contributor

makeyang commented Apr 5, 2016

any plan to release this?
it seems after this release, u guys will make ES a AP system? will u provide config paramters to allow users to control ES to be a AP or CP system eventually?

@bleskes

This comment has been minimized.

Show comment
Hide comment
@bleskes

bleskes Apr 5, 2016

Member

@makeyang this will be released as soon as it is done. There's still a lot of work to do.

it seems after this release, u guys will make ES a AP system? will u provide config paramters to allow users to control ES to be a AP or CP system eventually?

ES is currently and will stay CP in the foreseeable future. If a node is partitioned away from the cluster it will serve read requests (configurable) but will block writes, in which case we drop availability. Of course in future there are many options but currently there are no concrete plans to make it any different.

Member

bleskes commented Apr 5, 2016

@makeyang this will be released as soon as it is done. There's still a lot of work to do.

it seems after this release, u guys will make ES a AP system? will u provide config paramters to allow users to control ES to be a AP or CP system eventually?

ES is currently and will stay CP in the foreseeable future. If a node is partitioned away from the cluster it will serve read requests (configurable) but will block writes, in which case we drop availability. Of course in future there are many options but currently there are no concrete plans to make it any different.

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue Apr 27, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue Apr 30, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 4, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 4, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 4, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 4, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 4, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 4, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 8, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 10, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 10, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

added TODO note for test regarding Lucene rollback

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

dropped extra debug info of replicas seq# stats

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

check source of a doc after trimming

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

minTranslogGeneration has NOT to refer to SeqNumbers

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

add check that translog is not corrupted after any IO exception

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

don't randomize max attempts to get into random IO exception

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

moved ensureOpen check and term check from TranslogReader to Translog

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

dropped redundant belowTerm paremter from reader.closeIntoTrimmedReader

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

Allow to trim all ops above a certain seq# with a term lower than X -…
… Relates to #10708

added test case with more attempts - random roll generation, checks for primary terms

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue May 11, 2018

vladimirdolzhenko added a commit that referenced this issue Jun 8, 2018

Allow to trim all ops above a certain seq# with a term lower than X (#…
…30176)

Allow to trim all ops above a certain seq# with a term lower than X

Relates to #10708

vladimirdolzhenko added a commit that referenced this issue Jun 8, 2018

vladimirdolzhenko added a commit to vladimirdolzhenko/elasticsearch that referenced this issue Jun 8, 2018

@dnhatn dnhatn referenced this issue Jun 28, 2018

Open

Per doc replica rollbacks #31637

0 of 11 tasks complete

ywelsch added a commit that referenced this issue Aug 7, 2018

Verify primary mode usage with assertions (#32667)
Primary terms were introduced as part of the sequence-number effort (#10708) and added in ES
5.0. Subsequent work introduced the replication tracker which lets the primary own its replication
group (#25692) to coordinate recovery and replication. The replication tracker explicitly exposes
whether it is operating in primary mode or replica mode, independent of the ShardRouting object
that's associated with a shard. During a primary relocation, for example, the primary mode is
transferred between the primary relocation source and the primary relocation target. After
transferring this so-called primary context, the old primary becomes a replication target and the
new primary the replication source, reflected in the replication tracker on both nodes. With the
most recent PR in this area (#32442), we finally have a clean transition between a shard that's
operating as a primary and issuing sequence numbers and a shard that's serving as a replication
target. The transition from one state to the other is enforced through the operation-permit system,
where we block permit acquisition during such changes and perform the transition under this
operation block, ensuring that there are no operations in progress while the transition is being
performed. This finally allows us to turn the best-effort checks that were put in place to prevent
shards from being used in the wrong way (i.e. primary as replica, or replica as primary) into hard
assertions, making it easier to catch any bugs in this area.

ywelsch added a commit that referenced this issue Aug 7, 2018

Verify primary mode usage with assertions (#32667)
Primary terms were introduced as part of the sequence-number effort (#10708) and added in ES
5.0. Subsequent work introduced the replication tracker which lets the primary own its replication
group (#25692) to coordinate recovery and replication. The replication tracker explicitly exposes
whether it is operating in primary mode or replica mode, independent of the ShardRouting object
that's associated with a shard. During a primary relocation, for example, the primary mode is
transferred between the primary relocation source and the primary relocation target. After
transferring this so-called primary context, the old primary becomes a replication target and the
new primary the replication source, reflected in the replication tracker on both nodes. With the
most recent PR in this area (#32442), we finally have a clean transition between a shard that's
operating as a primary and issuing sequence numbers and a shard that's serving as a replication
target. The transition from one state to the other is enforced through the operation-permit system,
where we block permit acquisition during such changes and perform the transition under this
operation block, ensuring that there are no operations in progress while the transition is being
performed. This finally allows us to turn the best-effort checks that were put in place to prevent
shards from being used in the wrong way (i.e. primary as replica, or replica as primary) into hard
assertions, making it easier to catch any bugs in this area.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment