If SELECT LAST_INSERT_ID() is present in the statements to be replayed it means that the result of that statement already has been sent to the client. If the replay fails due to a checksum mismatch when that statement is executed, it means that the last insert id is different the second time around, perhaps because somebody else has modified the table in the meantime.

If the mismatch is ignored, the application will believe that the last insert id is different from what it actually is. Is that something the application can deal with?

Adding a transaction_replay_checksum parameter with the values full, result_only and no_insert_id allows for the following behavior:

• transaction_replay_checksum=full is how it works currently: the checksum is calculated from all responses and the replayed transaction is known to be consistent with what the client has seen.
• transaction_replay_checksum=result_only excludes OK packets (responses that aren't resultsets or errors) from the checksum. This effectively ignores the auto-generated insert ID for cases where the application doesn't explicitly request it via SQL. Currently this also ignores the OK packets generated by UPDATE statements which can cause the number of affected rows to change (might need to be adjusted if this is a problem). This still detects if a statement fails to execute as error packets are included in the checksum and they cause it to diverge if one of the statements fail that previously worked.
• transaction_replay_checksum=no_insert_id ignores both OK packets and results from queries that use the LAST_INSERT_ID() function (or any of its aliases). This is only safe for very specific use-cases where the function is unconditionally used or when the fact that the real inserted ID is not the one the client has is not a problem. The same limitations that apply to result_only also apply to this mode.