MySql 笔记 | 主从复制（Replication）配置项简述

Replication 主要配置项（配置文件）

---

1、log_bin：指定binlog文件的名称，同时也表示开启binlog功能，在replication模式下，master上必须开启log_bin，如果slave不需要failover，可以不开启。文件将会放置在“datadir”目录下。

2、binlog_checksum：是否开启binlog校验功能，在5.6.6+之后此值默认为“CRC32”，此前版本默认为“NONE”表示不开启校验和算法；用于控制master将每个变更操作写入binlog时是否携带checksum值，使用checksum可以在replication时，slave用于校验变更操作在网络传输时是否被破坏。

3、binlog_format：可选值“MIXED”、“ROW”、“STATEMENT”，在5.6版本之前默认为“STATEMENT”，5.6之后默认为“MIXED”；因为“STATEMENT”方式在处理一些“不确定”性的方法时会造成数据不一致问题，我们建议使用“MIXED”或者“ROW”。

4、sync_binlog：binlog文件刷新磁盘的时机，默认为“0”，表示binlog刷新磁盘的时机有操作系统决定，“1”表示每个变更操作写入binlog后立即刷新磁盘，这是最安全的方式，在crash时最多丢失一个“group”，当然也是磁盘效率最低的一种；其他任何大于0的数字，表示“多少次”变更操作写入binlog文件后执行flush。此值越大，对磁盘IO消耗越小，当回额外消耗内存，效率越高。

5、binlog_row_image：可选值“full”、“minimal”、“noblob”，默认值为“full”，对“STATEMENT”复制模式无效；每个变更操作发生时，都有2个“image”，“before”表示变更前此行所有列的值，“after”表示变更后此行所有列的值；“full”表示在binlog中将会记录before和after的全部信息，易于排错，但是会导致日志量很大，对磁盘空间和网络传输都有一定的影响；“minimal”只记录before中能够唯一标记此行的列值，比如主键或者唯一索引键，在after中只记录那些有值变更的列；“noblob”类似于full，但是不记录那些没有变更的blob或者text类型的列。

默认值为“full”，因为before和after均写入了binlog，所以通常不会带来问题；如果使用minimal或noblob，我们需要首先确保所有的表都有“主键”或者“唯一索引键”，且slave和master上的表结构完全一致，这样binlog只需要在before中记录能够唯一确定此行的的列即可，否则可能会引入数据不一致的问题。

6、log_slave_updates：默认值为“FALSE”，slave在读取relay log后执行变更操作时，是否也将变更操作再次保存在本地的binlog中，就像变更操作在本地发生一样，开启此特性时也需要同时开启binlog。如果你的slave后端仍有其他slave跟进，需要开启此特性；比如A<-B<-C链状模式，A是B的master，B为C的master，因此A和B需要同时开启binlog和log_slave_updates，否则C将无法正常replication。

7、max_binlog_size：binlog文件的大小，单位“字节”，默认为1G；即当binlog的尺寸大于此值时，将会滚动生成新的binlog文件，但是同一个事务将不会被分割在2个binlog文件中。如果没有设定“max_relay_log_size”配置项，那么此选项也会控制relay log的大小。

8、log_bin_index：binlog索引文件名称，此文件记录当前所有正在使用的binlog文件列表。默认与binlog文件名一样，只是后缀为“<binlog-filename>.index”。

9、expire_logs_days：binlog文件保存的天数，超过指定天数后，binlog历史文件将被删除；默认为“0”表示“不自动删除、永久保存”。通常我们建议不修改此值，即永久保存binlog日志，以备将来一旦数据操作失误时，可以用于恢复。如果磁盘空间有限，可以将binlog备份到其他存储平台，而在本地使用“PURGE BINARY LOGS”指令清除早期的binlog历史文件，释放磁盘空间。

10、master_verify_checksum：master在读取binlog时是否校验，与“binlog_checksum”对应，默认为“false”即关闭。

11、innodb_flush_log_at_trx_commit：innodb表中事务写入binlog后刷新磁盘的时机，配合“sync_binlog”参数使用，默认值为“1”表示每个事务提交后立即刷新binlog文件，是目前最安全的方式。“0”表示缓存事务，每隔1秒钟（innodb_flush_log_at_timeout控制）批量写入binlog并刷新一次磁盘，当crash时这种方式不能100%保证事务全部都写入磁盘，binlog中最多会丢失1秒内的事务。“2”表示事务提交后立即写入binlog文件，每隔一秒钟刷新一次磁盘，它和“1”并没有太大区别，只不过这个方式下操作系统也会影响文件的刷新时机。

12、binlog_order_commits：默认为“true”，事务提交的顺序与写入binlog的顺序保持一致，即在事务提交时会锁定binlog并写入；如果关闭此特性，事务将会并发的提交，那么binlog中事务的顺序有可能与其实际提交的顺序不同，恢复replication带来一定的影响，不过这种方式会提升一定的并发性。

13、server_id：当前mysql实例的id，整个replication中所有的实例的id都不能重复，而且每个server都必须配置此选项，此值是一个数字，integer型。

14、relay_log：relay log的文件名，建议在master和slave上均配置。

15、relay_log_index：relay log索引文件名称。

16、relay_log_info_repository：可选值为“FILE”、“TABLE”，用于保存slave读取relay log的位置信息，以便crash重启后继续恢复；“FILE”表示将信息写入relay-log.info文件，“TABLE”表示将信息写入mysql.slave_relay_log_info表中。

17、master_info_repository：可选值“FILE”、“TABLE”，将master的状态和链接信息保存何处，FILE则表示保存在master.info文件中，TABLE表示保存在mysql.slave_master_info表中。

