Details

    • Type: New Feature
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Journal
    • Labels:
      None

      Description

      Implement point in time rollback. This feature will allow the database to be forked at any historical commit point which is still retained. The intervening writes will still be available, so writes may be reapplied (by application specific logic). Rollback may be done for the entire database or for a specific namespace, e.g., corresponding to some triple store instance. The database must be partly offline during rollback (that is, read/write transactions and application submitted unisolated writer operations are not permitted during rollback).

      For the standalone database, rollback only needs to record a new entry in the Name2Addr index mapping the name of the each B+Tree onto the last checkpoint of that B+Tree prior to the rollback time.

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        This should be handled as a more general feature to create named versions of either some set of resources and/or all resources in some namespace together with a mechanism to indicate which is the "default" version and to select a version in an execution context as the default version. Any version may receive new writes. This mechanism can be used for provenance or lineage for an immortal database deployment in addition to effecting point in time rollback as described above.

        Show
        bryanthompson bryanthompson added a comment - This should be handled as a more general feature to create named versions of either some set of resources and/or all resources in some namespace together with a mechanism to indicate which is the "default" version and to select a version in an execution context as the default version. Any version may receive new writes. This mechanism can be used for provenance or lineage for an immortal database deployment in addition to effecting point in time rollback as described above.
        Hide
        bryanthompson bryanthompson added a comment -

        New versions will eventually have their own backing resources (index segment files) in scale-out, but initially they will depend on the index segment files for the historical version from which they are forked. Consider how to manage the co-location of that information and the constraints on the release of historical information. For example, if a version of a scale-out index is versioned, then new writes will go into shards named by the version (fooBLZG-208.1). If either the original version or the new version of that shard is then moved, we need to ensure that all necessary state for the shard which remains behind is preserved. This may well fall out automatically from the existing mechanisms since we do a compacting merge before we move a shard and historical resources are released once there are no B+Tree views on the data services within the configured retention age which depend on those resources.

        Show
        bryanthompson bryanthompson added a comment - New versions will eventually have their own backing resources (index segment files) in scale-out, but initially they will depend on the index segment files for the historical version from which they are forked. Consider how to manage the co-location of that information and the constraints on the release of historical information. For example, if a version of a scale-out index is versioned, then new writes will go into shards named by the version (fooBLZG-208.1). If either the original version or the new version of that shard is then moved, we need to ensure that all necessary state for the shard which remains behind is preserved. This may well fall out automatically from the existing mechanisms since we do a compacting merge before we move a shard and historical resources are released once there are no B+Tree views on the data services within the configured retention age which depend on those resources.

          People

          • Assignee:
            thompsonbry thompsonbry
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: