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

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

    XMLWordPrintable

    Details

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

      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.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

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