HDDS-11775. Allow Ozone debug tools that need to read RocksDB to automatically create a checkpoint

[Tejaskriya]

What changes were proposed in this pull request?

Some ozone debug tools may require a consistent view into the RocksDB instance to function correctly and may give incorrect results if the DB is being used by a running OM. To fix this, we can have ozone debug operate on a RocksDB checkpoint if the Ozone process is running. This avoids users having to manually install RocksDB's ldb and make the checkpoint themselves. An optional flag --checkpoint in introduced, that instructs the command to create a checkpoint from the RocksDB instance provided and read that instead.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-11775

How was this patch tested?

Tested manually using a db instace:

$ ozone debug ldb --db=/path/to/om.db --checkpoint scan --cf=bucketTable -l=2
Created checkpoint at /path/to/om.db/checkpoint-ldb-25
{ "/volvol/rba-enc": {
  "metadata" : { },
  "objectID" : -9223372036658957312,
  "updateID" : 764916,
  "volumeName" : "volvol",
  "bucketName" : "rba-enc",
  "acls" : [ {
    "type" : "USER",
    "name" : "e000000",
    "aclScope" : "ACCESS"
  }, {
    "type" : "GROUP",
    "name" : "admin",
    "aclScope" : "ACCESS"
  } ],
  "isVersionEnabled" : false,
  "storageType" : "DISK",
  "creationTime" : 1696281889240,
  "modificationTime" : 1705316194747,
  "usedBytes" : 134800539212445,
  "usedNamespace" : 4660925,
  "quotaInBytes" : 1125899906842625,
  "quotaInNamespace" : 10000000,
  "bucketLayout" : "FILE_SYSTEM_OPTIMIZED",
  "owner" : "e000000"
}
, "/volvol/rba-hsh": {
  "metadata" : { },
  "objectID" : -9223372036658963968,
  "updateID" : 764890,
  "volumeName" : "volvol",
  "bucketName" : "rba-hsh",
  "acls" : [ {
    "type" : "USER",
    "name" : "e000000",
    "aclScope" : "ACCESS"
  }, {
    "type" : "GROUP",
    "name" : "admin",
    "aclScope" : "ACCESS"
  } ],
  "isVersionEnabled" : false,
  "storageType" : "DISK",
  "creationTime" : 1696281250503,
  "modificationTime" : 1706066759131,
  "usedBytes" : 78302551495152,
  "usedNamespace" : 9426110,
  "quotaInBytes" : 1125899906842625,
  "quotaInNamespace" : 10000000,
  "bucketLayout" : "FILE_SYSTEM_OPTIMIZED",
  "owner" : "e000000"
}
 }

--will be adding a robot test

[errose28]

Thanks for adding this @Tejaskriya. I wonder if it would be better to have checkpoint as its own command? This would provide a few potential benefits:

• Ability to take a DB checkpoint for uses outside the LDB tools itself
• No need to add --checkpoint to every other command that may need it (FSO repair in debug mode comes to mind)
• User explicitly provides a file name so they know where the checkpoint is and that it is safe to remove. Terminal output tends to get lost with history.

I'm thinking something like ozone debug ldb checkpoint --db=<path-to-db> --output=<new-db-dir>

[Tejaskriya]

@errose28 That does sound like a better idea. I'll update this PR with the new approach soon.