Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-31091

blob store deletions.index file naming conventions can cause resilient instances to not compact blob stores correctly

    Details

    • Story Points:
      2
    • Sprint:
      NXRM Immortals Sprint 29
    • Notability:
      3
    • InvestmentLayer:
      support-escalated
    • Aha Concept:
      non-concept

      Description

      Scenario

      A customer may configure an active/passive pair of repo 3 instances which both refer to the same underlying blobstore(s) as part of a resiliency architecture.

      NEXUS-11967 introduced named deletions.index files unique to each "node" in a running HA-C (legacy) cluster of concurrently running nodes. Each instance has a unique node id.

      In the new resiliency architecture, this could introduce an issue in an active/passive scenario if the node id of the active and passive nodes differ.

      As instance 1 is used, the respective blobstore [NODE-ID]-deletions.index is updated to contain content marked as "to be deleted".

      When switching to instance 2, if it has a different node ID, this will prevent it from reading the original instance 1 deletions index file, and as a result will not perform equivalent/expected blobstore compactions against the same blobstore that instance 1 used.

      The document at https://help.sonatype.com/repomanager3/planning-your-implementation/backup-and-restore/backup-and-restore-in-amazon-web-services does not mention anything about consistent node ids, where they are stored, how they are generated, the deletions index file itself or what to backup from an instance data directory.

      The document at https://help.sonatype.com/repomanager3/planning-your-implementation/resiliency-and-high-availability/single-node-cloud-resilient-deployment-example-using-aws suggests a passive pod will be started from scratch and therefore implicitly suggests it will have a different node id than the active instance.

      The document https://help.sonatype.com/repomanager3/planning-your-implementation/backup-and-restore/prepare-a-backup#PrepareaBackup-NodeIDBackup suggests Node ID backup is crucial to normal operation of the product.

      Expected

      Design and document a resilient deletions index model that will mitigate the risk of two nodes that are intended to be identical from operating differently due to not accessing the same deletions history.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            plynch Peter Lynch
            Last Updated By:
            Rich Seddon Rich Seddon
            Team:
            NXRM - Optimus
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                tigCommentSecurity.panel-title