89566

89566



Updates involving nontransactional storage engines. When using GTlDs, updates to tables

using nontransactional storage engines such as My ISAM cannot madę in the same State ment 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 GTlDs 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 GTlDs is

broken, with the result that GTID-based replication cannot function correctly.

CREATE TABLE . . . SELECT StatementS. CREATE TABLE . . . SELECT is not safe for

State ment-based replication. When using row-based replication, this statement is actually logged as

twD 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.



Wyszukiwarka

Podobne podstrony:
Federated Storage Engine Notes and Tips You should be aware of the foliowing points when using the F
Federated Storage Engine Overview When you create a table using one of the standard storage engines
The csv Storage Engine The CSV storage engine Stores data in text files using comma-separated values
Using different storage engines on master and slave. It is possible to replicate transactional table
Using GTlDs for Failover and Scaleout There are a number of techniques when using MySQL Replication
Using Replication with Different Master and Slave Storage Engines It does not matter for the replica
Backward Compatibility Considerations of backward compatibility only apply when using a recent versi
Keycache Probes The keycache probes are triggered when using the index key cache used with the MylSA
SQL Syntax for Online DDL Typically, you do not need to do anything special to enable online DDL whe
Handling MySQL Recovery with ZFS When using ZFS replication to provide a constant copy of your data,
Indexes The MEMORY storage engine supports both HASH and BTREE indexes. You can specify one or the o
memcached Deployment When using memcached you can use a number of different potential deployment str
Multiple management nodes. When using multiple management servers: •    You must give
OtherStorage Engines Other storage engines may be available from third parties and community members
Overview of MySQL Storage Engine Architecture The MySQL pluggable storage engine architecture enable

więcej podobnych podstron