Monitoring Row-based Replication When GTID-based replication is in use, from MySQL 8.0.18 a multithreaded replica checks first whether MASTER_AUTO_POSITION  is set to  ON , and if it is, omits the step of calculating the transactions that should be skipped or not skipped, so that the old relay logs are not required for the recovery process. The current progress of the replication applier (SQL) thread when using row-based replication is monitored through Performance Schema instrument stages, enabling you to track the processing of operations and check the amount of work completed and work estimated. When these Performance Schema instrument stages are enabled the  events_stages_current  table shows stages for applier threads and their progress. For background information, see Section 27.12.5, “Performance Schema Stage Event Tables” . To track progress of all three row-based replication event types (write, update, delete): It does not matter for the replication process whether the original table on the source and the replicated table on the replica use different storage engine types. In fact, the  default_storage_engine  system variable is not replicated. This provides a number of benefits in the replication process in that you can take advantage of different engine types for different replication scenarios. For example, in a typical scale-out scenario (see Section 17.4.5, “Using Replication for Scale-Out” ), you want to use  InnoDB  tables on the source to take advantage of the transactional functionality, but use  MyISAM  on the replicas where transaction support is not required because the data is only read. When using replication in a data-logging environment you may want to use the  Archive  storage engine on the replica. Configuring different engines on the source and replica depends on how you set up the initial replication process: Another alternative for  mysqldump  is to disable engine types that you do not want to use on the replica before using the dump to build the data on the replica. For example, you can add the  --skip- federated  option on your replica to disable the  FEDERATED  engine. If a specific engine does not exist for a table to be created, MySQL uses the default engine type, usually  InnoDB . (This requires that the NO_ENGINE_SUBSTITUTION  SQL mode is not enabled.) If you want to disable additional engines in this •Enable the three Performance Schema stages by issuing: •Wait for some events to be processed by the replication applier thread and then check progress by looking into the  events_stages_current  table. For example to get progress for  update  events issue: •If  binlog_rows_query_log_events  is enabled, information about queries is stored in the binary log and is exposed in the  processlist_info  field. To see the original query that triggered this event: mysql>  UPDATE performance_schema.setup_instruments SET ENABLED = ’YES’ ->  WHERE NAME LIKE ’stage/sql/Applying batch of row changes%’; mysql>  SELECT WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_current ->  WHERE EVENT_NAME LIKE ’stage/sql/Applying batch of row changes (update)’ mysql>  SELECT db, processlist_state, processlist_info FROM performance_schema.threads ->  WHERE processlist_state LIKE ’stage/sql/Applying batch of row changes%’ AND thread_id = N; •If you used  mysqldump  to create the database snapshot on your source, you could edit the dump file text to change the engine type used on each table. 3635 17.4.4 Using Replication with Different Source and Replica Storage Engines 17.4.3 Monitoring Row-based Replication