Skip to content
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

Make IndexShard operation be more explicit about whether they are expected to run on a primary or replica #15282

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
3 participants
@bleskes
Copy link
Member

commented Dec 7, 2015

This commit cherry picks some infrastructure changes from the feature/seq_no branch to make merging from master easier.

More explicitly, IndexShard current have prepareIndex and prepareDelete methods that are called both on the primary as the replica, giving it a different origin parameter. Instead, this commits creates two explicit prepare_OnPrimary and prepare_OnReplica methods. This has the extra added value of not expecting the caller to use an Engine enum.

Also, the commit adds some code reuse between TransportIndexAction and TransportDeleteAction and their TransportShardBulkAction counter parts.

@bleskes

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2015

@jasontedor this should be familiar can you take a look?

After proving it's stable on master, I think it makes sense to cherry pick to 2.x to keep the code similar.

@jasontedor

This comment has been minimized.

Copy link
Member

commented Dec 7, 2015

LGTM.

bleskes added some commits Dec 7, 2015

Make IndexShard operation be more explicit about whether they are exp…
…ected to run on a primary or replica

This commit cherry picks some infrastructure changes from the `feature/seq_no` branch to make merging from master easier.

More explicitly, IndexShard current have  prepareIndex and prepareDelete methods that are called both on the primary as the replica, giving it a different origin parameter. Instead, this commits creates two explicit prepare*OnPrimary and prepare*OnReplica methods. This has the extra added value of not expecting the caller to use an Engine enum.

Also, the commit adds some code reuse between TransportIndexAction and TransportDeleteAction and their TransportShardBulkAction counter parts.

Closes #15282
can't enforce prepareIndexOnReplica is actually run on replicas
We need a proper primary hand off for that - an old primary and replicate to a new primary which is activated in the mean time

@bleskes bleskes force-pushed the bleskes:seq_no_friendly branch to 27715dc Dec 7, 2015

@bleskes

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2015

@jasontedor pushed another commit. It looks like we weren't ready for this yet on master.

update = operation.parsedDoc().dynamicMappingsUpdate();
if (update != null) {
throw new RetryOnPrimaryException(shardId,
"Dynamics mappings are not available on the node that holds the primary yet");

This comment has been minimized.

Copy link
@areek

areek Dec 7, 2015

Contributor

typo: "Dynamic" instead of "Dynamics"

@@ -1071,43 +1065,7 @@ public void close() {
}
}

/** Utility method to create either an index or a create operation depending

This comment has been minimized.

Copy link
@areek

areek Dec 7, 2015

Contributor

Nice!

@bleskes bleskes removed the v2.2.0 label Dec 8, 2015

@bleskes bleskes closed this in 82b502c Dec 8, 2015

@bleskes bleskes deleted the bleskes:seq_no_friendly branch Dec 8, 2015

@bleskes

This comment has been minimized.

Copy link
Member Author

commented Dec 8, 2015

merged to master. I'll give it a day and merge to 2.x

bleskes added a commit to bleskes/elasticsearch that referenced this pull request Dec 9, 2015

Make IndexShard operation be more explicit about whether they are exp…
…ected to run on a primary or replica (backport elastic#15282)

This commit cherry picks some infrastructure changes from the feature/seq_no branch to make merging from master easier.

More explicitly, IndexShard current have prepareIndex and prepareDelete methods that are called both on the primary as the replica, giving it a different origin parameter. Instead, this commits creates two explicit prepareOnPrimary and prepareOnReplica methods. This has the extra added value of not expecting the caller to use an Engine enum.

Also, the commit adds some code reuse between TransportIndexAction and TransportDeleteAction and their TransportShardBulkAction counter parts.

bleskes added a commit that referenced this pull request Dec 11, 2015

Make IndexShard operation be more explicit about whether they are exp…
…ected to run on a primary or replica (backport #15282)

This commit cherry picks some infrastructure changes from the feature/seq_no branch to make merging from master easier.

More explicitly, IndexShard current have prepareIndex and prepareDelete methods that are called both on the primary as the replica, giving it a different origin parameter. Instead, this commits creates two explicit prepareOnPrimary and prepareOnReplica methods. This has the extra added value of not expecting the caller to use an Engine enum.

Also, the commit adds some code reuse between TransportIndexAction and TransportDeleteAction and their TransportShardBulkAction counter parts.

Closes #15331

@bleskes bleskes added the v2.2.0 label Dec 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.