Skip to content

RunAlexDB Configuration Reference

RunAlexDB reads a single TOML configuration file. mysql_port, webui_port, bind, and data_dir are top-level keys — there is no [server] section.

mysql_port = 3306 # MySQL wire protocol
webui_port = 8306 # admin console: SQL runner, query plans, live metrics
bind = "0.0.0.0"
data_dir = "/var/lib/runalexdb" # base directory for logs, metrics_key, webui certs, etc.
[auth]
root_password = "change-me" # required — refuses to start at this placeholder
webui_api_key = "" # optional second factor for /api/*; empty = off

There is no default password shipped for root_password — the server refuses to start until it’s changed. The admin console logs in with the same MySQL users as the wire protocol (root included); there is no separate webui-only account. webui_api_key is opt-in defense-in-depth: when set, every /api/* call must also carry a matching X-Api-Key header alongside the session cookie.

[persistence]
enabled = true
dir = "/var/lib/runalexdb/wal"
durability = "durable" # or "relaxed"
parity_shards = 2 # Reed-Solomon auto-correction (0 = detect only)
mem_limit_pct = 75 # anti-OOM checkpoint/eviction threshold
  • enabled — turn off only for throwaway/benchmark instances; without it, data lives in memory only and does not survive a restart.
  • dir — where the write-ahead log and snapshots are stored (distinct from the top-level data_dir, which holds logs/certs/keys).

Durability is WAL-based with erasure-coded (Reed-Solomon) parity and fsync-backed commits — RunAlexDB’s target is RPO=0 for anything that acknowledged a commit. Point-in-time recovery reads back through the WAL from a checkpoint.

RunAlexDB’s replication is Raft-based: leader election, lease-based fencing (so a partitioned former leader can’t keep accepting writes), and semisynchronous replication with two-phase-commit finalization on the follower side.

[replication]
role = "replica" # standalone (default) | master | replica
master_addr = "10.0.0.1:3390" # replica: host:port of the master's replication stream

Isolation is snapshot isolation with row-grain multi-version concurrency control — conflict detection tracks versions per row, not per table, so two transactions touching disjoint rows never contend with each other. A transaction that loses a write-write race on the same row gets the standard first-committer-wins conflict error, not a silently overwritten row.