Updates involving nontransactional storage engines-opracowanie

Updates involving nontransactional storage engines. When using GTIDs, updates to tables
using nontransactional storage engines such as MyISAM cannot made in the same statement or
transaction as updates to tables using transactional storage engines such as InnoDB.
This restriction is due to the fact that updates to using a nontransactional storage engine mixed with
updates to tables that use a transactional storage engine within the same transaction can result in
multiple GTIDs being assigned to the same transaction. This problem can also occur in at least two
other cases, listed here:
• When the master and the slave use different storage engines for their respective versions of the
same table, where one storage engine is transactional and the other is not.
• When both the master and the slave use a nontransactional engine, but use different binary logging
formats (for example, when the master has binlog_format=ROW [2047] and the slave has
binlog_format=STATEMENT).
In any of the cases just mentioned, the one-to-one correspondence between transactions and GTIDs is
broken, with the result that GTID-based replication cannot function correctly.
CREATE TABLE ... SELECT statements. CREATE TABLE ... SELECT is not safe for
statement-based replication. When using row-based replication, this statement is actually logged as
two separate events—one for the creation of the table, and another for the insertion of rows from the
source table into the new table just created. When this statement is executed within a transaction, it is
possible in some cases for these two events to receive the same transaction identifier, which means
that the transaction containing the inserts is skipped by the slave. Therefore, CREATE TABLE ...
SELECT is not supported when using GTID-based replication.
... zobacz całą notatkę