Skip to content

Mark snapshot repository as corrupted if its UUID changes underneath us #109936

Open
@DaveCTurner

Description

@DaveCTurner

Today if Elasticsearch observes a change in repository UUID it will accept the new UUID without question. IIRC this leniency dates back to the introduction of repository UUIDs in 7.x. However these days there should be no need for this leniency, and indeed if we see a repository UUID that differs from the one recorded in the cluster state then this indicates that something has changed the repository contents underneath us. With searchable snapshots, this is almost certainly a bad situation to be in. I think we should treat this situation similarly to how we react to seeing the RepositoryData generation change: apply the corruption marker and block further operations until the repository is explicitly re-registered.

Metadata

Metadata

Assignees

No one assigned

    Labels

    :Distributed Coordination/Snapshot/RestoreAnything directly related to the `_snapshot/*` APIs>enhancementSupportabilityImprove our (devs, SREs, support eng, users) ability to troubleshoot/self-service product better.Team:Distributed (Obsolete)Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions