Comment 8 for bug 1402338

Revision history for this message
Krunal Bauskar (krunal-bauskar) wrote :

Kasi,

Seems like there was an in-consistency introduced in recent reversion of 5.6.
Patch with updated semantics has been pushed to latest 5.6 which will be part of next 5.6 release.

Let me re-quote the new/updated semantics for clarity here:

      Existing or Updated Semantics:

      a. DDL statement: CREATE/DROP/TRUNCATE/.... for engine=myisam
         Will be replicated ir-respective of wsrep_replicate_myisam settings.
         This is done to ensure that name of the object is blocked so that user
         can't create another object with same name on replicated node (with or
         without different schema structure).
         [No change in innodb semantics]

      b. DML statement: INSERT/UPDATE/DELETE/SELECT .... for engine=myisam
         Will be replicated only if wsrep_replicate_myisam = 1.
         Expect node in-consistency if user try to run part of workload with
         wsrep_replicate_myisam = 0 and rest of the part with
         wsrep_replicate_myisam = 1

      c. SST xfer:
         A newly booted cluster node that get full SST will also get MyISAM table
         (schema + data) ir-respective of wsrep_replicate_myisam setting.

      d. enforce_storage_engine (options specific to PXC)
         If this option is set and sql_mode doesn't conflict with the setting
         (set sql_mode = "") then even if user request creation of MyISAM table it
         will be auto-converted to SE dictated by enforce_storage_engine option.
         Replication status is captured even before enforce storage engine variable
         modifies the table execution path and so for replication original statement
         as issued by user is used. If this option is set for #node-1 and not for
         #node-2 then expect in-consistency in cluster operation as #node-1 would
         end up auto-updating SE for the table to "InnoDB" but #node-2 may continue
         to create the same table with original user specified engine.
         (This limitation should be documented)

      e. CTAS statement: This is executed and handled differently as it involves
         DML + DDL. CTAS semantics are already confusing in upstream.
         PXC ensures that if the CTAS "select" has myisam table only
         (or no table select 1) such queries are not replicated.

         Why is this so ?
         - If there is involvement of innodb table then trx context has to be setup
           and wsrep-plugin is design to work only if trx context is setup.

         Then how come other myisam stmt replicated ?
         - Using TOI and CTAS doesn't use TOI.