Uploaded image for project: 'Percona Server for MySQL'
  1. Percona Server for MySQL
  2. PS-4814

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


    • Type: Bug
    • Status: Done
    • Priority: High
    • Resolution: Fixed
    • Affects Version/s: 8.0.x
    • Fix Version/s: 8.0.12-2rc1
    • Component/s: TokuDB
    • Labels:


      '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.

        Smart Checklist




              • Assignee:
                george.lorch George Lorch
                george.lorch George Lorch
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created:

                  Time Tracking

                  Original Estimate - Not Specified
                  Not Specified
                  Remaining Estimate - 0 minutes
                  Time Spent - 5 hours, 45 minutes
                  5h 45m