AUTO_INCREMENTDIRECTORY StatementsFLUSHMEMORY Table Typesmysql Database
In general, replication compatibility at the SQL level requires
that any features used be supported by both the master and the
slave servers. If you use a feature on a master server that is
available only as of a given version of MySQL, you cannot
replicate to a slave that is older than that version. Such
incompatibilities are likely to occur between series, so that, for
example, you cannot replicate from MySQL 5.1 to
5.0. However, these incompatibilities also can occur
for within-series replication. For example, the
SLEEP() function is available in MySQL 5.0.12
and up. If you use this function on the master server, you cannot
replicate to a slave server that is older than MySQL 5.0.12.
If you are planning to use replication between 5.1 and a previous version of MySQL you should consult the edition of the MySQL Reference Manual corresponding to the earlier release series for information regarding the replication characteristics of that series.
The following sections provide details about what is supported and
what is not, and about specific issues and situations that may
occur when replicating certain statements. Additional
InnoDB-specific information about replication
is given in Section 14.5.6.5, “InnoDB and MySQL Replication”.
With MySQL's classic statement-based replication, there may be issues with replicating stored routines or triggers. You can avoid these issues by using MySQL's row-based replication instead. For a detailed list of issues, see Section 18.4, “Binary Logging of Stored Routines and Triggers”. For a description of row-based replication, see Section 6.1.2, “Replication Formats”.

User Comments
FWI. I just spent several hours trying to figure out why my two servers in chained replication A -> B -> A were not replicateing correctly when last week they were. After much agonizing i determined that only tables that had a timestamp colum where effected. It turned out one of the servers times had fallen behind by almost an hour. When that server issued an update the other server was ignoring the request (i can only assume because it figured that record had an older timestamp and therefore ignored it.) While this is probably the best behaviour it can catch you unaware so i thought i would put it up here to help anyone else in a similar situation. BTW I was using MS Access to access the database so it could have been a problem in Access, MyODBC or MySQL, I'm not entirely sure.
CONNECTION_ID() is replicated correctly in statement-based replication, even though on the slave everything is run from a single connection. Each binlog entry contains the thread_id which ran the query, so this can be reliably recreated on the slave.
Add your own comment.