8.0
xtrabackup 8.0 是 根据系统数据中的 performance_schema 中的 log_status 表 获取 GTID 和 binary_log_file binary_log_position 信息，如果是 myisam 表，因为不支持事务，所以不存在 redo 信息。还是需要 FTWL 机制来维护。防止备份前后出现不一致的情况。
相关源码
检查是否有myisam表
char *count_str =
read_mysql_one_value(mysql_connection,
"SELECT COUNT(*) FROM information_schema.tables "
"WHERE engine = 'MyISAM' OR engine = 'RocksDB'");
不安全的
have_unsafe_ddl_tables = (count > 0);
这需要进行FTWRL
lock_tables_maybe:
if (!have_unsafe_ddl_tables && !force_ftwrl) { //have_unsafe_ddl_tables 是否包含了myisam表，如果有则have_unsafe_ddl_tables设置为true
return (true); //直接return
}
...
return lock_tables_ftwrl(connection); //FTWRL
5.7
5.7 是没有 log_status 的这个信息的，因此在最后获取 redo点/GTID 信息 /binlog postition位置 的一致性就需要加 FTWRL 进行保证，其中 GTID信息/binlog postition位置是在backup_start 备份完 myisam 表后通过 write_current_binlog_file 发起"SHOW MASTER STATUS" 语句获取的，而redo信息是在随后获取的，其中ckpt 信息则是通过多去redo文件里面的ckpt信息，最后备份的redo lsn信息就是最后扫描的 redo LSN信息，正常这些信息应该在 FTWRL 保护下下获取的。但是如果 加-no-lock选项 就不可以了，因为没有FTWRL的保护这些信息不能达到一致的点。
总结
8.0 是 根据 系统表 perfoemance_schema 表中的 log_status 这张表 来整理 备份位置点 和 二进制文件的相关信息的，如果遇到 mysisam 不支持事务的引擎，需要通过 FTWRL 来保证备份后数据一致性。
5.7 不存在 log_status 这个表，不管怎么样都需要FTWRL来获取redo和binlog的一致点，并且很多内部视图也是myisam的表。所以备份全程需要 FTWRL 维护
