Skip to content
  • Nuno Carvalho's avatar
    f9f98f74
    BUG#26985561: BACKPORT BUG#26277771 TO 5.7 - BUG#27016053: REGRESSION IN... · f9f98f74
    Nuno Carvalho authored
    BUG#26985561: BACKPORT BUG#26277771 TO 5.7 - BUG#27016053: REGRESSION IN BINLOG_LOG_ROW INTRODUCED BY ADD_PKE
    
    This is backport of
    Bug#26277771: BAD WRITE SET TRACKING WITH UNIQUE KEY ON A
    DELETE FOLLOWED BY AN INSERT, which includes the optimizations
    present on BUG#27016053: REGRESSION IN BINLOG_LOG_ROW INTRODUCED BY
    ADD_PKE.
    
    Issue:
    ======
    The Writesets generated for keys were not using collation into consideration,
    and because of that wrong last_committed and sequence_number were
    getting added to binary log and thus transactions were getting applied
    in wrong order by parallel applier on slave.
    
    Solution:
    =========
    The fix uses make_sort_key to transform keys, with different charset and
    collation, into its binary image, suitable for sorting using binary
    comparison.
    
    Optimizations:
    ==============
    During detailed performance analysis it was discovered that there
    were non-optimized memory allocations and memory copy operations on
    the write-set extraction.
    
    In order to solve the performance regression, the following actions
    were made:
     1) optimize memory allocation;
     2) reduce memory copy operations;
     3) only collect foreign key write-sets when them are not disabled;
     4) do not collect and send duplicate write-sets through the network.
    f9f98f74
    BUG#26985561: BACKPORT BUG#26277771 TO 5.7 - BUG#27016053: REGRESSION IN...
    Nuno Carvalho authored
    BUG#26985561: BACKPORT BUG#26277771 TO 5.7 - BUG#27016053: REGRESSION IN BINLOG_LOG_ROW INTRODUCED BY ADD_PKE
    
    This is backport of
    Bug#26277771: BAD WRITE SET TRACKING WITH UNIQUE KEY ON A
    DELETE FOLLOWED BY AN INSERT, which includes the optimizations
    present on BUG#27016053: REGRESSION IN BINLOG_LOG_ROW INTRODUCED BY
    ADD_PKE.
    
    Issue:
    ======
    The Writesets generated for keys were not using collation into consideration,
    and because of that wrong last_committed and sequence_number were
    getting added to binary log and thus transactions were getting applied
    in wrong order by parallel applier on slave.
    
    Solution:
    =========
    The fix uses make_sort_key to transform keys, with different charset and
    collation, into its binary image, suitable for sorting using binary
    comparison.
    
    Optimizations:
    ==============
    During detailed performance analysis it was discovered that there
    were non-optimized memory allocations and memory copy operations on
    the write-set extraction.
    
    In order to solve the performance regression, the following actions
    were made:
     1) optimize memory allocation;
     2) reduce memory copy operations;
     3) only collect foreign key write-sets when them are not disabled;
     4) do not collect and send duplicate write-sets through the network.
Loading