MySQL更新数据流程

Posted 2023-03-30 酷炫lv

1.mysql三种重要日志

redo log（重做日志）：存在于引擎层，物理存储，通过设置innodb_flush_log_at_trx_xommit=1 让其持久化到磁盘，保证引擎的crash-safe能力，遵从WAL技术（Write-Ahead Logging），存放方式为指定大小循环存储，存储时通过写指针（write pos）和擦拭指针（check point）来控制，存放内容为“在某个数据页做了什么操作”，简单来说就是为了保证数据准确，场景：系统崩溃了，可以找回

bin log（归档日志）：存在server层，物理存储，通过设置sync_binlog=1让其持久化到磁盘，与引擎无关，存放方式为叠加，不会覆盖，存储内容包括两部分：存储sql，存储数据前后变动，在数据备份以及回复中，用得多，简单来说是为了备份数据，场景：数据还原，先备份到指定时间点的数据，再根据binlog恢复

undo log（回滚日志）：该日志主要是用于事务执行失败时进行回滚操作，同时也是用于MVCC中对数据的历史版本进行查看

 

2.先贴图

sql：

update test set c = c + 1 where id = 2;

3.执行流程

• 执行器从引擎层查询id=2的数据
• 引擎层先从内存中查询是否存在，如果不存在则从磁盘中加载返回
• 执行器对c字段进行+1后，调用引擎层进行写入
• 引擎层更新内存数据，同时写入redo log，并且设置redo log状态为prepare
• 通知执行器写入bin log ，写入后通知引擎层
• 引擎层提交事务，修改redo log状态为commit

4.疑问

  -> 为什么redo log需要两种状态（两段提交）？

        防止数据存储时，其中写入redo log或者bin log时系统崩溃，导致两端数据不一致，双重确认有利于保存数据一致性。

举个例子：在写入redo log后，还没写入bin log，这个时候系统崩溃重启了，这个时候bin log就会缺少该操作的日志，从而导致数据不一致，两者调换也一样.

MYSQL复制原理及其流程

Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其他主机（slave）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。

3个线程：

首先，slave开始一个工作线程-----I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。binlog dump process 从master的二进制日志中读取事件，如果已经跟上了master，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。

SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。

     此外，在master中也有一个工作线程：和其他Mysql的连接一样，slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制-----复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。 

https://dev.mysql.com/doc/refman/5.6/en/replication-implementation-details.html