Skip to content

Repository state tracking integration

Sami Hiltunen requested to merge smh-repository-generations into master

Tracking the expected and the actual repository states within a virtual storage is currently done by searching through the replication queue. This requires many variables to be taken in to account such as timings between different jobs and the job history of source nodes. To make the tracking easier, this commit adds two tables to record the latest state of repositories across the cluster:

  1. repositories table contains the expected state of a repository within a virtual storage.
  2. storage_repositories table contains the state of the repository on a given storage that is part of a virtual storage.

Cross-referencing storage_repositories with repositories makes it straightforward to figure out repositories which are in the expected state. If a repository on a storage is not in the expected state, appropriate corrective actions can be scheduled by diffing the expected record with the record of the stale storage.

Each repository has a generation number which increases monotonically for each write. The generation number can be used to deduce whether the repository has the latest changes or not. The generation number guarantees the repository is at least on the generation stored but it may also be on a later generation if an update was partially applied. To prevent the generation number from referring to outdated data, repository downgrades are rejected. Generation numbers get propagated via replication jobs which again guarantee the repository will be at least on the generation included in the job.

After the upgrade, there won't be any repositories in the tables and there might be replication jobs which do not have a generation number. To account for this, the downgrade protection is only applied to repositories which have a stored generation number, ensuring existing replication jobs during cluster upgrade are still accepted. As an upgraded primary receives new writes, the repository entries will be added to the tables and replication jobs with correct generation numbers scheduled.

Closes #2866 (closed)

Edited by Sami Hiltunen

Merge request reports