MySQL 复制参数详解

log-bin　　二进制日志

server-id 早起版本必须添加  1-pow(2,32)-1 推荐使用 端口号+ip最后一位  5.6后可以动态修改

server-uuid （5.6以后） 默认存在 $datadir/auto.cnf 下         5.6后可以动态修改

log-bin-index  包含二进制日志文件名

binlog-format  statement row mixed 三种  可动态修改

binlog_cache_size=1M - 2M

max_binlog_size 默认是1G  生成间隔在2分钟以上 推荐128M 或者256M

限制单个binlog大小 可以动态修改

sync_binlog=n

binlog在同步完之后,commit以后是否要刷到磁盘上 默认更高的性能设置成0 由操作系统控制是否刷到磁盘上

如果是教育系统,为了安全推荐设置成1

多少个SQL之后,调用fdatasync()函数刷新 binlog 到disk

fsync() / fdatasync() 区别是什么

fsync() 是完全刷新到磁盘,fdatasync 只刷新数据 不刷新metadata 可动态修改

expire_logs_days=n  推荐保存7天

n天后自动删除binlog

可动态修改

log_bin_trust_function_creators

开启binlog时,是否允许创建存储程序(除非有super权限,或指定deterministic,reads sql data,nosql)

可以动态修改

log_warnings

如果这个值设置大于 1，会在错误日志里看到异常断开的连接(Aborted connection)或者是被拒绝的请求

特殊说明

MySQL5.6.5，MySQL5.7.5以后,binlogv2 格式 gtid binlog_checksum

MySQL5.5 ——> MySQL5.6 没问题

如果以后有  MySQL5.6 --------> MySQL5.5 同步的需求    发现同步不了报错,

需要找到两个参数

binlog_checksum  默认为CRC32  由于5.5没有此参数所以需要设置为 none

log_bin_use_v1_row_events  默认为OFF 设置为 ON

这样可以避免升级过程中的一些问题(之后建议将参数还原回原来的设置)

binlog_error_action 当不能写binlog时,可以报出来错,默认没开启：ignore_error

开启可以使用 :abort_server

5.6引入 gtid

bin_log_image   三种模式 full  minimal  noblob 默认为full

binlog_rows_query_log_events 审计功能

基于MySQL5.6 GTID的Crash Recovery是有Mysql-5.6.21 支持到 5.6.23 稳定

传统复制里面也是可以支持

master_info_repository  |file|   修改为 table

relay_log_info_repository |file|   修改为table

binlog_gtid_recovery_simpliefied  【5.6.23--5.6.21 simplified_binlog_gtid_recovery 】 这个功能刚出来不久

在挂掉时,可以找到自己同步到那里 完成的同步GTID 上接着同步,重新拉一下日志

如果没启用这个特性,会从binlog 全部搜索一下,如果日志很多,需要占用的时间比较多

relay-master-log-file

exec-master-log-pos

master 其他参数

auto_increment_increment  偏移量

auto_increment_offset　　 初始值

特别声明:所有的过滤规则都不建议在主库设置

binlog-do-db

binlog记录db,除此外，其他db上的binlog都不记录，存在风险

binlog-ignore-db

和上面规则相反

max_binlog_cache_size

binlog最大的cachesize 有大SQL写入时需要用到，或者大数据Load DATA 时

binlog_stmt_cache_size

用于cache那些事物中非事物表产生的SQL语句。如果经常在事物中涉及到非事物表,需要加大该参数

max_binlog_stmt_cache_size

用于cache那些事物中非事务表产生的SQL语句 最大cache

binlog_direct_non_transactional_updates

事物中既有事务表,也有非事务表的情况下，发生数据变更时,非事物表会直接写binlog,而不是也和事务表一样在buffer中

这个参数只影响SBR 模式 RBR MBR 都不影响

gtid相关参数

gtid_mode  on 开启gitd 的参数

enforce_gtid_consistency

gtid_next 跳过错误的参数

