[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here is an explanation of what is supported and what is not:
AUTO_INCREMENT
,
LAST_INSERT_ID()
, and TIMESTAMP
values.
USER()
and LOAD_FILE()
functions
are replicated without changes and will thus not work reliably on the
slave. This is also true for CONNECTION_ID()
in slave versions
older than 4.1.1.
The new PASSWORD()
function in MySQL 4.1, is well
replicated since 4.1.1 masters; your slaves must be 4.1.0 or above
to replicate it. If you have older slaves and need to replicate
PASSWORD()
from your 4.1.x master, you must start your master
with option --old-password
.
SQL_MODE
, UNIQUE_CHECKS
,
SQL_AUTO_IS_NULL
variables are replicated only starting from 5.0.0.
SQL_SELECT_LIMIT
and TABLE_TYPE
variables are not
replicated yet. FOREIGN_KEY_CHECKS
is replicated since version
4.0.14.
--default-character-set
)
on the master and the slave. Otherwise, you may get duplicate key errors on
the slave, because a key that is regarded as unique in the master character
set may not be unique in the slave character set. Character sets will
be replicated in 5.0.x.
BEGIN/COMMIT
block, as
the slave will later start at the beginning of the BEGIN
block.
This issue is on our TODO and will be fixed in the near future.
DATA DIRECTORY
or INDEX DIRECTORY
clause was used in a
CREATE TABLE
on master, then these clauses will be used too on
slave. Starting from MySQL 4.0.15 there is a SQL_MODE
mode called
NO_DIR_IN_CREATE
; if the slave server is run in this mode, it will
simply cut off the clauses before replicating the CREATE TABLE
(so the
MyISAM data and index files will be created in the slave's datadir
directory).
FLUSH
, ANALYZE
, OPTIMIZE
, REPAIR
commands
are not stored in the binary log and thus are
not replicated to the slaves. This is not normally a problem as
these commands don't change anything. However, it does mean that if you
update the MySQL privilege tables directly without using the
GRANT
statement and you replicate the mysql
privilege
database, you must do a FLUSH PRIVILEGES
on your slaves to put
the new privileges into effect. Also if you use
FLUSH TABLES
when renaming a MyISAM
table involved in a
MERGE
table, you will have to issue FLUSH TABLES
manually on the slave.
Since MySQL 4.1.1, these commands are written to the binary log
(except FLUSH LOGS
, FLUSH MASTER
, FLUSH SLAVE
,
FLUSH TABLES WITH READ LOCK
) unless you specify
NO_WRITE_TO_BINLOG
(or its alias LOCAL
).
For a syntax example, see FLUSH
.
SELECT
queries to different
slaves.
HEAP
table having been emptied by master's shutdown/restart by writing a
DELETE FROM
to its binary log the first time it uses the table since
startup. See 14.3 HEAP
Tables for more details.
STOP SLAVE
statement.
SHOW STATUS
to check the value of the Slave_open_temp_tables
variable.
mysqladmin shutdown
command to
shut down the slave.
START SLAVE
.
We have plans to fix this problem in the near future.
log-slave-updates
enabled.
Note, however, that many queries will not work correctly in this kind of
setup unless your client code is written to take care of the potential
problems that can happen from updates that occur in different sequence
on different servers.
This means that you can do a setup like the following:
A -> B -> C -> A |
Server IDs are encoded in the binary log events. A will know when an event it reads had originally been created by A, so A will not execute it and there will be no infinite loop. But this circular setup will work only if you only if you perform no conflicting updates between the tables. In other words, if you insert data in A and C, you should never insert a row in A that may have a conflicting key with a row insert in C. You should also not update the same rows on two servers if the order in which the updates are applied matters.
START SLAVE
.
master-connect-retry
seconds (default
60). Because of this, it is safe to shut down the master, and
then restart it after a while. The slave will also be able to deal with
network connectivity outages. However, the slave will notice the
network outage only after receiving no data from the master for
slave_net_timeout
seconds. So if your outages are short, you may want
to decrease slave_net_timeout
.
See section SHOW VARIABLES
.
--slave-skip-errors
option.
This option is available starting with MySQL Version 3.23.47.
BEGIN/COMMIT
segment, updates to the binary log may be out of sync
if some thread changes the non-transactional table before the
transaction commits. This is because the transaction is written to the
binary log only when it's commited.
COMMIT
or not written at
all if you use ROLLBACK
; you have to take this into account
when updating both transactional tables and non-transactional tables
in the same transaction if you are using binary logging for backups or
replication. In version 4.0.15, we changed the logging behavior
for transactions that mix updates to transactional and
non-transactional tables, which solves the problems (order of queries
is good in binlog, and all needed queries are written to the binlog
even in case of ROLLBACK
). The problem which remains is when a
second connection updates the non-transactional table while the first
connection's transaction is not finished yet (wrong order can still
occur, because the second connection's update will be written
immediately after it is done).
The following table lists problems in MySQL 3.23 that are fixed in MySQL 4.0:
LOAD DATA INFILE
is handled properly, as long as the data file
still resides on the master server at the time of update
propagation.
LOAD LOCAL DATA INFILE
will be skipped.
RAND()
in updates does not replicate properly.
Use RAND(some_non_rand_expr)
if you are replicating updates with
RAND()
. You can, for example, use UNIX_TIMESTAMP()
for the
argument to RAND()
. This is fixed in 4.0.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |