Concept and mechanism
mysqldump --single-transaction provides a consistency scope for InnoDB tables rather than a universal guarantee for every engine. MyISAM and MEMORY can change during the dump; concurrent DDL can also invalidate results. Confirm engines, the schema-change window, and required artifacts before trusting the copy. PITR combines an appropriate backup with subsequent binlogs and validated start and stop points. Retention must cover the required interval rather than only the latest file. Test restoration into an isolated target, including accounts, routines, and configuration, and measure when the application becomes usable.
Guided application
Asynchronous replication permits delay between source commit and replica application. An immediate read needs an explicit contract: a suitable destination or a controlled wait for the required GTID. WAIT_FOR_EXECUTED_GTID_SET returns zero on success and one on timeout; do not confuse that result with a success boolean. After waiting, the read also needs a suitable snapshot, avoiding an old transaction that cannot see the commit. In a fictional error already replicated, promoting the current replica does not recover the past. Returning to an earlier point can exclude valid later movements. Preserve evidence and plan reconciliation before reopening writes.
WAIT_FOR_EXECUTED_GTID_SET = 1: the deadline expired; visibility of the required write is not guaranteed.
Common pitfalls
Connected receiver as current replica; 1 as success; replica as historical backup; PITR as an incorrect-change filter.
Related topics: Types and data contracts · Deterministic queries and plans · InnoDB transactions and error paths
Recovery and consistent reading need observable conditions rather than merely running services.
Reference: Backup and binary-log recovery · MySQL 9.7 LTS with InnoDB reference semantics