怎么做自己的网站卖东西,陇西 网站开发,做网站项目需求分析是什么,网站开发培训心得日志
1、为什么需要 undo log#xff1f;
#xff08;1#xff09;实现事务回滚#xff0c;保障事务的原子性。 事务处理过程中#xff0c;如果出现了错误或者用户执 行了 ROLLBACK 语句#xff0c;MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态…
日志
1、为什么需要 undo log
1实现事务回滚保障事务的原子性。 事务处理过程中如果出现了错误或者用户执 行了 ROLLBACK 语句MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
undo log 是一种用于撤销回退的日志。在事务没提交之前MySQL 会先记录更新前的数据到 undo log 日志文件里面当事务回滚时可以利用 undo log 来进行回滚。
在插入一条记录时要把这条记录的主键值记下来这样之后回滚时只需要把这个主键值对应的记录删掉就好了
在删除一条记录时要把这条记录中的内容都记下来这样之后回滚时再把由这些内容组成的记录插入到表中就好了
在更新一条记录时要把被更新的列的旧值记下来这样之后回滚时再把这些列更新为旧值就好了。2实现 MVCC多版本并发控制关键因素之一。 MVCC 是通过 ReadView undo log 实现的。undo log 为每条记录保存多份历史数据MySQL 在执行快照读普通 select 语句的时候会根据事务的 Read View 里的信息顺着 undo log 的版本链找到满足其可见性的记录。
2、为什么需要 Buffer Pool
MySQL 的数据都是存在磁盘中的那么我们要更新一条记录的时候得先要从磁盘读取该记录然后在内存中修改这条记录。那修改完这条记录是选择直接写回到磁盘还是选择缓存起来呢
当然是缓存起来好这样下次有查询语句命中了这条记录直接读取缓存中的记录就不需要从磁盘获取数据了。
为此Innodb 存储引擎设计了一个缓冲池Buffer Pool来提高数据库的读写性能。
当读取数据时如果数据存在于 Buffer Pool 中客户端就会直接读取 Buffer Pool 中的数据否则再去磁盘中读取。
当修改数据时如果数据存在于 Buffer Pool 中那直接修改 Buffer Pool 中数据所在的页然后将其页设置为脏页该页的内存数据和磁盘上的数据已经不一致为了减少磁盘I/O不会立即将脏页写入磁盘后续由后台线程选择一个合适的时机将脏页写入到磁盘。3、Buffer Pool 缓存什么
1数据页 2索引页 3插入缓存页 4undo页 5自适应哈希索引 6锁信息 开启事务后InnoDB 层更新记录前首先要记录相应的 undo log如果是更新操作需要把被更新的列的旧值记下来也就是要生成一条 undo logundo log 会写入 Buffer Pool 中的 Undo 页面。 4、为什么需要 redo log
1实现事务的持久性让 MySQL 有 crash-safe 的能力 保证 MySQL 在任何时间段突然崩溃重启后之前已提交的记录都不会丢失
Buffer Pool 是提高了读写效率没错但是问题来了Buffer Pool 是基于内存的而内存总是不可靠万一断电重启还没来得及落盘的脏页数据就会丢失。
为了防止断电导致数据丢失的问题当有一条记录需要更新的时候InnoDB 引擎就会先更新内存同时标记为脏页然后将本次对这个页的修改以 redo log 的形式记录下来这个时候更新就算完成了。
后续InnoDB 引擎会在适当的时候由后台线程将缓存在 Buffer Pool 的脏页刷新到磁盘里这就是 WAL Write-Ahead Logging技术 WAL 技术指的是 MySQL 的写操作并不是立刻写到磁盘上而是先写日志然后在合适的时间再写到磁盘上。 2将写操作从「随机写」变成了「顺序写」提升 MySQL 写入磁盘的性能。
我们思考一个问题redo log 要写到磁盘数据也要写磁盘为什么要多此一举
写入 redo log 的方式使用了追加操作 所以磁盘操作是顺序写而写入数据需要先找到写入位置然后才写到磁盘所以磁盘操作是随机写。
磁盘的「顺序写 」比「随机写」 高效的多因此 redo log 写入磁盘的开销更小。
5、什么是 redo log
redo log 是物理日志记录了某个数据页做了什么修改比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新每当执行一个事务就会产生这样的一条或者多条物理日志。
在事务提交时只要先将 redo log 持久化到磁盘即可可以不需要等到将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。
当系统崩溃时虽然脏页数据没有持久化但是 redo log 已经持久化接着 MySQL 重启后可以根据 redo log 的内容将所有数据恢复到最新的状态。
6、产生的 redo log 是直接写入磁盘的吗
实际上 执行一个事务的过程中产生的 redo log 也不是直接写入磁盘的因为这样会产生大量的 I/O 操作而且磁盘的运行速度远慢于内存。
所以redo log 也有自己的缓存—— redo log buffer每当产生一条 redo log 时会先写入到 redo log buffer后续在持久化到磁盘。 redo log buffer 默认大小 16 MB可以通过 innodb_log_Buffer_size 参数动态的调整大小增大它的大小可以让 MySQL 处理「大事务」是不必写入磁盘进而提升写 IO 性能。 7、redo log 什么时候刷盘
1MySQL 正常关闭时 2当 redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半时会触发落盘 3InnoDB 的后台线程每隔 1 秒将 redo log buffer 持久化到磁盘。 4每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘这个策略可由 innodb_flush_log_at_trx_commit 参数控制
innodb_flush_log_at_trx_commit 参数
01.当设置该参数为 0 时表示每次事务提交时 还是将 redo log 留在 redo log buffer 中 该模式下在事务提交时不会主动触发写入磁盘的操作。
02.当设置该参数为 1 时表示每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘这样可以保证 MySQL 异常重启之后数据不会丢失。
03.当设置该参数为 2 时表示每次事务提交时都只是缓存在 redo log buffer 里的 redo log 写到 redo log 文件注意写入到「 redo log 文件」并不意味着写入到了磁盘因为操作系统的文件系统中有个 Page CachePage Cache 是专门用来缓存文件数据的所以写入「 redo log文件」意味着写入到了操作系统的文件缓存。
innodb_flush_log_at_trx_commit 为 0 和 2 的时候InnoDB 的后台线程每隔 1 秒落盘一次redo log8、redo log 文件写满了怎么办
默认情况下 InnoDB 存储引擎有 1 个重做日志文件组( redo log Group「重做日志文件组」由有 2 个 redo log 文件组成这两个 redo 日志的文件名叫 ib_logfile0 和 ib_logfile1 。
在重做日志组中每个 redo log File 的大小是固定且一致的假设每个 redo log File 设置的上限是 1 GB那么总共就可以记录 2GB 的操作。
重做日志文件组是以循环写的方式工作的从头开始写写到末尾就又回到开头相当于一个环形。
所以 InnoDB 存储引擎会先写 ib_logfile0 文件当 ib_logfile0 文件被写满的时候会切换至 ib_logfile1 文件当 ib_logfile1 文件也被写满时会切换回 ib_logfile0 文件。
redo log 是循环写的方式相当于一个环形InnoDB 用 write pos 表示 redo log 当前记录写到的位置用 checkpoint 表示当前要擦除的位置 如果 write pos 追上了 checkpoint就意味着 redo log 文件满了这时 MySQL 不能再执行新的更新操作也就是说 MySQL 会被阻塞因此所以针对并发量大的系统适当设置 redo log 的文件大小非常重要此时会停下来将 Buffer Pool 中的脏页刷新到磁盘中然后标记 redo log 哪些记录可以被擦除接着对旧的 redo log 记录进行擦除等擦除完旧记录腾出了空间checkpoint 就会往后移动图中顺时针然后 MySQL 恢复正常运行继续执行新的更新操作。
9、redo log和 binlog的区别
1适用对象不同
binlog 是 MySQL 的 Server 层实现的日志所有存储引擎都可以使用
redo log 是 Innodb 存储引擎实现的日志2文件格式不同
binlog 有 3 种格式类型分别是 STATEMENT默认格式、ROW、 MIXEDSTATEMENT每一条修改数据的 SQL 都会被记录到 binlog 中主从复制中 slave 端再根据 SQL 语句重现。但 STATEMENT 有动态函数的问题比如你用了 uuid 或者 now 这些函数你在主库上执行的结果并不是你在从库执行的结果这种随时在变的函数会导致复制的数据不一致
ROW记录行数据最终被修改成什么样了这种格式的日志就不能称为逻辑日志了不会出现 STATEMENT 下动态函数的问题。但 ROW 的缺点是每行数据的变化结果都会被记录比如执行批量 update 语句更新多少行数据就会产生多少条记录使 binlog 文件过大而在 STATEMENT 格式下只会记录一个 update 语句而已
MIXED包含了 STATEMENT 和 ROW 模式它会根据不同的情况自动使用 ROW 模式和 STATEMENT 模式
redo log是物理日志记录的是在某个数据页做了什么修改比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新3写入方式不同
binlog 是追加写写满一个文件就创建一个新的文件继续写不会覆盖以前的日志保存的是全量的日志。
redo log 是循环写日志空间大小是固定全部写满就从头开始保存未被刷入磁盘的脏页日志。4用途不同
binlog 用于备份恢复、主从复制
redo log 用于掉电等故障恢复。10、如果不小心整个数据库的数据被删除了能使用 redo log 文件恢复数据吗
不可以使用 redo log 文件恢复只能使用 binlog 文件恢复。
因为 redo log 文件是循环写是会边写边擦除日志的只记录未被刷入磁盘的数据的物理日志已经刷入磁盘的数据都会从 redo log 文件里擦除。
binlog 文件保存的是全量的日志也就是保存了所有数据变更的情况理论上只要记录在 binlog 上的数据都可以恢复所以如果不小心整个数据库的数据被删除了得用 binlog 文件恢复数据。
11、主从复制的流程是怎么样的 1MySQL 主库在收到客户端提交事务的请求之后会先写入 binlog再提交事务更新存储引擎中的数据事务提交完成后返回给客户端“操作成功”的响应。 2从库会创建一个专门的 I/O 线程连接主库的 log dump 线程来接收主库的 binlog 日志再把 binlog 信息写入 relay log 的中继日志里再返回给主库“复制成功”的响应。 3从库会创建一个用于回放 binlog 的线程去读 relay log 中继日志然后回放 binlog 更新存储引擎中的数据最终实现主从的数据一致性。 12、从库是不是越多越好
不是的。 因为从库数量增加从库连接上来的 I/O 线程也比较多主库也要创建同样多的 log dump 线程来处理复制的请求对主库资源消耗比较高同时还受限于主库的网络带宽。 13、MySQL 主从复制还有哪些模型 1同步复制MySQL 主库提交事务的线程要等待所有从库的复制成功响应才返回客户端结果。这种方式在实际项目中基本上没法用原因有两个一是性能很差因为要复制到所有节点才返回响应二是可用性也很差主库和所有从库任何一个数据库出问题都会影响业务。 2异步复制默认模型MySQL 主库提交事务的线程并不会等待 binlog 同步到各从库就返回客户端结果。这种模式一旦主库宕机数据就会发生丢失。 3半同步复制MySQL 5.7 版本之后增加的一种复制方式介于两者之间事务线程不用等待所有的从库复制成功响应只要一部分复制成功响应回来就行比如一主二从的集群只要数据成功复制到任意一个从库上主库的事务线程就可以返回给客户端。这种半同步复制的方式兼顾了异步复制和同步复制的优点即使出现主库宕机至少还有一个从库有最新的数据不存在数据丢失的风险。 14、binlog 什么时候刷盘
binlog写入流程事务执行过程中先把日志写到 binlog cacheServer 层的 cache事务提交的时候再把 binlog cache 写到 binlog 文件中并清空 binlog cache。最后由配置决定binlog文件什么时候落到磁盘上。 一个事务的 binlog 是不能被拆开的因此无论这个事务有多大比如有很多条语句也要保证一次性写入。这是因为有一个线程只能同时有一个事务在执行的设定所以每当执行一个 begin/start transaction 的时候就会默认提交上一个事务这样如果一个事务的 binlog 被拆开的时候在备库执行就会被当做多个事务分段自行这样破坏了原子性是有问题的。 MySQL 给每个线程分配了一片内存用于缓冲 binlog 该内存叫 binlog cache参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小就要暂存到磁盘。 虽然每个线程有自己 binlog cache但是最终都写到同一个 binlog 文件 图中的 write指的就是指把日志写入到 binlog 文件但是并没有把数据持久化到磁盘因为数据还缓存在文件系统的 page cache 里write 的写入速度还是比较快的因为不涉及磁盘 I/O。
图中的 fsync才是将数据持久化到磁盘的操作这里就会涉及磁盘 I/O所以频繁的 fsync 会导致磁盘的 I/O 升高。
MySQL提供一个 sync_binlog 参数来控制数据库的 binlog 刷到磁盘上的频率 01.sync_binlog 0 的时候表示每次提交事务都只 write不 fsync后续交由操作系统决定何时将数据持久化到磁盘 02.sync_binlog 1 的时候表示每次提交事务都会 write然后马上执行 fsync 03.sync_binlog N(N1) 的时候表示每次提交事务都 write但累积 N 个事务后才 fsync。 15、一条Update语句的完整过程 1执行器负责具体执行会调用存储引擎的接口通过主键索引树搜索获取 id 1 这一行记录在 buffer pool 中就直接返回给执行器更新不在 buffer pool将数据页从磁盘读入到 buffer pool返回记录给执行器 2执行器得到聚簇索引记录后会看一下更新前的记录和更新后的记录是否一样一样就无需走后续流程不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层让 InnoDB 真正的执行更新记录的操作 3开启事务 InnoDB 层更新记录前首先要记录相应的 undo log因为这是更新操作需要把被更新的列的旧值记下来也就是要生成一条 undo logundo log 会写入 Buffer Pool 中的 Undo 页面不过在内存修改该 Undo 页面后需要记录对应的 redo log。 4InnoDB 层开始更新记录会先更新内存同时标记为脏页然后将记录写到 redo log 里面这个时候更新就算完成了。为了减少磁盘I/O不会立即将脏页写入磁盘后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术MySQL 的写操作并不是立刻写到磁盘上而是先写 redo 日志然后在合适的时间再将修改的行数据写到磁盘上。 5至此一条记录更新完了。 6在一条更新语句执行完成后然后开始记录该语句对应的 binlog此时记录的 binlog 会被保存到 binlog cache并没有刷新到硬盘上的 binlog 文件在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。 7事务提交剩下的就是「两阶段提交」的事情了 16、为什么需要两阶段提交
事务提交后redo log 和 binlog 都要持久化到磁盘但是这两个是独立的逻辑可能出现半成功的状态这样就造成两份日志之间的逻辑不一致。 1如果在将 redo log 刷入到磁盘之后 MySQL 突然宕机了而 binlog 还没有来得及写入。在主从架构中binlog 会被复制到从库由于 binlog 丢失了某些更新语句会导致主从数据不一致。 2如果在将 binlog 刷入到磁盘之后 MySQL 突然宕机了而 redo log 还没有来得及写入。由于 redo log 还没写崩溃恢复以后这个事务无效主库中可能丢失某些更新语句binlog 会被复制到从库从库执行了这些更新语句也会导致主从数据不一致。 MySQL 为了避免出现两份日志之间的逻辑不一致的问题使用了「两阶段提交」来解决两阶段提交其实是分布式事务一致性协议它可以保证多个逻辑操作要不全部成功要不全部失败不会出现半成功的状态。
17、什么是两阶段提交
在 MySQL 的 InnoDB 存储引擎中开启 binlog 的情况下MySQL 会同时维护 binlog 日志与 InnoDB 的 redo log为了保证这两个日志的一致性MySQL 使用了内部 XA 事务内部 XA 事务由 binlog 作为协调者存储引擎是参与者。
事务的提交过程有两个阶段就是将 redo log 的写入拆成了两个步骤prepare 和 commit中间再穿插写入binlog 1prepare 阶段将 XID内部 XA 事务的 ID 写入到 redo log同时将 redo log 对应的事务状态设置为 prepare然后将 redo log 持久化到磁盘innodb_flush_log_at_trx_commit 1 的作用 2commit 阶段把 XID 写入到 binlog然后将 binlog 持久化到磁盘sync_binlog 1 的作用接着调用引擎的提交事务接口将 redo log 状态设置为 commit此时该状态并不需要持久化到磁盘只需要 write 到文件系统的 page cache 中就够了因为只要 binlog 写磁盘成功就算 redo log 的状态还是 prepare 也没有关系一样会被认为事务已经执行成功 18、分析两阶段提交下异常重启不会导致主从数据不一致。
在 MySQL 重启后会按顺序扫描 redo log 文件碰到处于 prepare 状态的 redo log就拿着 redo log 中的 XID 去 binlog 查看是否存在此 XID 1如果 binlog 中没有当前内部 XA 事务的 XID说明 redolog 完成刷盘但是 binlog 还没有刷盘则回滚事务。 2如果 binlog 中有当前内部 XA 事务的 XID说明 redolog 和 binlog 都已经完成了刷盘则提交事务。 对于处于 prepare 阶段的 redo log即可以提交事务也可以回滚事务这取决于是否能在 binlog 中查找到与 redo log 相同的 XID如果有就提交事务如果没有就回滚事务。这样就可以保证 redo log 和 binlog 这两份日志的一致性了。 所以说两阶段提交是以 binlog 写成功为事务提交成功的标识因为 binlog 写成功了就意味着能在 binlog 中查找到与 redo log 相同的 XID。
19、事务没提交的时候redo log 会被持久化到磁盘吗这样会不会有问题
事务执行中间过程的 redo log 也是直接写在 redo log buffer 中的这些缓存在 redo log buffer 里的 redo log 也会被「后台线程」每隔一秒一起持久化到磁盘。也就是说事务没提交的时候redo log 也是可能被持久化到磁盘的。
如果 mysql 崩溃了还没提交事务的 redo log 已经被持久化磁盘了mysql 重启后数据不就不一致了
这种情况 mysql 重启会进行回滚操作因为事务没提交的时候binlog 是还没持久化到磁盘的。所以 redo log 可以在事务没提交之前持久化到磁盘但是 binlog 必须在事务提交之后才可以持久化到磁盘。
20、两阶段提交存在什么问题
两阶段提交虽然保证了两个日志文件的数据一致性但是性能很差主要有两个方面的影响 1磁盘 I/O 次数高对于“双1”配置每个事务提交都会进行两次 fsync刷盘一次是 redo log 刷盘另一次是 binlog 刷盘。 binlog 和 redo log 在内存中都对应的缓存空间binlog 会缓存在 binlog cacheredo log 会缓存在 redo log buffer它们持久化到磁盘的时机分别由下面这两个参数控制。一般我们为了避免日志丢失的风险会将这两个参数设置为 1 01.当 sync_binlog 1 的时候表示每次提交事务都会将 binlog cache 里的 binlog 直接持久到磁盘 02.当 innodb_flush_log_at_trx_commit 1 时表示每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘 2锁竞争激烈两阶段提交虽然能够保证「单事务」两个日志的内容一致但在「多事务」的情况下却不能保证两者的提交顺序一致因此在两阶段提交的流程基础上还需要加一个锁来保证提交的原子性从而保证多事务的情况下两个日志的提交顺序一致。 在早期的 MySQL 版本中通过使用 prepare_commit_mutex 锁来保证事务提交的顺序在一个事务获取到锁时才能进入 prepare 阶段一直到 commit 阶段结束才能释放锁下个事务才可以继续进行 prepare 操作。 通过加锁虽然完美地解决了顺序一致性的问题但在并发量较大的时候就会导致对锁的争用性能不佳。 21、怎么解决两阶段提交的问题
MySQL 引入了 binlog 组提交group commit机制当有多个事务提交的时候会将多个 binlog 刷盘操作合并成一个从而减少磁盘 I/O 的次数如果说 10 个事务依次排队刷盘的时间成本是 10那么将这 10 个事务一次性一起刷盘的时间成本则近似于 1。
22、详细说说两阶段提交的流程。
1flush 阶段
第一个事务会成为 flush 阶段的 Leader此时后面到来的事务都是 Follower获取队列中的事务组由事务组的 Leader 对 rodo log 做一次 write fsync即一次将同组事务的 redolog 刷盘完成了 prepare 阶段后将这一组事务执行过程中产生的 binlog 写入 binlog 文件调用 write不会调用 fsync所以不会刷盘binlog 缓存在操作系统的文件系统中。2sync 阶段
一组事务的 binlog 写入到 binlog 文件后并不会马上执行刷盘的操作而是会等待一段时间这个等待的时长由 Binlog_group_commit_sync_delay 参数控制目的是为了组合更多事务的 binlog然后再一起刷盘在等待的过程中如果事务的数量提前达到了 Binlog_group_commit_sync_no_delay_count 参数设置的值就不用继续等待了就马上将 binlog 刷盘binlog_group_commit_sync_delay N表示在等待 N 微妙后直接调用 fsync将处于文件系统中 page cache 中的 binlog 刷盘也就是将「 binlog 文件」持久化到磁盘。
binlog_group_commit_sync_no_delay_count N表示如果队列中的事务数达到 N 个就忽视binlog_group_commit_sync_delay 的设置直接调用 fsync将处于文件系统中 page cache 中的 binlog 刷盘。3commit 阶段
调用引擎的提交事务接口将 redo log 状态设置为 commit。23、组提交发现MySQL的IO还是很高有什么办法优化
现在我们知道事务在提交的时候需要将 binlog 和 redo log 持久化到磁盘那么如果出现 MySQL 磁盘 I/O 很高的现象我们可以通过控制以下参数来 “延迟” binlog 和 redo log 刷盘的时机从而降低磁盘 I/O 的频率
1设置组提交的两个参数 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 参数延迟 binlog 刷盘的时机从而减少 binlog 的刷盘次数。 这个方法是基于“额外的故意等待”来实现的因此可能会增加语句的响应时间但即使 MySQL 进程中途挂了也没有丢失数据的风险因为 binlog 早被写入到 page cache 了只要系统没有宕机缓存在 page cache 里的 binlog 就会被持久化到磁盘。 2将 sync_binlog 设置为大于 1 的值比较常见是 100~1000表示每次提交事务都 write但累积 N 个事务后才 fsync相当于延迟了 binlog 刷盘的时机。 这样做的风险是主机掉电时会丢 N 个事务的 binlog 日志。 3将 innodb_flush_log_at_trx_commit 设置为 2。表示每次事务提交时都只是缓存在 redo log buffer 里的 redo log 写到 redo log 文件 注意写入到「 redo log 文件」并不意味着写入到了磁盘因为操作系统的文件系统中有个 Page Cache专门用来缓存文件数据的所以写入「 redo log文件」意味着写入到了操作系统的文件缓存然后交由操作系统控制持久化到磁盘的时机。但是这样做的风险是主机掉电的时候会丢数据。