gtid_purged

用于指定那个事务从 binlog忽略了 ,reset master 这个值会被清空

gtid_executed 执行到的gtid 号及 所有执行过的 gtid 号

和executed_gtid_set（show master status,show slave status）输出的这列意思是一样的

reset master 这个值会被清空

总结:

主库开启最少参数(必须参数)

server-id

server-uuid

log-bin

gtid-mode

enforce-gtid-consistency

其他参数

max_binlog_size

expire_logs_days

binlog_format  （row格式）

salve 上的参数

server-id

server-uuid

relay-log  io thread 读取过来存到本地的日志

relay-log-index

read-only  设置从库为只读 但是对super权限不起作用

配置参数 (ignore/do 规则)

server-id

relay-log

relaylog 文件名前缀 可以是全路径

不可动态修改

relay-log-index

relay-log索引文件前缀名 和 relay-log一样 也可以是fullpath

不可以动态修改

read-only

除非有super权限 否则无法修改数据,不过不影响自主创建临时表（temporary,table）analyze table optimize table 也不受影响

可以动态修改

slave其他参数

log-slow-slave-statements  slave复制产生的slow log 是否也要记录

log-slave-updates   将master传输过来的变更操作,再次记录成本地的binlog,用于二次复制,当作中继分发点　　　　　　　　

max_relay_log_size 建议不用修改  限制relay log的大小

relay-log-info-file

relay-log-purge =1 应用完后删除 应用完了 是否立即删除

relay-log-recovery = 1 crash recover 的过程  slave崩溃或正常重启时,未应用完的relay log会被删掉,重新从master 请求binlog  再次生成relay log

replicate-same-server-id

skip-slave-start  在数据库起来后不要自动启用同步

slave_load_tmpdir

slave_transaction_retries

start_parallel_workers 默认是关闭的 5.6引入基于gtid库级别的并行赋值

master-info-file/relay-log-info-file  将来慢慢替换成 下面两个

master_info_repository   file    -->  table

relay_log_info_repository  file  ---> table

记录relay-log 最新信息

sync_master_info =n   保持默认

多少个事物/事件后调用fdatasync() 刷新master.info 文件

relay_log_purge relay

slave 的过滤参数

replicate-do-table

replicate-ignore-table

replicate-rewrite-db    把db1 的操作改到 db2 中

replicate-wild-do-table   通配符的方式制定哪些表被复制哪些表不被复制

replicate-wild-ignore-table

replicate-do-db

replicate-ignore-db

slave_net_timeout

slave_skip_errors

sql_slave_skip_counter

、过滤条件可以在线更改 5.7.3以后

slave_net_timeout  如果主从复制 线程都为yes 但是数据过不来 建议调到 20 -30  默认为60

slave_skip_errors

复制过程中忽略某些错误

1032  找不到记录

1053 指server是在关闭过程中

1062  重复主键

1050  表已经存在了

1051 表找不到

1054 列对不上

1146  表不存在

sql_slave_skip_counter

忽略多少个复制事件，遇到个别错误(主键冲突,记录不存在等等) 时,可以忽略这些事件 继续复制过程

基于binlog+position 错误处理

stop slave

set global sql_slave_skip_counter=n

start slave

show slave status\G;

一搬一次 只忽略一个事件,除非很肯定,否则不要设置大于1

其中  为了使用crash-safe-replication 功能,必须使用

relay-log-info-repository =table

relay-log-recovery

使用支持事务的引擎

使用crash-safe replication 功能：在mysql(slave) 故障挂起来后

在设置了relay-log-recovery=1 时 会清理掉已经存在的relay log 从 relay-log-info-repository 里读到的

同步位置,重新请求一份relay-log 实际上是做了一次：把read_master_log_pos 设置为Exec_mater_log_pos ,

master_log_file 设置成了 relay_master_log_file

note:在slave 上如果给指定了一个日志的不正确的binlog position start slave 是什么也不干的