Migrations 028–034 (the plan's 026–032; 026 and 027 are taken by the SSH
host key and the fanout switch), each with a down file, mirrored in
database.sql:
- 028: the 19 cluster settings with the plan's defaults. They stay inert
until cluster_api_enabled and cluster:init.
- 029: cluster_nodes (mode, flow bits, gen, node keys, state, sequence
high-waters, row MAC), cluster_node_epochs (the extension's sealed epoch
records; deleting a row erases z) and cluster_meta.
- 030: cluster_commands, FIFO per node with UNIQUE(server_id, seq),
UNIQUE(server_id, dedupe_key) and UNIQUE(cmd_id).
- 031: cluster_enrol_codes (sealed K_req/K_res under a row MAC, looked up
by SHA-256 of the secret) and cluster_enrol_requests (UNIQUE(server_id):
no bulk approve).
- 032: cluster_audit, cluster_nonces (replay cache) and
cluster_reservations (MySQL-mode admission).
- 033: crontab.role (all/main/legacy). The four crons Phase 0 gated to
MAIN become 'main', and a disabled 'cluster' row is added for
cron:cluster (Phase 2).
- 034: cluster_changes (blocklist delta log) and cluster_stream_ver (R2
versions).
Checked on MariaDB 10.11:
- a fresh database.sql and the previous database.sql plus these
migrations produce identical columns, indexes, cron rows and defaults;
- the migrations are idempotent;
- the down files remove everything and up re-applies.
ClusterSchemaTest keeps the two copies in step in CI.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Es8UhyPS8MNjuYTagqfGWi
Claude