Référence de configuration RunAlexDB

RunAlexDB lit un unique fichier de configuration TOML. mysql_port, webui_port, bind et data_dir sont des clés de premier niveau — il n’existe pas de section [server].

Premier niveau

mysql_port = 3306                    # protocole fil MySQL
webui_port = 8306                    # console d'administration : SQL, plans de requête, métriques
bind       = "0.0.0.0"
data_dir   = "/var/lib/runalexdb"    # dossier de base pour logs, metrics_key, certificats webui…

[auth]

[auth]
root_password = "change-me"  # requis — refuse de démarrer sur cette valeur par défaut
webui_api_key = ""           # 2e facteur optionnel pour /api/* ; vide = désactivé

Aucun mot de passe par défaut n’est fourni pour root_password — le serveur refuse de démarrer tant qu’il n’a pas été changé. La console d’administration se connecte avec les mêmes utilisateurs MySQL que le protocole fil (root inclus) ; il n’existe pas de compte séparé propre à la webui. webui_api_key est une défense en profondeur optionnelle : une fois configurée, chaque appel /api/* doit aussi porter un en-tête X-Api-Key correspondant, en plus du cookie de session.

[persistence]

[persistence]
enabled       = true
dir           = "/var/lib/runalexdb/wal"
durability    = "durable"   # ou "relaxed"
parity_shards = 2           # correction automatique Reed-Solomon (0 = détection seule)
mem_limit_pct = 75          # seuil anti-OOM de checkpoint/éviction

• enabled — à désactiver uniquement pour des instances jetables/de benchmark ; sans elle, les données ne vivent qu’en mémoire et ne survivent pas à un redémarrage.
• dir — où sont stockés le write-ahead log et les snapshots (distinct du data_dir de premier niveau, qui contient logs/certificats/clés).

La durabilité repose sur un WAL avec parité par code correcteur (Reed-Solomon) et des commits garantis par fsync — l’objectif de RunAlexDB est un RPO=0 pour tout ce qui a acquitté un commit. La restauration point-in-time relit le WAL depuis un checkpoint.

Réplication

La réplication de RunAlexDB est basée sur Raft : élection de leader, fencing par bail (lease) — pour qu’un ancien leader partitionné ne puisse pas continuer à accepter des écritures — et réplication semi-synchrone avec finalisation en commit à deux phases côté follower.

[replication]
role        = "replica"          # standalone (défaut) | master | replica
master_addr = "10.0.0.1:3390"    # replica : host:port du flux de réplication du master

Modèle de concurrence

L’isolation est une isolation par snapshot avec un MVCC à granularité ligne — la détection de conflit suit les versions par ligne, pas par table, donc deux transactions touchant des lignes disjointes n’entrent jamais en contention. Une transaction qui perd une course en écriture sur la même ligne reçoit l’erreur de conflit standard first-committer-wins, pas une ligne écrasée en silence.