TokuDB 'fast' replace into is incompatible with 8.0 row replication

Description

'fast' replace into allows a replace into to become what TokuDB calls an UPSERT a.k.a a blind insert that becomes an update deep in the FT library if a key already exists. The purpose of this is to eliminate the need for a read to see if there is a duplicate key collision. This causes problems with replication in 8.0. When this 'feature' is in play, the handler::write_rows will perform the replace and return SUCCESS instead of performing the replace and returning HA_ERR_FOUND_DUPP_KEY (which is what the server layer is expecting).  When SUCCESS happens on the master, a ROW INSERT event is created, but when the master gets HA_ERR_FOUND_DUPP_KEY, it creates a ROW UPDATE event instead.  When a slave handles the ROW INSERT, it is not an INSERT IGNORE or a REPLACE INTO, just an INSERT, so the 'fast' feature is skipped and the FT layer returns DB_KEYEXIST, which then is translated into a HA_ERR_FOUND_DUPP_KEY and returned from handler::write_rows, which then causes replication to halt on the duplicate key error.

 

Since this 'feature' is already incompatible with statement replication on a master, and now it is incompatible with row replication on a master, I believe it is best to just remove it entirely from 8.0.  It can be argued that it is an unsafe feature at any cost and this just allows us to avoid it entirely going forward and clean up the code and logic somewhat.

Environment

None

Smart Checklist

Activity

Show:
Done

Details

Assignee

Reporter

Labels

Time tracking

5h 45m logged

Components

Fix versions

Affects versions

Priority

Smart Checklist

Created September 4, 2018 at 9:14 PM
Updated March 6, 2024 at 12:52 PM
Resolved September 6, 2018 at 7:48 PM