Replication Features and Issues statements that act directly on partitions cannot be run on the source without causing errors there. To avoid stopping replication or creating inconsistencies between the source and replica, always ensure that a table on the source and the corresponding replicated table on the replica are partitioned in the same way. When used on a corrupted or otherwise damaged table, it is possible for the  REPAIR TABLE  statement to delete rows that cannot be recovered. However, any such modifications of table data performed by this statement are not replicated, which can cause source and replica to lose synchronization. For this reason, in the event that a table on the source becomes damaged and you use  REPAIR TABLE  to repair it, you should first stop replication (if it is still running) before using  REPAIR TABLE , then afterward compare the source’s and replica’s copies of the table and be prepared to correct any discrepancies manually, before restarting replication. You can encounter problems when you attempt to replicate from an older source to a newer replica and you make use of identifiers on the source that are reserved words in the newer MySQL version running on the replica. For example, a table column named  rank  on a MySQL 5.7 source that is replicating to a MySQL 8.0 replica could cause a problem because  RANK  is a reserved word beginning in MySQL 8.0. Replication can fail in such cases with Error 1064  You have an error in your SQL syntax... , even if a database or table named using the reserved word or a table having a column named using the reserved word is excluded from replication . This is due to the fact that each SQL event must be parsed by the replica prior to execution, so that the replica knows which database object or objects would be affected. Only after the event is parsed can the replica apply any filtering rules defined by  --replicate-do-db , --replicate-do-table ,  --replicate-ignore-db , and  --replicate-ignore-table . To work around the problem of database, table, or column names on the source which would be regarded as reserved words by the replica, do one of the following: For listings of reserved words by MySQL version, see Keywords and Reserved Words in MySQL 8.0, in the MySQL Server Version Reference . For identifier quoting rules, see Section 9.2, “Schema Object Names” . When a replica using row-based replication format applies an  UPDATE  or  DELETE  operation, it must search the relevant table for the matching rows. The algorithm used to carry out this process uses one of the table’s indexes to carry out the search as the first choice, and a hash table if there are no suitable indexes. The algorithm first assesses the available indexes in the table definition to see if there is any suitable index to use, and if there are multiple possibilities, which index is the best fit for the operation. The algorithm ignores the following types of index: 3670 •Multi-valued indexes. •Generated indexes. •Hidden indexes. •Fulltext indexes. •In any SQL statements using these database object names, write the names as quoted identifiers using backtick characters ( ‘ ). •Use one or more  ALTER TABLE  statements on the source to change the names of any database objects where these names would be considered reserved words on the replica, and change any SQL statements that use the old names to use the new names instead. 17.5.1.27 Replication and Row Searches 17.5.1.26 Replication and Reserved Words 17.5.1.25 Replication and REPAIR TABLE