RunAlexDB Configuration Reference

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

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

Top level

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]`

[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]`

[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.

Replication

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

Concurrency model

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.