rubydb 0.1.4 → 0.1.6

data/docs/operations/failover.md

@@ -1,30 +1,30 @@
-# Failover procedure
-
-Automatic election is intentionally disabled until fencing and partition
-testing are complete. Failover is an operator-controlled procedure.
-
-## Promote a replica safely
-
-1. Confirm the primary is stopped or fenced and cannot accept writes.
-2. Confirm the candidate replica is `SYNCED`, or is `DISCONNECTED` only after
-   it was previously synchronized, and that received and replayed WAL
-   positions are equal.
-3. Compare the candidate replay position with the incident recovery point.
-4. Promote only after the candidate passes the configured fencing checks.
-5. Point clients at the promoted node and run read/write smoke queries.
-6. Keep the old primary isolated until its data and fencing epoch are reviewed.
-
-Promotion must fail closed when a replica is lagging, has never replayed a
-durable position, or is missing a required recovery point. A disconnected but
-caught-up replica is eligible only for explicit operator promotion after the
-old primary is stopped or fenced. Never force promotion to hide a WAL gap.
-
-## Rejoin the old primary
-
-Treat the old primary as a stale writer. Preserve its files, compare WAL and
-catalog state, and rebuild or re-bootstrap it as a replica if divergence cannot
-be proven absent. Re-enable it for writes only after a new fencing lease and a
-clean recovery validation.
-
-Record the old and new fencing epochs, replica LSNs, promotion time, observed
-lag, and application error rate in the incident record.
+# Failover procedure
+
+Automatic election is intentionally disabled until fencing and partition
+testing are complete. Failover is an operator-controlled procedure.
+
+## Promote a replica safely
+
+1. Confirm the primary is stopped or fenced and cannot accept writes.
+2. Confirm the candidate replica is `SYNCED`, or is `DISCONNECTED` only after
+   it was previously synchronized, and that received and replayed WAL
+   positions are equal.
+3. Compare the candidate replay position with the incident recovery point.
+4. Promote only after the candidate passes the configured fencing checks.
+5. Point clients at the promoted node and run read/write smoke queries.
+6. Keep the old primary isolated until its data and fencing epoch are reviewed.
+
+Promotion must fail closed when a replica is lagging, has never replayed a
+durable position, or is missing a required recovery point. A disconnected but
+caught-up replica is eligible only for explicit operator promotion after the
+old primary is stopped or fenced. Never force promotion to hide a WAL gap.
+
+## Rejoin the old primary
+
+Treat the old primary as a stale writer. Preserve its files, compare WAL and
+catalog state, and rebuild or re-bootstrap it as a replica if divergence cannot
+be proven absent. Re-enable it for writes only after a new fencing lease and a
+clean recovery validation.
+
+Record the old and new fencing epochs, replica LSNs, promotion time, observed
+lag, and application error rate in the incident record.

data/docs/operations/monitoring.md

@@ -1,25 +1,25 @@
-# Monitoring and alerting
-
-Expose the RubyDB health and Prometheus endpoints through the deployment’s
-authenticated monitoring path. Use liveness to decide whether a process
-exists; use readiness to decide whether it is safe to route traffic.
-
-At minimum, collect:
-
-- request count, error count, latency, and active connections;
-- WAL bytes/segments, checkpoint failures, flush failures, and recovery-required
-  commit acknowledgements;
-- table/index counts, row counts, storage bytes, and vacuum/compaction duration;
-- replication role, state, received/replayed LSN, lag, authentication failures,
-  and fencing epoch;
-- process memory, CPU, open files, and filesystem free space.
-
-Alert on readiness failure, repeated request errors, checkpoint or WAL flush
-failures, any recovery-required acknowledgement, filesystem space below the
-service threshold, replication lag beyond the application RPO, authentication
-failures, and a fencing epoch change.
-
-Dashboards must show rates and percentiles over time, not only current gauges.
-Set thresholds from staging workload measurements and review them after every
-capacity or schema change. A green liveness check alone is not evidence that
-the database can accept traffic.
+# Monitoring and alerting
+
+Expose the RubyDB health and Prometheus endpoints through the deployment’s
+authenticated monitoring path. Use liveness to decide whether a process
+exists; use readiness to decide whether it is safe to route traffic.
+
+At minimum, collect:
+
+- request count, error count, latency, and active connections;
+- WAL bytes/segments, checkpoint failures, flush failures, and recovery-required
+  commit acknowledgements;
+- table/index counts, row counts, storage bytes, and vacuum/compaction duration;
+- replication role, state, received/replayed LSN, lag, authentication failures,
+  and fencing epoch;
+- process memory, CPU, open files, and filesystem free space.
+
+Alert on readiness failure, repeated request errors, checkpoint or WAL flush
+failures, any recovery-required acknowledgement, filesystem space below the
+service threshold, replication lag beyond the application RPO, authentication
+failures, and a fencing epoch change.
+
+Dashboards must show rates and percentiles over time, not only current gauges.
+Set thresholds from staging workload measurements and review them after every
+capacity or schema change. A green liveness check alone is not evidence that
+the database can accept traffic.