Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC

Bug #1168291
Comment #8

Comment 8 for bug 1168291

Revision history for this message

Krunal Bauskar (krunal-bauskar) wrote on 2016-02-17:

commit f3e541aa0355c6e074c2be8782fbb6c907997140
Merge: 1e75388 3bf804b
Author: Krunal Bauskar <email address hidden>
Date: Tue Feb 9 10:08:54 2016 +0530

Merge pull request #86 from natsys/5.6-pxc-474

- #PXC-474: Async replication + auto-increment + log-format (STMT) = inconsistent cluster node

commit 3bf804b48eb6860509608c17eb822e9b77f9adec
Author: Julius Goryavsky <email address hidden>
Date: Wed Feb 3 21:28:25 2016 -0500

The causes and fixes:

1. We must ignore wsrep_auto_increment_control when the operator is executed as the result of the replication, including, if it is received from the slave thread. Currently execution from ‘classic’ slave thread treated as local execution and controlled by the automatic increment step adjustment. It is wrong. To correct this error, I changed one conditional operator in the THD::reset_for_next_command() function.

2. If wsrep auto_increment_control switched on during operation of the node, then we should immediately update the auto_increment_increment and auto_increment_offset global variables - without waiting of the next invocation of the wsrep_view_handler_cb() callback. Currently these variables retain its initial values if wsrep_auto_increment_control is switched on during operation of the node, which leads to inconsistent results on the different nodes (in some scenarios).

3. If wsrep auto_increment_control switched off during operation of the node, then we must return the original values of the auto_increment_increment and auto_increment_offset global variables, as the user has set. To make this possible, I created a "shadow copies" of these variables (which stores the latest values set by the user).

commit f3e541aa0355c6e074c2be8782fbb6c907997140
Merge: 1e75388 3bf804b
Author: Krunal Bauskar <krunal.bauskar@percona.com>
Date:   Tue Feb 9 10:08:54 2016 +0530

Merge pull request #86 from natsys/5.6-pxc-474
    
    - #PXC-474: Async replication + auto-increment + log-format (STMT) = inconsistent cluster node

commit 3bf804b48eb6860509608c17eb822e9b77f9adec
Author: Julius Goryavsky <sysprg@gmail.com>
Date:   Wed Feb 3 21:28:25 2016 -0500

This is patch for the PXC-474 issue: suppose we have a PXC 2+ node cluster which is replicating from an async master. Now if the binlog_format is STATEMENT and multi-row inserts are executed on a table with an auto_increment column such that values are automatically generated by MySQL, then the PXC node generates wrong auto_increment values which are different from what was generated on the async master.
    
    The causes and fixes:
    
    1. We must ignore wsrep_auto_increment_control when the operator is executed as the result of the replication, including, if it is received from the slave thread. Currently execution from ‘classic’ slave thread treated as local execution and controlled by the automatic increment step adjustment. It is wrong. To correct this error, I changed one conditional operator in the THD::reset_for_next_command() function.
    
    2. If wsrep auto_increment_control switched on during operation of the node, then we should immediately update the auto_increment_increment and auto_increment_offset global variables - without waiting of the next invocation of the wsrep_view_handler_cb() callback. Currently these variables retain its initial values if wsrep_auto_increment_control is switched on during operation of the node, which leads to inconsistent results on the different nodes (in some scenarios).
    
    3. If wsrep auto_increment_control  switched off during operation of the node, then we must return the original values of the auto_increment_increment and auto_increment_offset global variables, as the user has set. To make this possible, I created a "shadow copies" of these variables (which stores the latest values set by the user).