89411

MySQL Cluster. The default binary logging format in all MySQL Cluster NDB 7.3 releases is MIXED.

You should notę that MySQL Cluster Replication always uses row-based replication, and that the

NDB storage engine is incompatible with statement-based replication. See Section 17.6.2, “General

Requirements for MySQL Cluster Replication", for morę information.

When using MIXED format the binary logging format is determined in part by the storage engine being

used and the statement being executed. For morę information on mixed-format logging and the rules

governing the support of different logging formats, see Section 5.2.4.3, “Mixed Binary Logging Format".

The logging format in a running MySQL server is controlled by setting the

binlog__format [2047]

sen/er system variable. This variable can be set with session or global scope. The rules governing

when and howthe new setting takes effect are the same as for other MySQL server system variables—

setting the variable for the current session lasts only until the end of that session, and the change is not

visible to other sessions; setting the variable globally requires a restart of the server to take effect. For

morę information, see Section 13.7.4, “SET Syntax'\

There are conditions under which you cannot change the binary logging format at runtime or doing so

causes replication tofail. See Section 5.2 4.2, “Setting The Binary Log Format".

You must have the SUPER [776] privilege to set either the global or session

binlog_format [2047] value.

The statement-based and row-based replication formats have different issues and limitations. For a

comparison of their relative advantages and disadvantages, see Section 16.1.2.1, “Advantages and

Disadvantages of Statement-Based and Row-Based Replication".

With statement-based replication, you may encounter issues with replicating stored routines or

triggers. You can avoid these issues by using row-based replication instead. For morę information, see

Section 19.7, “Binary Logging of Stored Programs”.