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

[BUG] [Remote Store] Getting old sequence number after restoring data from remote segment store #5971

Closed
sachinpkale opened this issue Jan 23, 2023 · 3 comments
Labels
bug Something isn't working Storage:Durability Issues and PRs related to the durability framework v2.6.0 'Issues and PRs related to version v2.6.0'

Comments

@sachinpkale
Copy link
Member

Describe the bug

  • Restoring data from remtoe store for an index sets sequence number back to last refresh number. Even though primary term changes and (primary term, sequence number) combination is still unique, this is a regression on the current behavior of seq number.
  • With remote translog, this bug is mitigated as we replay the operations from remote translog from last refresh to max sequence number in remote translog.

To Reproduce
Steps to reproduce the behavior:

  1. Setup 3 node cluster.
  2. Create index with remote segment store enabled (do not enable remote translog)
  3. Index should have 1 shard and 0 replica.
  4. Index 20 documents. Sequence number of last operation should be 19, with primary term 1.
  5. Explicit Refresh using API
  6. Index 20 more documents. Sequence number of last operation should be 39, with primary term 1.
  7. Explicit Refresh using API
  8. Bring down the node with primary shard.
  9. This should turn the index red.
  10. Close the index and restore from remote store.
  11. Index would turn GREEN and number of docs would show as 40.
  12. Index 1 more document, the index response will have sequence number as 20, with primary term 2.

Expected behavior

  1. The sequence number in the response of last index operation should be 40, with primary term 2.
@sachinpkale sachinpkale added bug Something isn't working untriaged Storage:Durability Issues and PRs related to the durability framework v2.6.0 'Issues and PRs related to version v2.6.0' and removed untriaged labels Jan 23, 2023
@ashking94
Copy link
Member

lets say if the do the following -
index 20 docs, refresh -> primary term 1, seq no 19
index 20 docs, refresh -> primary term 1, seq no 39
index 20 docs, refresh -> primary term 1, seq no 59
stop node where the index shard is located.
Now restore. Index a doc, will this lead to seq no 19? or will it be 39?

@sachinpkale
Copy link
Member Author

lets say if the do the following - index 20 docs, refresh -> primary term 1, seq no 19 index 20 docs, refresh -> primary term 1, seq no 39 index 20 docs, refresh -> primary term 1, seq no 59 stop node where the index shard is located. Now restore. Index a doc, will this lead to seq no 19? or will it be 39?

It would be 40.

@sachinpkale
Copy link
Member Author

Fixed in #5970

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Storage:Durability Issues and PRs related to the durability framework v2.6.0 'Issues and PRs related to version v2.6.0'
Projects
None yet
Development

No branches or pull requests

2 participants