Skip to content

Propagate auto_id_timestamp in primary-replica resync#33964

Merged
dnhatn merged 3 commits intoelastic:masterfrom
dnhatn:resync-timestamp
Sep 22, 2018
Merged

Propagate auto_id_timestamp in primary-replica resync#33964
dnhatn merged 3 commits intoelastic:masterfrom
dnhatn:resync-timestamp

Conversation

@dnhatn
Copy link
Copy Markdown
Member

@dnhatn dnhatn commented Sep 22, 2018

A follow-up of #33693 to propagate max_seen_auto_id_timestamp in a primary-replica resync.

Relates #33693

A follow-up of elastic#33693 to propagate max_seen_auto_id_timestamp in a primary-replica resync.
@dnhatn dnhatn added >enhancement :Distributed/Recovery Anything around constructing a new shard, either from a local or a remote source. v7.0.0 v6.5.0 labels Sep 22, 2018
@elasticmachine
Copy link
Copy Markdown
Collaborator

Pinging @elastic/es-distributed

Copy link
Copy Markdown
Contributor

@bleskes bleskes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

for (IndexRequest request : replicationRequests) {
shards.index(request); // deliver via normal replication
}
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we miss an assertion to check that all shards are identical?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this check in the teardown but yes, I added an explicit one here :).

shard.applyIndexOperationOnPrimary(Versions.MATCH_ANY, VersionType.INTERNAL,
SourceToParse.source(shard.shardId().getIndexName(), "_doc", Integer.toString(i), new BytesArray("{}"), XContentType.JSON),
IndexRequest.UNSET_AUTO_GENERATED_TIMESTAMP, false);
randomNonNegativeLong(), randomBoolean());
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we randomly want to have normal ops here (i.e. UNSET_AUTO_GENERATED_TIMESTAMP)

if (in.getVersion().onOrAfter(Version.V_7_0_0_alpha1)) {
maxSeenAutoIdTimestampOnPrimary = in.readZLong();
} else {
maxSeenAutoIdTimestampOnPrimary = -1;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we use UNSET_AUTO_GENERATED_TIMESTAMP?

@dnhatn dnhatn merged commit e7ae2f9 into elastic:master Sep 22, 2018
@dnhatn
Copy link
Copy Markdown
Member Author

dnhatn commented Sep 22, 2018

Thanks @bleskes.

@dnhatn dnhatn deleted the resync-timestamp branch September 22, 2018 15:40
dnhatn added a commit that referenced this pull request Sep 23, 2018
A follow-up of #33693 to propagate max_seen_auto_id_timestamp in a
primary-replica resync.

Relates #33693
dnhatn added a commit that referenced this pull request Sep 23, 2018
kcm pushed a commit that referenced this pull request Oct 30, 2018
A follow-up of #33693 to propagate max_seen_auto_id_timestamp in a
primary-replica resync.

Relates #33693
kcm pushed a commit that referenced this pull request Oct 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed/Recovery Anything around constructing a new shard, either from a local or a remote source. >enhancement v6.5.0 v7.0.0-beta1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants