Done
Details
Assignee
George LorchGeorge Lorch(Deactivated)Reporter
George LorchGeorge Lorch(Deactivated)Labels
Time tracking
5h 45m loggedComponents
Fix versions
Affects versions
Priority
High
Details
Details
Assignee
George Lorch
George Lorch(Deactivated)Reporter
George Lorch
George Lorch(Deactivated)Labels
Time tracking
5h 45m logged
Components
Fix versions
Affects versions
Priority
Smart Checklist
Smart Checklist
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
'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.