In order to support witnessing for a log with constant checkpoint updates due to the frequency of new entries being included in the log, Rekor publishes a "stable" checkpoint periodically. Witnesses can verify consistency using this checkpoint and inclusion proofs can be built from the log size specified in the checkpoint. These stable checkpoints are persisted in Redis so that they can be accessed across replicated deployments, and Redis provided a straightforward locking mechanism to prevent concurrent writes.
We went with Redis because Redis was originally the only supported storage for persisting the search indices. Now you can write to either Redis or MySQL through the indexstorage interface.
We should create a similar interface for writing checkpoints to MySQL so that deployments can exclusively use MySQL if preferred.
Description
In order to support witnessing for a log with constant checkpoint updates due to the frequency of new entries being included in the log, Rekor publishes a "stable" checkpoint periodically. Witnesses can verify consistency using this checkpoint and inclusion proofs can be built from the log size specified in the checkpoint. These stable checkpoints are persisted in Redis so that they can be accessed across replicated deployments, and Redis provided a straightforward locking mechanism to prevent concurrent writes.
We went with Redis because Redis was originally the only supported storage for persisting the search indices. Now you can write to either Redis or MySQL through the indexstorage interface.
We should create a similar interface for writing checkpoints to MySQL so that deployments can exclusively use MySQL if preferred.