about replica

[Joren De Vries]

A rebuilt replica can show healthy I/O and SQL threads, zero reported lag, and the expected GTID position while still being unsafe to promote. The seed may have omitted objects, replication filters may differ, checksums may not match, or application traffic may depend on users, events, routines, and configuration that were not part of the data copy.

What is your promotion gate after cloning or restoring a replica? I am considering checking GTID continuity and errant transactions, replication filters, row counts and chunked checksums for critical tables, schema objects, users and grants, scheduled events, time zones and SQL modes, plus representative read-only application queries. The replica would remain fenced from writes until these checks pass.

Which checks provide useful confidence without putting too much load on the primary? How do you validate a very large dataset, and what evidence do you retain so a later failover can show exactly which replica state was approved?

...