Cross Engine Synchronization for Clone

Even though the clone plugin supports cloning across multiple storage engines, the existing clone implementation only considers InnoDB and binary log for clone consistency, with the synchronization implementation being fully internal to InnoDB, with no way for other engines to join. Thus, implementing the clone support for an additional transactional storage engine results in all engines being cloned, but potentially inconsistently with respect to InnoDB and binlog.

MySQL 8.0 has a way to synchronize InnoDB, binlog, and arbitrary participating SE log positions: performance_schema.log_status table, which is used by XtraBackup for this purpose. It makes all SEs to block their log writes, and once all SEs have done so, save their log positions.

We add a new method to the donor-side handlerton clone interface:

• using Clone_set_log_stop_t = void (*)(const uchar *loc, uint loc_len, const Json_dom &log_stop_pos): it takes the part of log_status query pertaining to the current storage engine and orders the clone session at the provided locator to stop at exact log position. This method will be called from inside the clone_copy handlerton method, the implementation of both must be compatible with this.

The call site of set_log_stop cannot be placed arbitrarily. If called too soon, then InnoDB clone might contain flushed pages with modification LSNs past the target clone stop LSN. That forces keeping InnoDB as a special engine for clone cross-engine synchronization, but only for deciding its invocation point.

To avoid InnoDB clone having flushed pages with LSNs larger than the clone LSN, the earliest possible point for the set_log_stop call is at the state change from page (or SST) to log copy. This is the same place the old implementation performs binlog synchronization, which is completely removed in the new implementation.

The clone callback structures gets a new callback: set_log_stop, which is called by InnoDB stage transition. This callback, in the clone plugin core, performs the performance_schema.LOG_STATUS query, parses its results and calls handlerton set_log_stop method for every storage engine. For its implementation, InnoDB is patched to stop clone redo log archiving at that LSN, and MyRocks adds the given WALs with their sizes to the clone file set, and advances the MyRocks clone state from Final Checkpoint to Final Checkpoint with Logs. Then the plugin callback returns to the InnoDB clone copy state change, which then proceeds.

Note that the above ignores the Clone SST Copy patch for the rolling checkpoint for simplicity. Their combination is presented in Clone SST copy and Synchronization Together.