Enterprise Manager
The following are the MySQL Replication Standard compliance rules:
Description Binary logs written and read by the MySQL Server are now crash-safe, because only complete events (or transactions) are logged or read back. By default, the server logs the length of the event as well as the event itself and uses this information to verify that the event was written correctly. You can also cause the server to write checksums for the events using CRC32 checksums by setting the binlog_checksum system variable, to add an extra level of safety to the logs and the replication process. To cause the server to read checksums from the binary log, use the source_verify_checksum system variable. The replica_sql_verify_checksum system variable causes the replica SQL thread to read checksums from the relay log.
Severity Minor Warning
Advice Investigate why binlog_checksum is
set to %binlog_checksum%. Turn on checksums by issuing a SET
GLOBAL binlog_checksum = CRC32 statement. Add binlog_checksum =
CRC32 to your MySQL configuration file
(my.cnf) to be sure checksums are enabled
the next time the server is started.
Description Row-based replication supports row image control. By logging only those columns required for uniquely identifying and executing changes on each row (as opposed to all columns) for each row change, it is possible to save disk space, network resources, and memory usage. You can determine whether full or minimal rows are logged by setting the binlog_row_image server system variable to one of the values minimal (log required columns only), full (log all columns), or noblob (log all columns except for unneeded BLOB or TEXT columns).
Severity Minor Warning
Advice Investigate why binlog_row_image is
set to %binlog_row_image%. Log only those columns required for
uniquely identifying and executing changes on each row by
issuing a SET GLOBAL binlog_row_image =
minimal. Add binlog_row_image = minimal to your MySQL
configuration file (my.cnf) to be sure the
new setting is in effect the next time the server is started.
Description Binary logs written and read by the MySQL Server are now crash-safe, because only complete events (or transactions) are logged or read back. By default, the server logs the length of the event as well as the event itself and uses this information to verify that the event was written correctly. You can also cause the server to write checksums for the events using CRC32 checksums by setting the binlog_checksum system variable, to add an extra level of safety to the logs and the replication process. To cause the server to read checksums from the binary log, use the source_verify_checksum system variable. The replica_sql_verify_checksum system variable causes the replica SQL thread to read checksums from the relay log.
Severity Minor Warning
Advice Investigate why
source_verify_checksum is set to %verify_checksum%. Turn on
server verification of checksums by issuing a SET
GLOBAL source_verify_checksum = ON statement. Add
source_verify_checksum = ON to your MySQL
configuration file to be sure server checksum verification is
enabled the next time the server is started. However, keep in
mind that this will add overhead on the source, as the source
will need to read the binary log event and verify that the
checksum for the event on disk matches what it has in memory.
You may want to measure your database performance on a test
system before and after making this change to be sure the
overhead is acceptable before deploying the change in
production.
Description Replicas must deal with network connectivity outages that affect the ability of the replica to get the latest data from the source server, and hence cause replication to fall behind. However, the replica notices the network outage only after receiving no data from the source server for replica_net_timeout seconds . You may want to decrease replica_net_timeout so the outages -- and associated connection retries -- are detected and resolved faster. The default for this parameter is 3600 seconds (1 hour), which is too high for many environments.
Severity Minor Warning
Advice Set
replica_net_timeout=60 (or whatever value is
reasonable to detect network connectivity outages in your
environment) in the [mysqld] section of your MySQL configuration
file (my.cnf). The current value of
replica_net_timeout is %net_timeout%.
Description Arbitrary or unintended updates to a replica may break replication or cause a replica to be inconsistent with respect to its source server. Making a replica read_only can be useful to ensure that a replica accepts updates only from its source server and not from clients; it minimizes the possibility of unintended updates.
Severity Minor Warning
Advice Set read_only=1 in your MySQL
configuration file (my.cnf) to ensure that
a replica accepts updates only from its source server and not
from clients, and restart your MySQL server.
Description Binary logs written and read by the MySQL Server are now crash-safe, because only complete events (or transactions) are logged or read back. By default, the server logs the length of the event as well as the event itself and uses this information to verify that the event was written correctly. You can also cause the server to write checksums for the events using CRC32 checksums by setting the binlog_checksum system variable, to add an extra level of safety to the logs and the replication process. To cause the server to read checksums from the binary log, use the source_verify_checksum system variable. The replica_sql_verify_checksum system variable causes the replica SQL thread to read checksums from the relay log.
Severity Minor Warning
Advice Investigate why
replica_sql_verify_checksum is set to %sql_verify_checksum%.
Turn on replica verification of checksums by issuing a SET
GLOBAL replica_sql_verify_checksum = ON statement. Add
replica_sql_verify_checksum = ON to your MySQL configuration
file (my.cnf) to be sure replica checksum
verification is enabled the next time the server is started.
Description Replication supports parallel execution of transactions with multi-threading on the replica. When parallel execution is enabled, the replica SQL thread acts as the coordinator for a number of replica worker threads as determined by the value of the replica_parallel_workers server system variable. Note that the current implementation of multi-threading on the replica assumes that data and updates are partitioned on a per-database basis, and that updates within a given database occur in the same relative order as they do on the source server. However, it is not necessary to coordinate transactions between different databases. Transactions can then also be distributed per database, which means that a worker thread on the replica can process successive transactions on a given database without waiting for updates to other databases to complete. Also note that since transactions on different databases can occur in a different order on the replica than on the source server, simply checking for the most recently executed transaction is not a guarantee that all previous transactions on the source server have been executed on the replica. This has implications for logging and recovery when using a multi-threaded replica. However, as of MySQL Server 5.7.5, you can ensure that the order in which transactions were committed to the binary log on the source server is preserved on the replica using the replica_preserve_commit_order option variable: MySQL Manual: Replication Replica Options and Variables . Finally, note that beginning with MySQL Server 5.7.2, there is also support for intra-schema parallelization (LOGICAL_CLOCK): MySQL Manual: Replication Replica Options and Variables .
Severity Minor Warning
Advice Investigate why
replica_parallel_workers is set to %parallel_workers%. Turn on
parallel execution of transactions on a replica by issuing a SET
GLOBAL replica_parallel_workers = n statement, where n depends
on your specific environment. Add replica_parallel_workers = n
to your MySQL configuration file (my.cnf)
to be sure parallel execution of transactions is enabled the
next time the server is started.