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.
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 _myisam settings.
Will be replicated ir-respective of wsrep_replicate
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 _myisam = 1.
wsrep_ replicate_ myisam = 0 and rest of the part with
wsrep_ replicate_ myisam = 1
Will be replicated only if wsrep_replicate
Expect node in-consistency if user try to run part of workload with
c. SST xfer: _myisam setting.
A newly booted cluster node that get full SST will also get MyISAM table
(schema + data) ir-respective of wsrep_replicate
d. enforce_ storage_ engine (options specific to PXC) storage_ engine option.
Replication status is captured even before enforce storage engine variable
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_
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.