Oracle 5.0 Reference Manual page 1527

care should be taken when replicating transactional tables from the master to nontransactional tables
on the slaves.
Beginning with MySQL 5.0.56, every transaction (including
recorded in the binary log as though it starts with a
or a
ROLLBACK
affecting tables using a nontransactional storage engine such as
as nontransactional, even when
16.4.1.26. Replication and Triggers
Known issue: In MySQL 5.0.17, the syntax for
clause for specifying which access privileges to check at trigger invocation time. (See
"CREATE TRIGGER
server older than MySQL 5.0.17 to a slave running MySQL 5.0.17 through 5.0.19, replication of
CREATE TRIGGER
workaround is to create triggers on the master using a version-specific comment embedded in each
CREATE TRIGGER
CREATE /*!50017 DEFINER = 'root'@'localhost' */ TRIGGER ... ;
CREATE TRIGGER
clause from the comment and execute successfully.
DEFINER
This slave problem is fixed as of MySQL 5.0.20.
16.4.1.27. Replication and Views
Views are always replicated to slaves. Views are filtered by their own name, not by the tables they refer
to. This means that a view can be replicated to the slave even if the view contains a table that would
normally be filtered out by
ensure that views do not replicate table data that would normally be filtered for security reasons.
16.4.1.28. Replication and Variables
The
foreign_key_checks
are all replicated.
[495]
sql_mode
mysqlbinlog
NO_DIR_IN_CREATE
The
storage_engine
intended to facilitate replication between different storage engines.
The
read_only
different effects with regard to temporary tables, table locking, and the
different MySQL versions.
The
max_heap_table_size
variable on the master without doing so on the slave can lead eventually to
on the slave when trying to execute
permitted to grow larger than its counterpart on the slave. For more information, see
"Replication and
Starting from MySQL 5.0.3 (master and slave), replication works even if the master and slave have
different global character set variables. Starting from MySQL 5.0.4 (master and slave), replication
works even if the master and slave have different global time zone variables.
Session variables are not replicated properly when used in statements that update tables. For example,
the following sequence of statements will not insert the same data on the master and the slave:
Replication Features and Issues
statement. However, this does not apply to nontransactional changes; any statements
autocommit
Syntax", for more information.) However, if you attempt to replicate from a master
statements fails on the slave with a
statement:
statements written this way will replicate to newer slaves, which pick up the
replication-ignore-table
[451],
unique_checks
is also replicated except for the
parses a
SET @@sql_mode = mode
[537], is passed to the receiving server.
[497] system variable is not replicated, regardless of the logging mode; this is
[488] system variable is not replicated. In addition, the enabling this variable has
[468] system variable is not replicated. Increasing the value of this
INSERT
Tables".
MEMORY
autocommit
statement, and ends with either a
BEGIN
MyISAM
[436] is enabled. (Bug #26395)
CREATE TRIGGER
Definer not fully qualified
rules. Care should therefore be taken to
[504], and
sql_auto_is_null
NO_DIR_IN_CREATE
statement, the full
statements on a
MEMORY
1507
[436] transactions) is
are regarded for this purpose
changed to include a
DEFINER
Section 13.1.11,
[493]
[537] mode. However, when
value, including
mode
statement in
SET PASSWORD
Table is full
table on the master that is thus
Section 16.4.1.14,
COMMIT
error. A
variables
errors