PDF (US Ltr)
- 0.7Mb
PDF (A4)
- 0.7Mb
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 master_verify_checksum system variable. The slave_sql_verify_checksum system variable causes the slave 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 my.cnf/my.ini file to be sure checksums are enabled the next time the server is started.
Description As of MySQL Server 5.6, row-based replication now 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 my.cnf/my.ini file 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 master_verify_checksum system variable. The slave_sql_verify_checksum system variable causes the slave SQL thread to read checksums from the relay log.
Severity Minor Warning
Advice Investigate why master_verify_checksum is set to %verify_checksum%. Turn on server verification of checksums by issuing a SET GLOBAL master_verify_checksum = ON statement. Add master_verify_checksum = ON to your my.cnf/my.ini 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 master, as the master 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 Slaves must deal with network connectivity outages that affect the ability of the slave to get the latest data from the master, and hence cause replication to fall behind. However, the slave notices the network outage only after receiving no data from the master for slave_net_timeout seconds . You may want to decrease slave_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 slave_net_timeout=60 (or whatever value is reasonable to detect network connectivity outages in your environment) in the [mysqld] section of your my.cnf/my.ini file. The current value of slave_net_timeout is %net_timeout%.
Description Arbitrary or unintended updates to a slave may break replication or cause a slave to be inconsistent with respect to its master. Making a slave read_only can be useful to ensure that a slave accepts updates only from its master server and not from clients; it minimizes the possibility of unintended updates.
Severity Minor Warning
Advice Set read_only=1 in your my.cnf/my.ini file to ensure that a slave accepts updates only from its master 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 master_verify_checksum system variable. The slave_sql_verify_checksum system variable causes the slave SQL thread to read checksums from the relay log.
Severity Minor Warning
Advice Investigate why slave_sql_verify_checksum is set to %sql_verify_checksum%. Turn on slave verification of checksums by issuing a SET GLOBAL slave_sql_verify_checksum = ON statement. Add slave_sql_verify_checksum = ON to your my.cnf/my.ini file to be sure slave checksum verification is enabled the next time the server is started.
Description As of MySQL Server version 5.6, replication now supports parallel execution of transactions with multi-threading on the slave. When parallel execution is enabled, the slave SQL thread acts as the coordinator for a number of slave worker threads as determined by the value of the slave_parallel_workers server system variable. Note that the current implementation of multi-threading on the slave 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 master. 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 slave 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 slave than on the master, simply checking for the most recently executed transaction is not a guarantee that all previous transactions on the master have been executed on the slave. This has implications for logging and recovery when using a multi-threaded slave. 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 master is preserved on the slave using the slave_preserve_commit_order option variable: MySQL Manual: Replication Slave 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 Slave Options and Variables .
Severity Minor Warning
Advice Investigate why slave_parallel_workers is set to %parallel_workers%. Turn on parallel execution of transactions on a slave by issuing a SET GLOBAL slave_parallel_workers = n statement, where n depends on your specific environment. Add slave_parallel_workers = n to your my.cnf/my.ini file to be sure parallel execution of transactions is enabled the next time the server is started.