DB
Operations

Health and readiness

Separate artifact preflight, process liveness, protocol health, and workload readiness.

A production probe answers one question. Do not use a static executable check as proof that a running database can serve traffic.

Probe layers

LayerCheckMeaning
Artifactnyxdb --capabilitiesBuild and runtime capability inventory
Deployment preflightnyxdb --readinessStatic compiled-role capability gate for this executable
ProcessSupervisor/container stateProcess exists and has not exited
ListenerTCP connection to configured host/portSocket accepts a connection
ProtocolWire OP_PINGEvent loop and protocol handler respond
QuerySELECT 1Admission, bind, execute, and result path respond
WorkloadRepresentative read and optional canary write/readRequired catalog, storage, and policy are usable

--readiness exits after evaluating compiled service-capability metadata. It does not parse or validate startup flags, files, storage, the environment, or a recently started server.

Startup gate

Keep traffic closed while:

  1. the process creates/opens the data directory;
  2. catalog and WAL recovery run;
  3. checkpoints and parts are validated;
  4. the listener reaches ready state;
  5. OP_PING succeeds; and
  6. a representative query returns the expected schema/result.

Start the readiness grace period from process launch and size it from measured recovery time on production-scale data.

Liveness policy

Use protocol ping as the normal live check. It is intentionally lighter than a query and remains independent of query admission. Require several consecutive failures before restart so a transient scheduler or I/O stall does not create a restart loop.

An automatic restart is appropriate only when:

  • the process has exited;
  • protocol ping is persistently unavailable; or
  • a documented fatal condition cannot recover in place.

High query latency, a full admission queue, or governor BLOCK is an incident to diagnose; a blind restart may discard evidence and add recovery load.

Readiness policy

Remove the process from service when the workload contract is not met even if it is live. Examples include:

  • recovery has not completed;
  • query admission is persistently saturated;
  • the memory governor remains at BLOCK;
  • required storage is unavailable;
  • a required transform is terminal; or
  • the live probe passes but representative queries fail.

Because the current deployment is single-node, marking the only process unready means planned unavailability. There is no automatic peer to receive traffic.

Shutdown gate

On SIGTERM:

  1. stop opening new application work;
  2. let in-flight operations reach their documented boundary;
  3. wait for the process to exit cleanly;
  4. verify the supervisor did not escalate to SIGKILL; and
  5. preserve shutdown logs with the deployment record.

After restart, run the full startup gate again. A successful TCP connect alone does not prove storage recovery or query readiness.

On this page