Mysql redo&&undo学习 - 推酷
Mysql redo&&undo学习
mysql通过锁机制来实现事务的隔离性，用redo log实现事务的原子性和持久性，用undo log实现事务的一致性。undo并不是redo的逆过程，redo和undo都可以看做一种恢复过程，redo恢复事务修改的页操作，redo记录的是物理日志，记录的是页的物理修改操作，redo log基本上都是顺序写的，在数据库运行时不需要对redo log的文件进行读取操作。undo回滚行记录到某个版本，undo记录的是逻辑日志，根据每行记录进行记录，undo log是需要进行随机读取的。
& &redo log是innodb存储引擎产生的，二进制日志则是mysql数据库层产生的，redo log在事务进行中不断的被写入redo log，这导致日志并不是随着事务的提交顺序进行写入的，而二进制日志只在事务提交后进行一次写入日志。
& &redo日志由两部分构成：redo log buffer、redo log file。innodb是支持事务的存储引擎，在事务提交时，必须先将该事务的所有日志写入到redo日志文件中，待事务的commit操作完成才算整个事务操作完成。在每次将redo log buffer写入redo log file后，都需要调用一次fsync操作，因为重做日志缓冲只是把内容先写入操作系统的缓冲系统中，并没有确保直接写入到磁盘上，所以必须进行一次fsync操作。因此，磁盘的性能在一定程度上也决定了事务提交的性能。
& &但是，关于fsync这个操作用户是可以干预的，因为每次提交事务都执行一次fsync，确实影响数据库性能。通过innodb_flush_log_at_trx_commit来控制redo log刷新到磁盘的策略。该参数的默认值为0，表示每次提交事务时都执行一次fsync操作。0则表示事务提交时不进行写入重做日志，这个写入操作由master thread进程来完成，master thread每一秒会进行一次重做日志文件的fsync操作。2则表示事务提交时将重做日志写入重做日志文件，但仅写入文件系统的缓存中，并不进行fsync操作。用户可以通过设置0或者2啦提高事务提交的性能，也可以设置1来要求确保redo log是写入文件中的，总之三种方法各有利弊。redo log buffer将内存中的log block刷新到磁盘是有一定的规则的：事务提交时(前面已经提到)、当log buffer中有一半的内存空间被使用时、log checkpoint时。
& innodb存储引擎中，redo log以512字节进行存储，这意味着重做日志是以块的方式保存的，如果一个页中的重做日志大于512字节，则需要分隔到多个块中进行存储。重做日志块由三部分构成：日志块头(12字节)、日志块尾(8字节)、日志本身。redo log buffer是由log block(512字节)组成的。redo log group其中包含多个重做日志文件，可以有多个log group，log group只是一个逻辑概念，并没有一个实际存储的物理文件来表示log group的信息。在log group中的每个重做日志文件大小都是相同的，在innodb版本1.2之前，重做日志文件的总大小要小于4G，1.2版本之后总大小提高到512G。重做日志文件中存储的就是在之前log buffer中保存的log block，因此其也是根据块的方式进行物理存储管理的，大小也是512字节。log block会被追加写入到redo log file的最后面，当一个redo log file被写满时，会接着写入下一个rdo log file，其使用方式是轮转的。redo log file除了保存log buffer刷新到磁盘的信息外，还保存了一些其他信息，每个redo log file的前2KB不保存log block信息，这2KB会保存log file header信息和一些checkpoint信息。
& innodb引擎的存储管理是基于页的，因此其重做日志格式也是基于页的。在重做日志中有个LSN比较重要，它的全称是log sequence number，其代表的是日志序列号。LSN在存储引擎中单调递增，它表示重做日志写入的总量(单位为字节)、checkpoint的位置、页的版本。在每个页中有一个值记录了该页的LSN，在页中LSN表示该页最后刷新时LSN的大小，以为重做日志记录的是每个夜的日志，因此页中的LSN用来判断页是否需要进行恢复操作。假如：重做日志中的LSN小于页中的LSN则表示不需要重做，如果重做日志中的LSN大于页中的LSN，则表示需要将重做日志恢复到页中。
& innodb存储引擎在启动时不管上次数据库是否正常关闭，都会尝试进行恢复操作，因为重做日志记录的是物理日志，因此恢复起来比逻辑日志要快，由于checkpoint记录的是已经刷新到磁盘页上的LSN，因此在恢复过程中仅需要恢复checkpoint开始的日志。
& undo就是对事务进行回滚操作的，innodb引擎在对数据库进行修改时，不但会产生redo也会产生一定量的undo。例如用户执行rollback时就会利用undo信息进行回滚。redo有redo log，undo则存放在数据库内部的一个特殊段中，称为undo段，undo段位于共享表空间内，undo是逻辑日志，因此只是将数据库逻辑的恢复到原来的样子，所有的修改都被逻辑的取消，但是数据结构和页本身在回滚之后可能不相同。因此，不能将一个页回滚到事务开始的样子，因为同一时刻可能还有其他事务在访问该页。
& 当innodb引擎进行回滚时，实际上做的是与之前相反的操作，例如对insert执行delete操作，undo除了回滚功能外，还有另外一个作用是MVCC，innodb中的MVCC是通过undo实现的。当用户读取一行记录，该记录被其他事务占用时，可以通过undo信息读取之前的行版本信息。不过要注意，undo会产生redo log。
& innodb对undo的管理采用段的方式，innodb有rollback segment，每个rollback segment记录了1024个undo log segment，在每个undo log segment中申请undo页。在innodb1.1之后支持128个rollback segment。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致innodb的binlog和redo/undo log无关 - 数据库当前位置:& &&&innodb的binlog和redo/undo log无关innodb的binlog和redo/undo log无关&&网友分享于：&&浏览：0次innodb的binlog跟redo/undo log无关
mysql, 不管用的是不是innodb, 都有binlog. 这个binary log跟transaction没关系，它主要用于replication和backup. log文件会一直递增，不会循环使用(后面的记录不会覆盖前面的）同时，innodb还有redo log/undo log. 它们用于transaction, 且会循环使用。
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有陈仲阳0 的BLOG
用户名：陈仲阳0
文章数：113
评论数：50
访问量：178857
注册日期：
阅读量：5863
阅读量：12276
阅读量：404730
阅读量：1093537
51CTO推荐博文
在InnoDB中，bufferpool里面的dirtypage一方面可以加快数据处理速度，同时也会造成数据的不一致(RAMvsDISK)。本文介绍了dirtypage是如何产生，以及InnoDB如何利用redolog如何消除dirtypage产生的数据不一致。当事务(Transaction)需要修改某条记录（row）时，InnoDB需要将该数据所在的page从disk读到bufferpool中，事务提交后，InnoDB修改page中的记录(row)。这时bufferpool中的page就已经和disk中的不一样了，我们称bufferpool中的page为dirtypage。Dirtypage等待flush到disk上。dirtypage既然是在Bufferpool中，那么如果系统突然断电Dirtypage中的数据修改是否会丢失？这个担心是很有必要的，例如如果一个用户完成一个操作（数据库完成了一个事务，page已经在bufferpool中修改，但dirtypage尚未flush），这时系统断电，bufferpool数据全部消失。那么，这个用户完成的操作（导致的数据库修改）是否会丢失呢？答案是不会(innodb_flush_log_at_trx_commit=1)。这就是redolog要做的事情，在disk上记录更新。redolog在每次事务commit的时候，就立刻将事务更改操作记录到redolog。所以即使bufferpool中的dirtypage在断电时丢失，InnoDB在启动时，仍然会根据redolog中的记录完成数据恢复。redolog的另一个作用是，通过延迟dirtypage的flush最小化磁盘的randomwrites。（redolog会合并一段时间内TRX对某个page的修改）正常情况下，dirtypage什么时候flush到disk上？1).redolog是一个环(ring)结构，当redo空间占满时，将会将部分dirtypageflush到disk上，然后释放部分redolog。这种情况可以通过Innodb_log_wait(SHOWGLOBALSTATUS)观察，情况发生该计数器会自增一次。2).当需要在Bufferpool分配一个page，但是已经满了，并且所有的page都是dirty的（否则可以释放不dirty的page），通常是不会发生的。这时候必须flushdirtypagestodisk。这种情况将会记录到Innodb_buffer_pool_wait_free中。一般地，可以可以通过启动参数innodb_max_dirty_pages_pct控制这种情况，当bufferpool中的dirtypage到达这个比例的时候，将会强制设定一个checkpoint，并把dirtypageflush到disk中。3).检测到系统空闲的时候，会flush，每次64pages。涉及的InnoDB配置参数：innodb_flush_log_at_trx_commit、innodb_max_dirty_pages_pct；状态参数：Innodb_log_wait、Innodb_buffer_pool_wait_free。本文出自 “” 博客，转载请与作者联系！
了这篇文章
类别：┆阅读(0)┆评论(0)
本文收录至博客专题：《》no redo log
时间： 20:56:04
分布式系统原理 -- 日志技术 Redo Log
在分布式系统中，宕机是需要考虑的重要组成部分。日志技术是宕机恢复的重要技术之一。日志技术应用广泛，早些更是广泛应用在数据库设计实现中。本文先介绍基本原理概念，最后通过 redis 介绍生产环境中的实现方法。
数据库设计中，需要满足 ACID，尤其是在支持事务的系统中。当系统遇到未知错误时，可以恢复到一个稳定可靠的状态。有一个很简单的思路，就是记录所有对数据库的写操作日志。那么一旦发生故障，即使丢失掉内存中所有数据，当下一次启动时，通过已经记录的数据库写操作日志，依然可以回到故障之前的状态（如果在写操作作日志的时候发生故障，那么这次数据库操作失败）。
操作流程简单如下（假设每次数据变化，都提交）：
更新的操作方式依次记录到磁盘日志文件。
更新内存中的数据。
返回更新成功结果。
恢复流程：
读取日志文件，依次修改内存中的数据。
日志文件有序，可以通过 append 的方式写入磁盘，性能很高。
简单可靠，应用广泛。可以把内存中的数据，做备份在磁。
使用时间一长，恢复宕机的时间很慢。
先具体化下，如果我们内存中保留一个 a 的值，记录了写操作比如 a = 4; a++; a--; 当这些操作上千万、亿之后，恢复非常慢。甚至可能最后一条就是a=0，按照之前的算法，我们却跑了很长时间。
那么根据这个场景，很容易想到一个解决方案。
操作流程：
日志文件记录begin check point
在某个时刻，把内存中的数值，直接 snapshot 或 dump 到磁盘上。（比如直接记录 a=4）
日志文件记录end check point
恢复流程：
扫描日志文件，找到最后的end check point中的begin check point。
读入 dump 文件。
依次回放记录的日志操作。
应用广泛，包括 mysql，oracle。
一些的问题：
在做 snapshot 的时候，往往不能停止数据库的服务，那么很可能记录了begin check point之后的日志。那么在重新 load begin check point之后的日志时，最后恢复的数据很有可能不对。比如我们记录的是a++这样的日志, 那么重复一条日志，就会让 a 的值加 1。如果我们记录是幂等的，比如一直是 a=5 这种操作，那么就对最后结果没有影响。很显然，设计幂等操作系统很麻烦。
设计一个支持 snapshot 的内存数据结构，也比较麻烦。
典型的是通过 copy-on-write 机制。和操作系统中的概念一样。当这个数据结构被修改，就创建一份真正的 copy。老数据增加一份 dirty flag。如果没有修改就继续使用之前的内存。这样在做 snapshot 的时候，保证我们的 dump 数据是begin check point这个时刻的数据。显然这个也比较麻烦。
还有一种支持 snapshot 的思路是begin check point后，不动老的数据。内存中的数据在新的地方，日志也写在新的地方。最后在end check point做一次 merge。这个实现起来简单，但是内存消耗不小。
Redis 是如何解决日志问题的
Redis 是一个基于内存的 database，不同于 memcached，他支持持久化。另外由于 redis 处理 client request 和 response 都是在一个 thread 里面，也没有抢占式的调度系统，核心业务都是按照 event loop 顺序执行，而磁盘写日志又开销很大，所以 redis 实现日志功能做了很多优化。并且提供 2 种持久化方案。我们需要在不同的场景下，采用不同的方式配置。
snapshotting
某个时刻，redis 会把内存中的所有数据 snapshot 到磁盘文件。更的说法是 fork 一个 child process，把内存中的数据序列化到临时文件，然后在 main event loop 中原子的更换文件名。redis，利用了操作系统 VM 的 copy-on-write 机制，在不阻塞主线程的情况下，利用子进程和父进程共享的 data segment 实现 snapshot。具体是代码实现在rdb.c, function at rdbSaveBackground
简单可靠，如果 database 不大，执行的效果非常好。
如果 database size 很大，每一次 snapshot 时间非常长。不得不配置大的间隔，提高了宕数据丢失的风险。
为了解决上面的问题，redis 增加了 AOF。
Append Only File（AOF）
在 database 术语中，也被叫做 WAL。如果开启的 AOF 的配置，redis 会记录所有写操作到日志文件中。那么 redis 同样会遇到之前我们提到过的问题。
即便是追加写，磁盘的操作依然比内存慢好几个数，频繁的操作容易产生瓶颈。
如果数据量操作频繁，会产生大量的重复日志数据，导致恢复时间太长。比如记录一条微博的浏览量，会记录大量重复的+1日志。
那么 redis 是如何解决的呢？
文件写操作消耗的时间很长，redis 会先把记录日志写在内存 buffer 中，在每一次 event loop 结束之后，根据配置判断是否做写操作。每个 buffer 的大小有限制，这样每次写操作时间不会太长。
即便是调用 write 操作，OS 并没有立即写入磁盘，redis 同样提供了一些方案决定刷新 OS IO buffer 的时机（1 秒、、每次）。
redis 提供一种 AOF 重写的方式rewriteAppendOnlyFile来处理 AOF 文件过大情况。
前面我们知道了，这种check point的机制还是比较麻烦的。那么 redis 是这么设计的。
为了避免加锁，redis 依然创建了一个 child process，利用 VM 的 copy-on-write，共享数据。同时保证主线程依然可以处理 client 请求。
根据 KV 的类型，先从内存读取数据，然后再写数据到磁盘，和之前的 AOF 文件无关。
那么当子进程 rewrite AOF 的过程中，main thread 依然可以处理新的 client request。新增的数据会被放在 rewrite buffer 中，而且写到原有的 AOF 文件中。
child process 完成后会通知主线程。主线程有一个定时任务，也就是会不断轮询 child process 是否已经完成（通过信号量）。
主线程会 merge 变化的数据到 temp file。
主线程原子的 rename 到一个新的 AOF 文件，之前的 AOF 就不起作用了。
除了 merge 和 rename 需要阻塞主线程，rewrite 不会阻塞主线程。（前提是使用 bgrewrite command）。
这些都是性能和稳定性之间做的，根据不同场景需要调整。
Redis latency problems troubleshooting
分布式系统原理介绍
Thoughts on Redis
http://studentdeng.github.io/blog//log-system/
分布式系统原理 -- 日志技术 No Redo Log
上一篇介绍了 Redo Log，这篇介绍 No Redo Log。
在分布式系统中，某些情况下我们依然需要实现原子操作，有很多方式，其中 No Redo(Undo) Log 便是在工程中运用最广泛的思想之一。他的过程非常简单。
下面是一个简单系统的状态。
为了实现原子的修改 A，B，C 的值。我们把 A，B，C 看成一个集合，或是一个 “目录”。
1. 做一次 copy
2. 对于每个更新的操作，创建一个新的 item，然后在新的目录中保存修改后的新值。
3. 原子性的修改生效目录指针。
通过原子性的修改一个值，切换一个状态，完成一系列分布式操作原子性的修改。
http://studentdeng.github.io/blog//log-system2/
$T.total > 0 && $T.page <= $T.pageNum}
{#foreach $T.data as r}
{$T.r.formt_tm}{#if $T.r.nickname}{#else}匿名{#/if}
{$T.r.content}
{#if $T.page > 1 && $T.pageNum > 1)
$T.s_num > 2}
{#for index = $T.s_num to $T.e_num}
$T.pageNum > $T.pageNavSize+ 2 && $T.s_num != $T.pageNum - $T.pageNavSize}
{#if $T.pageNum > 1}
{#if $T.pageNum != $T.page && $T.pageNum > 1}
<a href="javascript:void(0);" page="{$T.page 下一页
您的回应...
也许你感兴趣
(window.slotbydup=window.slotbydup || []).push({
id: '3465635',
container: s,
size: '120,240',
display: 'float'
(C)2012 本站提供的内容来源于广大网络用户，我们不保证内容的正确性。如果转载了您的内容，希望删除的请联系我们！