NDB Replication
How we replicate all changes in one cluster to another cluster.
The serialization of transactions happens in the data nodes. Any attempt at replication without involving them just won't work.
[edit] History
There was a previous implementation that you will see parts of in 4.1 and 5.0 that's called "Global REPlication" - or more commonly, GREP. All traces (should) be removed from 5.1 and onwards. We now use a new implementation that integrates with the MySQL Binary Log and standard replication infrastructure.
[edit] NDB Injector Thread
A thread inside the MySQL Server (the NDB Injector Thread) subscribes to events on NDB tables (using NDBAPI). It injects all the changes in a Global Checkpoint as a single transaction in the binary log. The event subscribed to is "row committed". Non-committed operations are not replicated.
[edit] Row Based Replication
As modifications to NDB tables may be through SQL locally, SQL through another node or via the NDBAPI, getting SQL back is near impossible. The SUMA block sends back images of rows. We convert these into MySQL format and write the rows to the binlog using the row based replication API. This means that only 5.1 and higher can read the binary log.