old primary is writable for about 31 s after a crash and boot (errant GTID risk) #104

New issue

Closed

opened 2026-10-08 21:03:49 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-10-08 21:03:49 -03:00

(Migrated from github.com)

Found in the real-node test of the MariaDB pair, keel 0.23.3 (finding B2).

ID	Severity	Problem	Output
B2	High	After a crash and boot, the old primary sets `read_only OFF` from its stale local claim, before `keel vip check` learns the newer epoch. It stays writable for about 31 s while the other node holds the VIP. A write to its own address in that window makes an errant GTID. Contradicts "read only at its first second" (docs/replication.md, measured case a).	`23:57:36 keel[691]: database.server.role: set read_only OFF: this role takes the application's writes` ... `23:58:07 set read_only ON`; probe `read_only=0` from 23:57:36.347 to 23:58:07.753

Evidence: Keel-Linux/handbook#60, docs/evidence/2026-10-08-mariadb-pair-real.md.

Found in the real-node test of the MariaDB pair, keel 0.23.3 (finding B2). | ID | Severity | Problem | Output | |---|---|---|---| | B2 | High | After a crash and boot, the old primary sets `read_only OFF` from its stale local claim, before `keel vip check` learns the newer epoch. It stays writable for about 31 s while the other node holds the VIP. A write to its own address in that window makes an errant GTID. Contradicts "read only at its first second" (docs/replication.md, measured case a). | `23:57:36 keel[691]: database.server.role: set read_only OFF: this role takes the application's writes` ... `23:58:07 set read_only ON`; probe `read_only=0` from 23:57:36.347 to 23:58:07.753 | Evidence: Keel-Linux/handbook#60, docs/evidence/2026-10-08-mariadb-pair-real.md.