|
The following are known problems or issues when using
replication with MySQL Cluster in MySQL 5.1:
The use of data definition statements, such as
CREATE TABLE , DROP
TABLE , and ALTER TABLE , are
recorded in the binary log for only the MySQL server on
which they are issued.
-
A MySQL server involved in replication should be started or
restarted after using ndb_restore to
discover and setup replication of NDB
Cluster tables. Alternatively, you can issue a
SHOW TABLES statement on all databases in
the cluster.
Similarly, when using CREATE SCHEMA , the
new database is not automatically discoverable by the MySQL
server. Thus, this statement must be issued on each MySQL
server participating in the cluster when creating a new
database.
Restarting the cluster with the
--initial option will cause the
sequence of GCI and epoch numbers to start over from
0 . (This is generally true of MySQL
Cluster and not limited to replication scenarios involving
Cluster.) The MySQL servers involved in replication should
in this case be replicated. After this, you should use the
RESET MASTER and RESET
SLAVE statements to clear the invalid
binlog_index and
apply_status tables. respectively.
See
Section 16.7.9.2, “Initiating Discovery of Schema Changes”,
for more information about the first two items listed above, as
well as some examples illustrating how to handle applicable
situations.
|
|