InnoDB Cluster Configuration

With statement-based replication, you may encounter issues with replicating stored routines or triggers (i.e. nondeterministic operations). You can avoid these issues by using row-based replication instead.
Row-based logging generates significantly larger log files than statement-based logging.
Statement-based logging can be useful as a way of auditing.

MIXED - statement-based replication is used, except for cases where only row-based replication is guaranteed to lead to proper results. For example, this happens when statements contain loadable functions or the UUID() function.
STATEMENT - When using statement-based binary logging, the source writes SQL statements to the binary log. Replication of the source to the replica works by executing the SQL statements on the replica.
ROW - When using row-based logging, the source writes events to the binary log that indicate how individual table rows are changed. Replication of the source to the replica works by copying the events representing the changes to the table rows to the replica. (1)

binlog_transaction_dependency_tracking

NOTE: binlog_transaction_dependency_tracking is deprecated and will be removed in a future release. When upgrading to a future version (e.g. 8.4), you should RESET PERSIST binlog_transaction_dependency_tracking (if previously persisted) and rely on the server’s default logic instead of setting it manually.

Default: COMMIT_ORDER
Required: WRITESET

binlog_transaction_dependency_history_size

Default: 25000
Recommended: 25000

Range = 1 to 1000000

Determines the number of row hashes to be kept and checked for the latest transaction to have changed a given row

enforce_gtid_consistency

Default: OFF
Required: ON

Change needs MySQL instance restart

OFF - all transactions are allowed to violate GTID consistency.
ON - no transaction is allowed to violate GTID consistency.
WARN - all transactions are allowed to violate GTID consistency, but a warning is generated in this case

gtid_mode

Default: OFF
Required: ON

Change needs MySQL instance restart

Controls whether GTID (Global Transaction Identifier) based logging is enabled and what type of transactions the logs can contain.

OFF - Both new and replicated transactions must be anonymous
OFF_PERMISSIVE - New transactions are anonymous. Replicated transactions can be either anonymous or GTID transactions.
ON_PERMISSIVE - New transactions are GTID transactions. Replicated transactions can be either anonymous or GTID transactions.
ON - Both new and replicated transactions must be GTID transactions.

server_id

Default: 1
Required: a unique id

Change needs MySQL instance restart

slave_parallel_type

Default: DATABASE
Required: LOGICAL_CLOCK
Deprecated

DATABASE - Transactions that update different databases are applied in parallel.
LOGICAL_CLOCK - Transactions that are part of the same binary log group commit on a source are applied in parallel on a replica.

slave_preserve_commit_order

Default: OFF (0)
Required: ON (1)
Deprecated

If slave_preserve_commit_order is 0, the transactions that the replica applies in parallel may commit out of order.

transaction_write_set_extraction

Default: OFF
Required: XXHASH64 (or MURMUR32)

Defines the algorithm used to generate a hash identifying the writes associated with a transaction.

OFF
MURMUR32
XXHASH64

Bibliography

https://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-options-binary-log.html(1) https://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-formats.htmlhttps://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-sbr-rbr.htmlhttps://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-options-gtids.htmlhttps://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-gtids.html

Page updated

Google Sites

Report abuse