云南建设厅和网站html5 响应式网站

当前位置： 首页 > news >正文

云南建设厅和网站,html5 响应式网站,云虚拟机搭建wordpress,国外wordpress主题优化日志是mysql数据库的重要组成部分#xff0c;记录着数据库运行期间各种状态信息#xff0c;能帮助我们进行很多容错及分析工作#xff0c;其中有三大日志与我们这些开发者息息相关#xff0c;本文将介绍binlog、redoLog、undoLog三种日志#xff1a; 1. redoLog 1.1 为什么…日志是mysql数据库的重要组成部分记录着数据库运行期间各种状态信息能帮助我们进行很多容错及分析工作其中有三大日志与我们这些开发者息息相关本文将介绍binlog、redoLog、undoLog三种日志 1. redoLog 1.1 为什么需要redo log 我们都知道事务的四大特性里面有一个是持久性具体来说就是只要事务提交成功那么对数据库做的修改就被永久保存下来了不可能因为任何原因再回到原来的状态。 事务在运行过程中都是在内存的Buffer Pool修改页面事务提交后这些被修改后的脏页并不会立刻刷盘立刻刷盘开销太大一方面是一个页面可能就修改了一点点将整个页面刷盘不值当另一方面是一个事务会涉及不同的页面如果将这些页面都刷盘会产生很多的随机IO。 但如果不采取其他措施那么在事务提交后MySQL发生故障导致内存中数据丢失那么这个已提交事务作出的更改也会丢失那么mysql是如何保证内存和磁盘的一致性的呢 最简单的做法是在每次事务提交的时候将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题主要体现在两个方面 1、 因为Innodb是以页为单位进行磁盘交互的而一个事务很可能只修改一个数据页里面的几个字节这个时候将完整的数据页刷到磁盘的话太浪费资源了 2、 一个事务可能涉及修改多个数据页并且这些数据页在物理上并不连续使用随机IO写入性能太差 所以这里就需要引入redo日志对任意页面进行修改的操作都会生成redo日志在事务提交时只要保证生成的redo日志成功落盘即可这样即使MySQL发生故障导致内存中的数据丢失也可以根据已落盘的redo日志恢复数据 1.2 redo log基本概念 redo log是InnoDB存储引擎层的日志又称重做日志文件用于记录事务操作的变化记录的是数据修改之后的值不管事务是否提交都会记录下来。一个事务生成的redo日志是按顺序写入磁盘的是顺序IO在实例和介质失败media failure时redo log文件就能派上用场如数据库掉电InnoDB存储引擎会使用redo log恢复到掉电前的时刻以此来保证数据的完整性。 redo log包括两部分 一个是内存中的 日志缓冲(redo log buffer) 另一个是磁盘上的日志文件(redo log file) 。mysql每执行一条DML语句先将记录写入redo log buffer后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。 1.3 redo log记录形式 redo log 日志的大小是固定的即记录满了以后就从头循环写。 redolog记录方式 简单的redo日志  —— 记录哪个表空间中的哪个页面从哪个位置开始的多少个节点要修改成什么 复杂的redo日志  —— 记录了对哪个表空间的哪个页面进行修改存储了对该页面进行修改操作的一些必备要素重启时MySQL会根据redo日志的类型将redo日志中的必备要素作为参数调用日志类型对应的函数恢复数据 在计算机操作系统中用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。因此redo log buffer写入redo log file实际上是先写入OS Buffer然后再通过系统调用fsync()将其刷到redo log file中过程如下   mysql支持三种将redo log buffer写入redo log file的时机可以通过innodb_flush_log_at_trx_commit参数配置 redo log实际上记录数据页的变更而这种变更记录是没必要全部保存因此redo log实现上采用了大小固定循环写入的方式当写到结尾时会回到开头循环写日志。 总结确保事务的持久性。防止在发生故障的时间点尚有脏页未写入磁盘在重启mysql服务的时候根据redo log进行重做从而达到事务的持久性这一特性。   2. binlog 2.1 binlog基本概念 binlog是属于MySQL Server层面 的又称为归档日志属于逻辑日志是以二进制的形式记录的用于记录数据库执行的写入性操作(不包括查询)信息依靠binlog是没有crash-safe能力的 啥是逻辑日志啥是物理日志 逻辑日志可以简单理解为记录的就是sql语句物理日志因为mysql数据最终是保存在数据页中的物理日志记录的就是数据页变更 另外binlog是通过追加的方式进行写入的可以通过max_binlog_size参数设置每个binlog文件的大小当文件大小达到给定值之后会生成新的文件来保存日志。 2.2 binlog使用场景 在实际应用中binlog的主要使用场景有两个分别是主从复制和数据恢复。 1、主从复制在Master端主父节点开启binlog然后将binlog发送到各个(子)Slave端Slave端重放binlog从而达到主从数据一致。 2、 数据恢复通过使用mysql binlog工具来恢复数据。 2.3 binlog日志格式 binlog日志有三种格式分别为STATMENT、ROW 和 MIXED。 在 MySQL 5.7.7之前默认的格式是 STATEMENTMySQL 5.7.7之后默认值是 ROW。日志格式通过binlog-format指定。 STATMENT 基于SQL语句的复制(statement-based replication, SBR)每一条会修改数据的sql语句会记录到binlog中。 优点不需要记录每一行的变化减少了binlog日志量节约了IO, 从而提高了性能 缺点在某些情况下会导致主从数据不一致比如执行sysdate()、slepp()等。ROW 基于行的复制(row-based replication, RBR)不记录每条sql语句的上下文信息仅需记录哪条数据被修改了。 优点不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题 缺点会产生大量的日志尤其是alter table的时候会让日志暴涨MIXED 基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)一般的复制使用STATEMENT模式保存binlog对于STATEMENT模式无法复制的操作使用ROW模式保存binlog 3. redolog和binlog区别 redo log是属于innoDB层面binlog属于MySQL Server层面的这样在数据库用别的存储引擎时可以达到一致性的要求。redo log是物理日志记录该数据页更新的内容binlog是逻辑日志记录的是这个更新语句的原始逻辑redo log是循环写日志空间大小固定binlog是追加写是指一份写到一定大小的时候会更换下一个文件不会覆盖。binlog可以作为恢复数据使用主从复制搭建redo log作为异常宕机或者介质故障后的数据恢复使用。 redo log是InnoDB存储引擎层的日志binlog是MySQL Server层记录的日志 两者都是记录了某些操作的日志(不是所有)自然有些重复但两者记录的格式不同。 4. undo log 数据库事务四大特性中有一个是原子性具体来说就是 原子性是指对数据库的一系列操作要么全部成功要么全部失败不可能出现部分成功的情况。 实际上原子性底层就是通过undo log实现的。 undo log主要记录了数据的逻辑变化比如一条INSERT语句对应一条DELETE的undo log对于每个UPDATE语句对应一条相反的UPDATE的undo log这样在发生错误时就能回滚到事务之前的数据状态。 undo log保存了事务发生之前的数据的一个版本可以用于回滚同时可以提供多版本并发控制下的读MVCC也即非锁定读