Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • briar briar
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 789
    • Issues 789
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 9
    • Merge requests 9
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • briar
  • briarbriar
  • Issues
  • #57

Closed
Open
Created Dec 01, 2015 by akwizgran@akwizgranOwner

Detect DB durability failures

If the app or device crashes, the database may fail to store data durably:

http://www.h2database.com/html/advanced.html#durability_problems

This may cause a wide range of problems, including data sync bugs where a peer believes we've stored some data because we acked it, but we failed to store the data durably. The peer won't ever resend the acked data.

To detect durability problems, store a flag in the DB indicating whether the DB is dirty. At startup, if the DB is dirty then a crash has occurred. Otherwise mark the DB dirty before handling the first transaction. At shutdown, mark the DB clean after handling the last transaction.

If a crash is detected then we can attempt to recover from any problems it may have caused, for example by asking peers to forget about any acks we've sent.

This approach relies on the assumption that if transaction A is committed before transaction B is started, it's not possible for the database to durably store transaction B but not transaction A. Is that a safe assumption?

Edited Nov 21, 2020 by Cleopatra
Assignee
Assign to
Time tracking