過濾規則 範圍 ria ted conn -m cksum date 之間

特別聲明： 所有的過濾規則不建議在主庫上設置。

server_id

是一個整數，範圍：1 至 power(2,32)-1 之間。 推薦使用端口號+ip最後一位的方式。 唯一區別ID，同一個集群不可重復，從5.6開始可動態修改。 server_uuid 唯一區別ID，同一個集群不可重復，從5.6開始可動態修改。 從5.6開始，系統根據函數自動生成唯一的一個值，默認存放在$datadir/auto.cnf ，MySQL啟動時，會判斷auto.cnf文件是否存在，如果不存在auto.cnf文件就會創建。在gtid中用此參數標識一個server，而不是server_id。 cat auto.cnf [auto] server-uuid=b16b53da-c1a1-11e6-915f-000c29355816 log_bin_index
mysql> show variables like ‘log_bin_index‘; +---------------+---------------------------------------+ | Variable_name | Value | +---------------+---------------------------------------+ | log_bin_index | /data/mysql/3306/logs/mysql-bin.index | +---------------+---------------------------------------+ 此參數與log_bin_basename 參數文件做的一個前綴。 mysql> show variables like ‘log_bin_basename‘; +------------------+---------------------------------+ | Variable_name | Value | +------------------+---------------------------------+ | log_bin_basename | /data/mysql/3306/logs/mysql-bin | +------------------+---------------------------------+ 此文件（ /data/mysql/3306/logs/mysql-bin.index）可用vi等工具手工編輯。 cat /data/mysql/3306/logs/mysql-bin.index /data/mysql/3306/logs/mysql-bin.000003 /data/mysql/3306/logs/mysql-bin.000004 /data/mysql/3306/logs/mysql-bin.000005 binlog_format binlog日誌格式：statement，row，mixed三種。 可動態修改。 生成環境建議使用row格式。 binlog_cache_size binlog寫入bugger。 建議設置值在1M-4M之間。 max_binlog_size 限制單個binlog大小。 默認是1G，在生產環境binlog文件生成要兩分鐘以上，此值推薦使用128M或者256M。 可動態修改。 sync_binlog 多少個SQL之後，調用fdatasync()函數刷新binlog到disk。 （fsync()和fdatasync()的區別是什麽？fsync是完全刷新到磁盤，fdatasync值刷新數據，不刷新metedata。） 可動態修改。 交易系統為了安全，建議設置此值為1 。 expire_logs_days binlog保存多少天。 可動態修改。 推薦此值設置為7天。 log_bin_trust_function_creators
開啟binlog時，是否允許創建存儲過程（除非有super權限，或者指定deterministic、reads sql data、no sql） 可動態修改。 推薦開啟。 log_awrnings 如果政治設置的大於1，會在錯誤日誌裏看到異常斷開的連接（Aborted connection ）或者是被拒絕的請求。 binlog_row_image 5.6.2後出現。 full： 記錄所有的行信息，和以前沒有區別。 minimal： 只記錄要修改的列的記錄 noblob： 記錄除了BLOB和TEXT之外的所有字段 註意，當binlog_format = statement的時候，不起作用； = row的時候，完美支持； = mixed 的時候，根據實際情況決定； binlog_rows_query_log_events 5.6.2後出現。 在row模式下開啟該參數,將把sql語句打印到binlog日誌裏面.默認是0(off); 雖然將語句放入了binlog,但不會執行這個sql,就相當於註釋一樣.但對於dba來說,在查看binlog的時候,很有用處. 基於MySQL 5.6 GTID的Crash Recover 在5.6.23版本後才穩定。 傳統復制也是支持的（前提是master_info_repository,relay_log_info_repository 兩個值改為table ）。 binlog_gtid_simple_recovery( 5.6.21 -5.6.23) 這個功能剛出來不久，在掛掉時，可以找到自己同步到哪裏，完成的同步的GTID上接著同步，重新拉一下日誌。 如果沒啟用這個特性，會從binlog全部搜索一下，如果日誌很多，需要占用的時間比較多。 binlogging_impossable_mode ->binlog_error_action binlog_error_action 當不能寫binlog時，可以爆出來錯，默認沒開啟：IGNORE_ERROR。 特別說明 5.6.5，5.7.5以後binlog v2格式，引入了GTID，主庫是5.5從庫是5.6是OK的，但是5.6到5.5或者5.7到5.6是同步不了的，會報錯，如果相兼容的話，需要設置兩個參數（分別是binlog_checksum=none和log_bin_use_v1_row_events=on） binlog-do-db binlog記錄db，除此外，其他db上的binlog都不記錄，存在風險。 use mysql;update db1.t1 set user=‘user2‘ where id=1; 這個SQL會記錄到binlog裏面麽？ SBR模式下，這個SQL就不會記錄binlog，會導致主從不一致，而在RBR/MBR模式下，則會被記錄。 類似CREATE TABLE mydb3.mytable1 like mytable1,則會一如既然的記錄binlog，只有INSERT/UPDATE/DELETE不會被記錄。 binlog-ignore-db 和binlog-do-db規則相反。 se mysql;update db1.t1 set user=‘user2‘ where id=1; 這個SQL會記錄到binlog裏面麽？ SBR模式下，這個SQL就不會記錄binlog，會導致主從不一致，而在RBR/MBR模式下，則會被記錄。 類似CREATE TABLE mydb3.mytable1 like mytable1,則會一如既然的記錄binlog，只有INSERT/UPDATE/DELETE不會被記錄。 max_binlog_cache_size binlog最大的cache size，有大SQL寫入時需要用到，或者大數據LOAD DATA時。 binlog_stmt_cache_size 用於cache那些事務中非事務表產生的SQL語句，如果經常在事務中涉及到非事務表，需要加大該參數。 binlog_direct_non_transactional_updates 事務中既有事務表也有非事務表的情況下，發生數據變更時，非事務表會直接寫binlog，而不是也和事務表一樣緩存在buffer中。 這個參數只影響SBR模式，RBR/MBR不影響。 gtid_mode 用於控制是否啟用GTID。 如果設置成ON，則必須是log_bin，log_slave_updates，enforce_gtid_consistency 也要啟用。 enforce_gtid_consistency 如果開啟了GTID必須把這個參數選項打開。 用於控制只有是事務安全的語句才能被記錄到log中。 gtid_next 5.6.5後出現。 用來表示下一個要執行的事務，設置這個變量需要由SUPER權限。 gtid_purged 用於指定哪個事務從binlog忽悠了，reset master這個值會被清空。 gtid_executed 執行到gtid號及所有執行過gtid號，和executed_gtid_set（show master status,show slave status ）輸出的這列意思是一樣的。 reset master這個值會被清空。

復制相關參數學習筆記--master上的參數