Mysql系统变量系列之（三）Replication

1. 全局事务模式：gtid_mode

• off：master不产生Normal_GTID，slave只接受来自master的ANONYMOUS_GTID；
• off_permissive：master不产生Normal_GTID，slave可以接受来自master的ANONYMOUS_GTID & Normal_GTID；
• on_permissive：master产生Normal_GTID，slave可以接受来自master的ANONYMOUS_GTID & Normal_GTID
• on：master产生Normal_GTID，只接受来自master的Normal_GTID

2. 强事务一致性：enforce_gtid_consistency = ON

3. 从服务器的二进制日志是否更新：log_slave_updates = ON

    通常情况，从服务器从主服务器接收到的更新不记入它的二进制日志。该选项告诉从服务器将其SQL线程执行的更新记入到从服务器自己的二进制日志。

4. 是否自动启动slave复制线程：skip_slave_start = ON

    该选项能够阻止备库在崩溃后自动启动复制，崩溃后启动复制，数据可能不一致。

5. 日志过期时间：expire_logs_days = 30

6. 数据校验配置：

    binlog_checksum =  CRC32, 在5.6之前，管理员只能通过ssl实现检校验
        5.6中，可以使用CRC32检查和来保证master和slave的数据的完整性。校验信息记录在master的二进制日志中和slave的relay日志中；

    master_verify_checksum = ON, 开启后，master从binary log读取信息的时候会执行校验；

    slave_sql_verify_checksum = ON，开启后，slave从relay log读取信息的时候会执行校验

7. 二进制日志文件格式：binlog_format = statement | row | mixed

8. 二进制日志文件的最大值：max_binlog_size = 512M

9. 二进制日志文件刷新到磁盘的频率：sync_binlog = 1

    sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。

    如果sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。

10. master信息，中继日志信息配置：

    relay_log_recovery = 1 

    relay_log_info_repository = TABLE，relay_log信息存储在mysql.slave_relay_log_info中；

    master_info_repository = TABLE，master信息存储在mysql.slave_master_info中；

11. slave并行回放线程配置：

    slave_parallel_workers = 4
    slave_parallel_type = LOGICAL_CLOCK

12. 基于行操作的查询日志事件：binlog_rows_query_log_events = ON

    

Property	Value
Command-Line Format	--binlog-rows-query-log-events[={OFF|ON}]
System Variable	binlog_rows_query_log_events
Scope	Global, Session
Dynamic	Yes
Type	Boolean
Default Value	OFF

This system variable affects row-based logging only. When enabled, it causes the server to write informational log events such as row query log events into its binary log. 

These informational events are normally ignored by MySQL programs reading the binary log and so cause no issues when replicating or restoring from backup. To view them, increase the verbosity level by using mysqlbinlog's --verbose option twice, either as -vv or --verbose --verbose.