Day.14 Crash Recovery- InnoDB 架构 -> MYSQL 二阶段提交(2PC) _2

有关於实际业务上对於数据要求的重要性，以下参数设定的写入策略搭配会对性能与安全度产生不同的影响。

相关参数内容:

innodb_flush_log_at_trx_commit

• 控制日志缓冲区内容如何写入和刷新到磁盘策略参数: innodb_flush_log_at_trx_commit (选项: 0,1,2)

看一下大致流程，才会懂下面提到的参数设置意义喔！！

(内存中的日志缓冲)                                        (磁盘上)        
redo log buffer -写入-> OS cache  --呼叫fsync()刷盘--> redo log file 

ps. 呼叫fsync()操作指的是将OS buffer中的日志刷到磁碟上的redo log file中数据持久化。

设 0 - 每隔1秒才将日志缓存区中的日志写入到os cache并呼叫fsync()刷新到磁盘上的redo log file。

(虽然效率高但资料安全性低，因为1秒的数据有可能因为mysql崩溃而丢失)

设 1 - 每次事务提交时都会将日志缓存区中的日志写入os cache并呼叫fsync()刷新到磁盘上的redo log file。

(资料安全性高，因为只要提交就会更新磁盘资料所以不会有丢失的状况，不过因为每次提交都刷新磁盘所以效能相对最差)

设 2 - 每次事务提交时把日志缓存区的日志写入os cache，不会同时刷新到磁盘上，而是每秒呼叫fsync()刷到磁盘上的redo log file。

(比设为0安全每秒执行刷新到磁盘，在操作系统崩溃or系统断电的状况下才可能发生那一秒的数据丢失)

sync_binlog

• 控制MySQL服务器将binlog同步到磁盘的频率: sync_binlog (选项: 0,1,N个)

写入流程如下，先了解才会懂下面提到的参数设置意义喔！！

                                         事务提交(commit)
事务执行中(尚未commit) -写入-> binlog cache -----写入-----> os cache -呼叫fsync()刷盘--> binlog

设 0: 在事务提交时不会将二进制日志同步到磁盘。(等於不会fsync()刷盘)

设 1: 在事务提交时会将二进制日志同步到磁盘。(最安全的设置，且保证没有事务从二进制日志中丢失)

设 N(>1): 当提交的日志组到达设定值N时，会将二进制日志同步到磁盘。

• 如何去取舍两者参数之间的搭配有关於:

  • 对数据安全性要求(高低)
  • 磁盘写入能力(好坏)
  • 主从延迟落後问题

下集预告: 了解完以上内容後明天就正式讲解二阶段提交流程罗！