mysql主从参数_mysql 主从参数解释

redo log 刷盘机制

当提交事务是，可通过参数innodb_flush_log_at_trx_commit 来控制redolog写入机制，参数不同，产生的行为不同，主要参数如下：

1，inno_flush_log_at_trx_commit=0：当食物提交时mysql不会去处理日志樊村去的内容，也不会去处理日志文件的刷盘操作，有mysql的后台master县城每个1s将樊村去的文件刷新到日志文件中。

2，innodb_flush_log_at_trx_commit=1:事务提交时，会将日志反冲去的日志写入到文件同事会刷新到磁盘，保证数据库事务完全不会丢失，这种设置影响数据库性能最大。

3，innodb_flush_log_at_trx_commit=2：事务提交时会将日志缓存区的日志写入到文件中，是不会刷新到磁盘中。有mysql的后台master县城每个1s将系统樊村的日志文件刷新到磁盘中。

宕机与innodb_flush_log_at_trx_commit 参数的关系：

一般宕机有两种情况：

数据宕机系统正常运行

数据库所在的服务器宕机

1，在数据库宕机，服务器正常运行

inno_flush_log_at_trx_commit=0 由于事务提交时，不刷新日志缓存区，及时事务已经提交，缓存区的日志也会全部丢失，所以最新的数据修改也会丢失，master线程是每个仪表刷新一次，所以一般会丢失最近1s的事务。

inno_flush_log_at_trx_commit=1时 如果数据库宕机，由于每次事务提交都会刷新日志，系统成长日志已经保存到磁盘，数据不会丢失。

inno_flush_log_at_trx_commit=2时 如果数据宕机由于事务已经刷新到了系统缓存中，数据库服务器正常运行，数据也不会丢失。

2，数据库所在服务器宕机

inno_flush_log_at_trx_commit=0 由于事务提交时，不刷新日志缓存区，及时事务已经提交成功，反冲去的日志也会全部丢失，所以最新修改也都会丢失，master县城美标刷新一次，所以一般丢失最近1s的事务。

inno_flush_log_at_trx_commit=1时，由于，每次事务提交都会刷新到磁盘文件中，所以即使服务器宕机，数据也不会有任何丢失。

inno_flush_log_at_trx_commit=2时，事务是指刷新到系统缓存中，如果服务器系统出现问题，导致宕机，那么日志就没有刷新到磁盘，就会丢失最近1s的事务。

mysql集群安全参数：

sync_binlog:

binlog是用于保存数据库修改的日志信息。传统的主从复制是基于binlog的，binlog的安全直接关系到复制的安全，而binlog的谢日方式主要有参数sync_binlog来控制，参数值决定了其行为方式。

sync_binlog=0 事务提交时，mysql将binlog信息写入binlog文件中，danshimysql不控制binlog的刷新磁盘操作，有文件系统控制其缓存的刷新，一旦操作系统宕机，在binlog cache中的所有binlog都会丢失，如果只是数据库宕机，而操作系统没有宕机，那么数据库所生成的binlog都不会丢失。

sync_binlog=1 每个事务提交时，mysql都会把binlog刷新到磁盘中。这样，数据库安全性提高，但是性能损耗比较严重。如果这样设置，在数据库或操作系统宕机的情况下，二进制日志缺少的任何事务也会处于准备阶段，那么导致服务器自动回复时，会回滚这些事务，或保证无数据丢失，索然binlog是顺序io，但是多个事务同事提交，同样会对mysql和io的性能带来很大影响，不过mysql可以通过group commit来缓解压力。

sync_binlog=n (n>1)：表示没n次事务提交，mysql调用文件系统的刷新操作将缓存到磁盘中，如果数据库或者操作系统宕机，数据库可能会丢失一部分事务。(在mysql5.7版本中由于添加了多线程复制，在写binlog方面做出了相应调整)

innodb_support_xa参数：

默认情况下innodb_support_xa是开启的，如果将参数关闭，事务提交可以以不同的顺序写入binlog，如果宕机恢复或者从库应用这些binlog，就会导致数据的不同，这是非常不安全的，建议在线上环境或主库中开启。(不过该参数在5.7.10版本中已经废弃)

主从复制参数的影响

在replication的配置中，有一些参数会影响主从复制的行为，这些行为的配置会影响复制的数据一致性问题，进而影响到集群的数据安全。

binlog_format

binlog_format主要为三种格式：statement(语句级)、row(行模式)和mixed(混合模式)。

statement：master写入执行的sql语句到binlog中，从库读取这些sql语句并且执行，这种基于语句的复制是mysql最早支持的形式。优势：技术成熟、减少binlog的写入量、binlog包含了所有修改的语句便于审计，缺点：基于语句级复制并不安全，有些函数不能正确的在slave上复制、与基于row格式的复制相比，insert....select需要更多的锁，性能不佳、隔离级别必须为repeatable-read，这也是发生死锁的主要原因。

mixed：可以将master的binlog_format配置成同事使用基于statement和row两者的组合格式，它记录日志取决于修改的类型，选择最适合的格式来记录该修改，默认情况下，使用statement格式记录日志，在特定的情况下转换为基于row格式记录。

row：mysql 5.7.7版本后，把binlog_format的 默认值修改为了row。master将修改表event写入binlog中，并且master将该binlog信息发送到slave，slave重放binlog中event。基于row格式复制是最安全的复制，slave需要的行锁也更少。但是也有缺点，继续row格式的复制binlog日志会记录更多的数据，并且无法再slave上看到master上获取的语句，因为都是event，但是在row格式下，可以开启binlog_row_query_log_events参数，这会让binlog在记录events的同事，也记录下原始的sql语句，以方便后去的查询或审计。在复制过程中建议使用row格式的模式，其他模式可能会导致处从数据不一致的情况。

master_info_repository与sync_master_info:

其中，master_info_repository有两个值，分别是file和table，改参数决定了slave记录master的状态，如果参数值是file，就会创建master.info文件，如果参数时table就会在mysql库中简历slave_master_info的表。其中，sync_master_info参数决定slave刷新master状态的方式。并且master_info_repository 的参数不同刷新方式也不同。

如果master_info_repository=file,sync_master_info=n(n>0),那么slave就会在n格式件后使用fdatasysnc()方式同步master信息状态到master.info文件中。如果sync_master_info=n(n=0)，那么mysql只会讲状态信息写入操作系统缓存中，需要等待操作系统同步。

如果master_info_repository=table,sync_master_info=n(n>0)，那么slave就会在没n个时间后，更新mysql.slave_master_info表，如果n=0，那么mysql.slave_master_info表将永远不会更新。