mysql与事务、恢复相关的参数解析
1、崩溃恢复相关参数解析：
innodb_fast_shutdown: innodb_fast_shutdown = 0：这个表示在MySQL关闭的时候，执行slow shutdown，不但包括日志的刷盘，数据页的刷盘，还包括数据的清理(purge)，ibuf的合并，buffer pool dump以及lazy table drop操作(如果表上有未完成的操作，即使执行了drop table且返回成功了，表也不一定立刻被删除)。 innodb_fast_shutdown = 1：这个是默认值，表示在MySQL关闭的时候，仅仅把日志和数据刷盘。 innodb_fast_shutdown = 2：这个表示关闭的时候，仅仅日志刷盘，其他什么都不做，就好像MySQL crash了一样。 这个参数值越大，MySQL关闭的速度越快，但是启动速度越慢，相当于把关闭时候需要做的工作挪到了崩溃恢复上。另外，如果MySQL要升级，建议使用第一种方式进行一次干净的shutdown。
innodb_force_recovery: 这个参数主要用来控制InnoDB启动时候做哪些工作，数值越大，做的工作越少，启动也更加容易，但是数据不一致的风险也越大。当MySQL因为某些不可控的原因不能启动时，可以设置这个参数，从1开始逐步递增，知道MySQL启动，然后使用SELECT INTO OUTFILE把数据导出，尽最大的努力减少数据丢失。 innodb_force_recovery = 0：这个是默认的参数，启动的时候会做所有的事情，包括redo日志应用，undo日志回滚，启动后台master和purge线程，ibuf合并。检测到了数据页损坏了，如果是系统表空间的，则会crash，用户表空间的，则打错误日志。 innodb_force_recovery = 1：如果检测到数据页损坏了，不会crash也不会报错(buf_page_io_complete)，启动的时候也不会校验表空间第一个数据页的正确性(fil_check_first_page)，表空间无法访问也继续做崩溃恢复(fil_open_single_table_tablespace、fil_load_single_table_tablespace)，ddl操作不能进行(check_if_supported_inplace_alter)，同时数据库也被不能进行写入操作(row_insert_for_mysql、row_update_for_mysql等)，所有的prepare事务也会被回滚(trx_resurrect_insert、trx_resurrect_update_in_prepared_state)。这个选项还是很常用的，数据页可能是因为磁盘坏了而损坏了，设置为1，能保证数据库正常启动。 innodb_force_recovery = 2：除了设置1之后的操作不会运行，后台的master和purge线程就不会启动了(srv_master_thread、srv_purge_coordinator_thread等)，当你发现数据库因为这两个线程的原因而无法启动时，可以设置。 innodb_force_recovery = 3：除了设置2之后的操作不会运行，undo回滚数据库也不会进行，但是回滚段依然会被扫描，undo链表也依然会被创建(trx_sys_init_at_db_start)。srv_read_only_mode会被打开。 innodb_force_recovery = 4：除了设置3之后的操作不会运行，ibuf的操作也不会运行(ibuf_merge_or_delete_for_page)，表信息统计的线程也不会运行(因为一个坏的索引页会导致数据库崩溃)(info_low、dict_stats_update等)。从这个选项开始，之后的所有选项，都会损坏数据，慎重使用。 innodb_force_recovery = 5：除了设置4之后的操作不会运行，回滚段也不会被扫描(recv_recovery_rollback_active)，undo链表也不会被创建，这个主要用在undo日志被写坏的情况下。 innodb_force_recovery = 6：除了设置5之后的操作不会运行，数据库前滚操作也不会进行，包括解析和应用(recv_recovery_from_checkpoint_start_func)。
2、事务提交相关参数解析：
innodb_flush_log_at_trx_commit：这个参数控制InnoDB 存储引擎事务提交时的redo刷新机制。innodb_flush_log_at_trx_commit = 0：Innodb 中的Log Thread 没隔1 秒钟会将logbuffer中的数据写入到文件，同时还会通知文件系统进行文件同步的flush操作，保证数据确实已经写入到磁盘上面的物理文件。但是，每次事务的结束（commit 或者是rollback）并不会触发LogThread 将log buffer 中的数据写入文件。所以，当设置为0 的时候，当MySQL Crash 和OS Crash或者主机断电之后，最极端的情况是丢失1 秒时间的数据变更。innodb_flush_log_at_trx_commit = 1：这也是Innodb的默认设置。我们每次事务的结束都会触发Log Thread 将log buffer中的数据写入文件并通知文件系统同步文件。这个设置是最安全的设置，能够保证不论是MySQL Crash 还是OS Crash或者是主机断电都不会丢失任何已经提交的数据。innodb_flush_log_at_trx_commit = 2：当我们设置为2 的时候，Log Thread会在我们每次事务结束的时候将数据写入事务日志，但是这里的写入仅仅是调用了文件系统的文件写入操作。而我们的文件系统都是有缓存机制的，所以LogThread的这个写入并不能保证内容真的已经写入到物理磁盘上面完成持久化的动作。文件系统什么时候会将缓存中的这个数据同步到物理磁盘文件LogThread 就完全不知道了。所以，当设置为2 的时候，MySQL Crash 并不会造成数据的丢失，但是OS Crash或者是主机断电后可能丢失的数据量就完全控制在文件系统上了。
binlog_sync:这个参数控制mysql server 事务提交时二进制日志的同步机制。binlog_sync=0:事务提交时，mysql server 不主动同步binlog 到磁盘，由OS 文件系统决定何时同步，当mysql server 或者OS crash时存在binlog 丢失风险。binlog_sync=1:事务每次提交时，mysql server 都将binlog 同步至磁盘，安全性最高，IO 压力最大，mysql 可以通过group commit 机制来改善IO压力。binlog_sync=n(n>1)：每进行n次事务提交时，mysql server 将binlog 同步至磁盘，当mysql server 或者OS crash 时存在binlog 丢失风险。
以上是 mysql与事务、恢复相关的参数解析 的全部内容， 来源链接： utcz.com/z/536128.html
