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

.