Monitor and recover a database
Keep a record of your instance configuration, recovery procedure and working connection details. This guide explains what to check during normal operation and when something fails.
- Identify the affected instanceRecord its state, timing and the reported symptom.
- Narrow the causeSeparate access problems, workload pressure and storage issues.
- Use the matching procedureFollow the supported configuration or recovery steps.
- Verify service after the changeTest reads, permitted writes and the relevant recovery evidence.
Health checks
Use health checks to distinguish a running process from a database ready for the operation you need. A successful liveness check is not proof that writes, replication and backups are healthy.
| Check | What to inspect |
|---|---|
| Process health | Status and error body from the health endpoint. |
| Readiness | The requested read/write readiness and any pressure reason. |
| Storage | Free space, write errors and recovery state. |
| Replication | Standby state and lag where configured. |
Per-tenant usage signal
Use the documented usage endpoint for counts and activity available on your deployment. Missing telemetry is unavailable, not zero. Console sample metrics are not production measurements.
Write durability
Durability describes whether an acknowledged write survives a failure. The guarantee can differ between source rows, explicit vector writes, full-text indexes and other derived structures. Confirm the behavior for the exact engine build and write interface you use.
A successful primary write does not prove that an asynchronous standby has received it. Keep enough source data to rebuild derived indexes, and test recovery before making an application commitment.
Treat a full storage volume or an unclean restart as an incident. Restore capacity, follow the supported recovery procedure and verify subsequent writes before returning the instance to normal use.
Backups
Confirm which snapshots and archives your configuration creates, where they are stored and how long they are retained. Check the latest completed recovery point, not just whether a backup option is selected.
Practice restoring into a separate instance. Verify representative records and indexes, then measure how long the application takes to reconnect. Do not assume a fixed retention window or recovery time from an older plan name.
Continuous backup streaming
An archive can capture changes between base snapshots. Its actual recovery point depends on successfully uploaded and replayable data. A configured interval is not evidence that each interval completed.
Check archive progress and the latest restorable timestamp. If the archive is delayed or stopped, plan recovery from the confirmed snapshot or recovery point and contact support.
Failover
Failover moves service to a replacement primary. Whether it is manual or automatic depends on the configured topology. With asynchronous replication, the replacement may be missing recent writes.
- Confirm the failure and prevent the old primary from continuing to accept writes.
- Inspect the standby’s health and replication position.
- Follow the supported promotion procedure.
- Check read/write readiness before moving traffic.
- Verify records and reconnect clients.
Do not infer a time budget or zero data loss from the presence of a standby. Test the actual procedure with your configuration.
Schema migrations
A schema migration changes a table’s structure. Review its supported operations, backfill behavior and cutover boundary before starting. A backfill processes existing records; cutover makes the new structure active.
Use a test database first. Check progress and errors during the live operation. An abort may be available before cutover, while a completed migration can require a new migration to reverse it. See the schema reference.
Observability
Watch errors, query time, resource pressure, storage and any configured replication or backup progress. Use query plans to investigate expensive work.
EXPLAIN inspects a query plan; EXPLAIN ANALYZE executes the query. See query diagnostics. Use only monitoring endpoints and exporters available on your deployment.
Incident response
Record the instance, time, symptoms, affected operations and request IDs. Preserve logs without credentials or private records. Reduce additional load or writes when needed to protect recovery.
Contact support and follow the agreed service procedure. This guide does not establish response-time or resolution-time commitments; those belong in your service agreement.
Compliance posture
ISO 27001 certification and SOC 2 Type II attestation are in progress. Neither is complete. See the security page for status updates.
A company certification does not configure your application’s access controls or establish compliance for its workload. Review permissions, data handling, retention and contractual requirements for your use case.
Recreate affected older FTS and geo indexes
Older full-text and geospatial indexes may require recreation when crossing the compatibility boundary described in the 19 October release notes. Check the source and target engine versions before planning an upgrade.
- Identify affected indexes and keep a backup or recoverable source dataset.
- Recreate them using the supported procedure.
- Wait for completion and check errors.
- Compare known queries and record counts before switching application traffic.
Recreation is operational work. Reading the release notes or changing a schema file does not rebuild an index.