Metadata availability

Catalog definitions and access permissions must remain available for queries and administration. A clustered deployment coordinates this information across replicas. This is separate from the durability of ingested rows.

Availability

In the documented three-replica topology, two healthy replicas are needed for metadata-dependent operations. Losing one replica can interrupt its client connections; clients must reconnect to a healthy endpoint. Without a majority, affected operations fail or pause instead of proceeding with unverified catalog or access information.

Do not treat a successful metadata operation as proof that every recent streaming row is stored durably. See Reliability and completion.

Recovery

A replacement node can recover metadata from healthy replicas. Complete loss of local cluster state requires the configured object-storage backups, original encryption material and correct cluster identity. The recovery point is the latest completed backup.

Unpublished recent rows may not be recoverable. Historical cache files can be rebuilt from their existing objects; they have a different recovery role.

Follow the cluster recovery procedure before restoring an entire deployment. Do not initialize an empty cluster as a substitute for a failed restore.

Monitoring

boilstream-admin cp-metadata status

Investigate unhealthy status, prolonged absence of a leader or a result indicating that safe current reads are unavailable. Check replica health, connectivity and recovery storage before reopening traffic.

Use the Kubernetes deployment for topology and key management. Confirm recovery behavior with the server release and configuration you intend to operate.