18、slave_net_timeout：slave与master链接IO超时的时间，超时后将会中断read，默认为3600。

19、slave_parallel_workers：设置执行replication的worker线程的数量，默认为0，表示关闭多线程，此时slave只有一个SQL线程。如果开启多线程，slave中的SQL线程将作为worker线程池的“协调器”，SQL线程从relay log中读取变更操作记录，并以database为分离标准将操作分发给相应的workers线程，每个worker线程在一端时间内将持续执行一个database的变更操作，简单而言，就是不同的worker线程执行不同database的操作，多个database数据将在slave上被并行的执行，为了能够正确的工作，事务不能跨多个databases。

此值用于控制worker线程的个数，“协调器”线程不包含在内，我们在slave上通过“SHOW PROCESSLIST”指令可以查看到SQL线程、worker线程的数据和状态。

开启多线程时，并发执行会导致，在slaves上不同的databases被执行的时机可能与master上不同，归因于线程上线文的切换和CPU资源分配的不确定性；即一个事务执行后，不能保证此事务之前的其他事务（其他databases）也已经执行成功，这或许会对slave上binlog的记录、数据恢复和客户端数据访问带来影响。建议线程数为“database个数”，每个database一个worker线程；也有很多DBA将此值设置为2，即只用一个worker线程，这就不会带来事务顺序与master不一致的问题；需要强调的是，无论多少个线程，单个database的事务总是在一个worker中执行，单个database的事务顺序总是正确的。

20、slave_pending_jobs_size_max：仅对多线程有效，SQL线程将变更操作读取后分发给worker线程，每个worker线程以队列的方式缓存亟待执行的变更操作记录，此处用于控制队列的大小，默认为16M，单位为“字节”；此值不得大于“max_allowed_packet”。

21、slave_sql_verify_checksum：slave中SQL线程是否使用校验和检测relay log中的变更操作，与“binlog_checksum”配合，默认为“1”表示开启。

22、slave_transaction_retries：如果SQL线程在执行事务时发生InnoDB死锁且等待超时后，slave重试的次数，默认为10，如果超过此次数，slave将会抛出error且终止replication；此值在“slave_parallel_workers”开启时无效，即为0，不重试。

23、sync_relay_log：slave将多少条变更操作写入relay log后刷新磁盘文件，默认为10000；“0”表示刷新时机有操作系统决定，“1”表示每写入一条变更操作即立即刷新，是最安全的方式，不过因为relay log的安全级别与binlog还是要低一些，建议保持默认值，这通常也不会带来问题。

24、gtid_mode：是否开启GTID特性，可选值为“ON”、“OFF”；在replication模式下我们应该开启。
　　
25、enforce_gtid_consistency：如果gtid_mode=ON，此值必须开启，可选值为“ON”、“OFF”，表示是否强制gtid的“一致性”避免并发操作。
　　
26、binlog_ignore_db：binlog中忽略的db，master与slave均可以配置，通常在master端。如果需要ignore多个databases，此配置允许声明多次，每次指定一个db。
　　
27、binlog_do_db：指定可以写入binlog的database名字，与binlog_ignore_db相反，只有指定的db才会写入binlog。此配置允许声明多次，每次指定一个db。（上述两个如果在slave上配置，可能还需要开启“log_slave_updates”，默认情况下，slaves端是不写binlog的）
　　
28、replicate_do_db：同上，只是在slave端生效，slave中的SQL线程在读取relay log时，会检测此变更操作所属DB，SQL线程只会执行此配置参数指定的db。如果不声明replicate_do_db，表示所有的db都会执行。此配置允许声明多次，每次指定一个db。与此配置项对应的还有“replicate_ignore_db=<db>”、“replicate_db_table=<db>.<table>”、“replicate_ignore_table=<db>.<table>”。
　　
29、read_only：当前实例是否为“只读”模式，在此模式下除了具有“SUPER”权限的用户外，其他权限用户均不可以修改数据。SUPER权限包括（举例）：CHANGE MASTER TO、KILL、SET GLOABL等。通常slave上，需要设定read_only=1以避免客户端意外修改数据，而造成数据错乱问题。默认为“0”（OFF）表示关闭。read_only并不会影响replication进程对数据的变更。
　　
30、super_read_only：对于具有SUPER权限的用户，是否也只读，默认为“0”（OFF）表示关闭。super_read_onl开启时，也会隐式的开启“read_only”参数。
　　
31、slave_preserve_commit_order：对于多线程slaves，来保障事务在slave上执行的顺序与relay log中的顺序严格一致，只有当“slave_parallel_workers”开启时有效；此时“log_bin”、“log_slave_updates”必须开启，而且“slave_parallel_type”值必须为“LOGICAL_CLOCK”（默认值为DATABASE）。即当多线程开启时，且根据relay log中事务的逻辑顺序执行statements，是否需要严格保持顺序，默认值为0表示并发执行忽略顺序。
　　
slave_parallel_type默认为DATABASE，原理参见18，能够确保每个DATABASE中的事务顺序严格一致，但是无法保证所有databases的事务执行顺序也是严格一致的（gap），比如两个事务依次操作了2个DB：A和B，尽管事务A、B分别被worker X、Y线程接收，但是因为线程调度的问题，有可能导致A的执行时机落后于B。
　　
如果你的事务经常是“跨DB”操作，那么可以考虑使用此参数限定顺序。当此参数开启时，这要求任何worker线程执行的事务时，只有当前事务中此之前的所有事务都执行后（被其他worker线程执行），才能执行和提交。（每个事务中，都记录了当前GTID的privious GTID，只有privious GTID被提交后，当前GTID事务才能提交）