431340fc34
Found by violating it. The staged roll landed at 03:50/03:55/03:56 UTC; velero-fleet-daily fires at 03:30 and takes 9-25 min. Restarting tidaldb-0 cancelled its own in-flight volume backup (podvolumebackup ...-wgtkt, pod=tidaldb-0 volume=data) at 2.7 GB of 5.4 GB, and the parent Backup froze at 3529/3907 items. It did not fail - it sat InProgress for 67+ minutes heading for the 240-minute timeout that produces PartiallyFailed, and a stalled Backup blocks the next scheduled run. That is almost certainly the explanation for the PartiallyFailed runs on 2026-08-17/18/19 and 08-25: the namespace holds 4 Canceled and 4 Failed PVBs, all clustered on exactly those dates. The hazard is invisible from both sides - nothing in the deploy path mentions Velero and nothing in the Velero config mentions deploys - so the warning goes at the TOP of the deploy runbook rather than in a section nobody reaches. Note what caught it: the recalibrated 60-minute in-flight bound from the previous commit. The old binary "any InProgress fails" assertion would have been red every day during the normal window, so a real stall would have looked like the usual noise. Resolved by confirming 20260830033034 was Completed at 3707/3707 and all four PVCs Bound, then deleting the stalled Backup. Suite 34/34. |
||
|---|---|---|
| .. | ||
| cluster.md | ||
| deploy-verification.md | ||
| disaster-recovery.md | ||
| kubernetes.md | ||
| nightly-soak.md | ||
| on-call.md | ||
| README.md | ||
tidalDB Runbooks — index
Operational documentation for the cluster deployment (ns tidaldb-cluster,
single StatefulSet, full-placement RF3, quorum-ack + automatic election). Live state
and history live in the orchard9-k3sf repo (cluster-state.yaml,
deployments/history/tidaldb.md).
| When you need to… | Open |
|---|---|
| Verify a deploy end to end — every layer, with the command and its expected output | deploy-verification.md |
| Respond to an incident / page — symptom → signal → fix | on-call.md |
| Operate the cluster — API, failover, partition, membership, scale, rolling upgrade | cluster.md |
| Run it on Kubernetes — deploy, digest-pin, probes, scale up/down, troubleshoot pods | kubernetes.md |
| Back up / restore / DR — object-store export, restore, byte-verify, query-proof, R2, rebuild | disaster-recovery.md |
| Recover a single node / standalone engine — corrupt keyspace, WAL, lock, schema | ../ops/recovery.md |
| Size a deployment — single-node tables + the measured Ref-A cluster envelope | ../ops/capacity-planning.md |
| Soak before a release — 1000 rps load with p99 / error-rate gates (moved out of CI on 2026-08-30; the shared runner cannot meet a 250ms p99) | nightly-soak.md |
| Read the metrics / wire dashboards & alerts | ../ops/observability.md, ../ops/grafana-tidaldb.json, ../ops/prometheus-alerts.yaml |
| Understand the live perf/topology findings (dev handoff) | ../profiling/m12-cluster-deploy-findings.md |
Current production facts (2026-06-19)
- Image:
registry.threesix.ai/tidal/server@sha256:171505745b…(m12-writeburst-rc7). - Shape: 1 StatefulSet
tidaldb, 3 pods = 3 regions = 3 voters, full-placement RF3 (every pod hosts all 3 shard groups; gRPC 9601/9602/9603), HTTPS+mTLS on:9500, metrics:9091. - Guarantees live: quorum-ack writes, automatic election/failover, elastic seed-join (learner→voter), inter-node mTLS, per-node Prometheus.
- Shipped fixes in this image: reseed-loop resolved, seed-join promotion, election-divergence/quarantine, read-SLA (CPU oversubscription), and the write-burst false-partition fix.
- Known limits: read p99 ≤10 ms to ~1000 rps (ceiling ~1–1.5k/s, CPU-bound); write knee ~250 rps; soak at 200 rps; 1M corpus needs >16 GiB nodes; 2.5× write-scaling needs ≥5 nodes + partitioned placement.
- Must-watch signal:
tidaldb_cluster_peer_breaker_state(0/1/2) — a live peer stuck at 1 is the write-burst/partition pattern.
Alert rules in
../ops/prometheus-alerts.yamlare accurate but design-reference — not yet loaded by the live Prometheus. Promoting them to aPrometheusRuleis the one open observability step (seeon-call.md§3).