Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




16.7.3. Known Issues

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, “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.

  Published under the terms of the GNU General Public License Design by Interspire