Navigation: README | Architecture | Related: Testing, Configuration, API
This document lists practical debugging paths for common TeoDB failures.
Check:
- Config path and syntax.
TEODB__*environment overrides.- Iceberg REST catalog reachability.
- Object-store endpoint and credentials.
- Writable data, cache, and spill directories.
- WAL lease ownership.
- Production security validation.
Useful commands:
curl -fsS http://localhost:8181/v1/config | jq .
curl -fsS http://localhost:19000/healthCall:
curl -fsS http://localhost:8080/ready | jq .Readiness can fail because the process is draining, catalog checks fail, scheduler is unreachable, executor quorum is not met, or local directories are not writable.
This is usually expected: query visibility begins after flush.
curl -fsS -X POST http://localhost:8080/api/v1/tables/default/events/flushThen query again.
Look for:
- WAL corruption messages.
- Recovery mode.
- Missing table tombstone handling.
- Catalog committed generation metadata.
- WAL directory lease conflicts.
Do not delete WAL files to “fix” replay unless you intentionally accept loss of unflushed rows.
Check:
- SQL validity.
- Catalog table resolution.
- Unsupported equality deletes.
- Object-store read errors.
- Spill directory capacity.
- Query timeout.
- Ballista scheduler/executor reachability in distributed mode.
Use POST /api/v1/query/explain to inspect plans.
Check:
cluster.scheduler_addrfrom data nodes.- Control-plane scheduler bind address.
- Data-node
--executor-advertise-host. - Internal ports between pods/containers.
- Executor quorum in
/ready. - HAProxy or service routing.
Use /metrics for counters and histograms. If security.admin_token is set, include the bearer token.
Set log level through config, environment, or CLI:
teodb --config deploy/docker/config/standalone.toml --log-level debug