Oracle 5.0 Reference Manual page 1522

Replication of
guaranteed, since the order of the rows affected is not defined. Such statements can be replicated
correctly only if they also contain an
16.4.1.10. Replication and
Using
LOAD TABLE FROM MASTER
MySQL 5.0 may corrupt the table data, and is not supported. (Bug #16261)
The
LOAD DATA INFILE
CONCURRENT INFILE
is replicated as
INFILE
The following applies only if either the master or the slave is running MySQL 5.0.3 or older: If on the
master a
LOAD DATA INFILE
on), the slave skips the
inserted or updated table records before being interrupted, these modifications are not replicated to the
slave.
16.4.1.11. Replication and the Slow Query Log
Replication slaves do not write replicated queries to the slow query log, even if the same queries were
written to the slow query log on the master. This is a known issue. (Bug #23300)
16.4.1.12. Replication and
When used on a corrupted or otherwise damaged table, it is possible for the
to delete rows that cannot be recovered. However, any such modifications of table data performed
by this statement are not replicated, which can cause master and slave to lose synchronization.
For this reason, in the event that a table on the master becomes damaged and you use
to repair it, you should first stop replication (if it is still running) before using
TABLE
then afterward compare the master's and slave's copies of the table and be prepared to correct any
discrepancies manually, before restarting replication.
16.4.1.13. Replication and Master or Slave Shutdowns
It is safe to shut down a master server and restart it later. When a slave loses its connection to the
master, the slave tries to reconnect immediately and retries periodically if that fails. The default is
to retry every 60 seconds. This may be changed with the
master-connect-retry
outages. However, the slave notices the network outage only after receiving no data from the master
for
slave_net_timeout
slave_net_timeout
An unclean shutdown (for example, a crash) on the master side can result in the master binary log
having a final position less than the most recent position read by the slave, due to the master binary log
file not being flushed. This can cause the slave not to be able to replicate when the master comes back
up. Setting
sync_binlog=1
it causes the master to flush its binary log more frequently.
Unclean master shutdowns may cause inconsistencies between the content of tables and the binary
log. This can be avoided by using
the master. See
Shutting down a slave cleanly is safe because it keeps track of where it left off. However, be careful
that the slave does not have temporary tables open; see
Replication Features and Issues
clauses in DELETE, UPDATE, and
LIMIT
ORDER BY
Operations
LOAD
statement
is replicated as
LOAD DATA LOCAL
is interrupted (integrity constraint violation, killed connection, and so
LOAD DATA INFILE
REPAIR TABLE
[1453] option. A slave also is able to deal with network connectivity
[1466] seconds. If your outages are short, you may want to decrease
[1466]. See Section 5.1.4, "Server System
[1472] in the master
InnoDB
Section 5.2.3, "The Binary
Note
--innodb-safe-binlog
made obsolete by the introduction of XA transaction support.
INSERT ... SELECT
clause.
where the master is running MySQL 4.1 and the slave is running
option is not replicated; that is,
CONCURRENT
INFILE, and
LOAD DATA
INFILE. (Bug #34628)
entirely. This means that if this command permanently
CHANGE MASTER TO
file helps to minimize this problem because
my.cnf
tables and the
--innodb-safe-binlog
Log".
[409] is unneeded as of MySQL 5.0.3, having been
Section 16.4.1.15, "Replication and
1502
statements is not
LOAD DATA
LOAD DATA CONCURRENT LOCAL
REPAIR TABLE
REPAIR
REPAIR
statement or
Variables".
[409]
statement
TABLE,
--
option on