ValidateRollups
Checks the rollup archives of the tenant for the inconsistencies a restore (or a dump taken during a recompute) can leave: a pointer without rows, rows above the pointer, a watermark ahead of the rows, a missing generation map. Read only: the server runs counts and MAX/MIN statements, nothing is changed.
Examples
Check all rollup archives of the tenant:
octo-cli -c ValidateRollups
Check one rollup archive:
octo-cli -c ValidateRollups -id "69fda707d47638c68edc7fea"
Check all rollups and exit non-zero when one is inconsistent or not checked (DR runbook gate after a restore):
octo-cli -c ValidateRollups -ff
Options
| Short | Long | Required | Description |
|---|---|---|---|
-id | --identifiers | no | Optional: comma-separated runtime ids of the rollup archives to check (default: all rollups of the tenant) |
-ff | --failOnFindings | no | Exit with a non-zero code when any rollup is inconsistent or could not be checked in a way that matters, i.e. when the report is not ok (for scripts and the DR runbook; a never-activated rollup does not count) |
-j | --json | no | Output the report as raw JSON |
Notes
Run it after a CrateDB restore. If it reports findings, run RepairRollups (dry run first).
Read only and safe to repeat; the check uses counts and MAX/MIN statements and exports no rows.
A rollup the validator cannot check is listed in its own 'Not checked' section with the reason; it is never reported as consistent. No live table and a missing source are problems (they fail the report and -ff); a rollup that was never activated has no data and is listed as 'Not checked, informational' without failing anything.
The tenant is the tenant of the active context.