Oracle 5.0 Reference Manual page 1523

Temporary
flushed to disk before the problem occurred:
• For transactions, the slave commits and then updates relay-log.info. If a crash occurs between
these two operations, relay log processing will have proceeded further than the information file
indicates and the slave will re-execute the events from the last transaction in the relay log after it has
been restarted.
• A similar problem can occur if the slave updates
before the write has been flushed to disk. Writes are not forced to disk because the server relies on
the operating system to flush the file from time to time.
The fault tolerance of your system for these types of problems is greatly increased if you have a good
uninterruptible power supply.
16.4.1.14. Replication and
When a master server shuts down and restarts, its
this effect to slaves, the first time that the master uses a given
event that notifies slaves that the table must to be emptied by writing a
to the binary log.
When a slave server shuts down and restarts, its
to be out of synchrony with the master and may lead to other failures or cause the slave to stop. For
example,
INSERT INTO ... SELECT FROM memory_table
the master and slave.
The safe way to restart a slave that is replicating
the
MEMORY
safe to restart the slave.
The size of
variable, which is not replicated (see
max_heap_table_size
TABLE ... ENGINE = MEMORY
tables following a server restart. If you increase the value of this variable on the master without doing
so on the slave, it becomes possible for a table on the master to grow larger than its counterpart
on the slave, leading to inserts that succeed on the master but fail on the slave with
errors. This is a known issue (Bug #48666). In such cases, you must set the global value of
full
max_heap_table_size
recommended that you restart both the master and slave MySQL servers, to insure that the new value
takes complete (global) effect on each of them.
See Section 14.4, "The
16.4.1.15. Replication and Temporary Tables
Safe slave shutdown when using temporary tables.
in the case where you stop the slave server (not just the slave threads) and you have replicated
temporary tables that are open for use in updates that have not yet been executed on the slave. If you
stop the slave server, the temporary tables needed by those updates are no longer available when
the slave is restarted. To avoid this problem, do not shut down the slave while it has temporary tables
open. Instead, use the following procedure:
1. Issue a
2. Use
SHOW STATUS
3. If the value is not 0, restart the slave SQL thread with
procedure later.
Replication Features and Issues
Tables". Unclean shutdowns might produce problems, especially if the disk cache was not
Tables
MEMORY
tables on the master and wait until those changes have replicated to the slave. Then it is
tables is limited by the value of the
MEMORY
takes effect for
[468] on the slave as well as on the master, then restart replication. It is also
(HEAP) Storage
MEMORY
STOP SLAVE SQL_THREAD
to check the value of the
relay-log.info
MEMORY
MEMORY
MEMORY
max_heap_table_size
Section 16.4.1.28, "Replication and
tables that are created or updated using
MEMORY
or following the change, or for all
TRUNCATE TABLE
Engine", for more information about
statement.
Slave_open_temp_tables
1503
but the server host crashes
(HEAP) tables become empty. To replicate
table after startup, it logs an
MEMORY
statement for that table
DELETE
tables become empty. This causes the slave
may insert a different set of rows on
tables is to first drop or delete all rows from
Variables"). A change in
Temporary tables are replicated except
[531]
START SLAVE SQL_THREAD
[468] system
ALTER
MEMORY
Table is
tables.
MEMORY
variable.
and repeat the