binlog 就是binary log,二进制日志文件,这个文件记录了mysql所有的dml操作。通过binlog日志我们可以做数据恢复,做主住复制和主从复制等等。 如何开启mysql的binlog日志呢? log_bin_basename=/var/lib/mysql/mysql-bin log_bin_index=/var/lib/mysql/mysql-bin.index 三个参数来指定, 第一个参数是打开binlog日志 第二个参数是binlog日志的基本文件名,后面会追加标识来表示每一个文件 第三个参数指定的是binlog文件的索引文件,这个文件管理了所有的binlog文件的目录 当然也有一种简单的配置,一个参数就可以搞定 对于binlog日志的具体操作,可以参考 binlog日志详解:http://blog.csdn.net/king_kgh/article/details/74833539 使用binlog
什么是事务日志? 事务要保证 ACID 的完整性必须依靠事务日志做跟踪: 每一个操作在真正写入数据数据库之前,先写入到日志文件中 如要删数据会先在日志文件中将此行标记为删除,但是数据库中的数据文件并没有发生变化。 然后再写入数据库文件中 写入数据库文件的操作是重做事务日志中已提交的事务操作的记录 事务日志 事务的日志主要分为三类:redo log,undo log和binlog 日志组 在写日志的时候, 日志提高事务的效率和安全性保证 用事务日志,存储引擎在修改表的数据的时候,只需要修改其内存,再把该行为记录到持久在磁盘的事务日志中。 事务开启时,事务中的操作,都会先写入存储引擎的日志缓冲。 在事务提交之前,缓冲的日志都需要提前刷新到磁盘上持久化,这就常说的“日志先行”(Write- Ahead-Logging)。
1、日志文件 (1)Zookeeper的事务日志文件位置,在配置文件zoo.cfg的dataDir指定。 我的配置如下 dataDir=/tpdata/zookeeper (2)日志文件 zookeeper的日志为二进制格式文件,不能直接查看 [root@node1 version-2]# pwd /tpdata log.b00000001 -rw-r--r-- 1 root root 296 4月 19 2018 snapshot.200000000 [root@node2 version-2]# 2、查看日志文件 (1)复制zookeeper的两个jar包到日志目录 [root@node1 zookeeper-3.4.10]# cp zookeeper-3.4.10.jar /tpdata/zookeeper/ / [root@node1 zookeeper-3.4.10]# cp lib/slf4j-api-1.6.1.jar /tpdata/zookeeper/version-2/ (2)通过jar包解析日志
1.Undo 日志引入: 事务需要保证原子性,也就是事务中的操作要么全部完成,要么什么也不做。 2.Undo 日志作用: 作用一:回滚数据 用户对undo日志可能有误解:undo用于将数据库物理地恢复到执行语句或事务之前的样子。但事实并非如此。 undo是逻辑日志,因此只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了,但是数据结构和页本身在回滚之后可能大不相同。 这是因为在多用户并发系统中,可能会有数十、数百甚至数千个并发事务。 图片 回滚段与事务: 图片 show variables like '%innodb_undo_tablespaces%'; 图片 回滚段中的数据分类: 图片 4.Undo 日志类型: 图片 5.Undo 日志生命周期: 事务日志生成过程: 图片 图片 图片 在更新Buffer Pool中的数据之前,我们需要先将该数据事务开始之前的状态写入Undo Log中。
那么事务的四种特性到底是基于什么机制实现呢? 事务的隔离性由 锁机制 实现。 而事务的原子性、一致性和持久性由事务的 redo 日志和 undo 日志来保证。 REDO LOG 称为 重做日志 ,提供再写入操作,恢复提交事务修改的页操作,用来保证事务的持久性。 ,再写磁盘,只有日志写入成功,才算事务提交成功,这里的日志就是 redo log。 特点 redo 日志是顺序写入磁盘的 在执行事务的过程中,每执行一条语句,就可能产生若干条 redo 日志,这些日志是按照 产生的顺序写入磁盘的 ,也就是使用顺序 ID,效率比随机 IO 快。 # 2.1 如何理解 Undo 日志 事务需要保证 原子性 ,也就是事务中的操作要么全部完成,要么什么也不做。
有了事务日志和快照,就可以让任意节点恢复到任意时间点(只要没有清理事务日志和快照)。 如果没有配置事务日志(即dataLogDir配置项)的路径,那么ZooKeeper的事务日志也存放在数据目录中。 dataLogDir:指定事务日志的存放目录。 事务日志对ZooKeeper的影响非常大,强烈建议事务日志目录和数据目录分开,不要将事务日志记录在数据目录(主要用来存放内存数据库快照)下。 preAllocSize:为事务日志预先开辟磁盘空间。 默认是64M,意味着每个事务日志大小就是64M(可以去事务日志目录中看一下,每个事务日志只要被创建出来,就是64M)。 (见snapCount配置项) snapCount:ZooKeeper使用事务日志和快照来持久化每个事务(注意是日志先写)。
(这就是 redo log 的基本原理)InnoDB引擎的事务采用了WAL技术(Write-Ahead Logdhing),这种技术的思想就是先写日志,再写磁盘,只有日志写入成功,才算事务提交成功,这里的日志就是 在执行事务的过程中,每执行一条语句,就可能产生若干条redo日志,这些日志是按照产生的顺序写入磁盘的,也就是使用顺序IO,效率比随机IO快事务执行过程中,redo log不断记录。 如果事务执行期间MySQL挂了或宕机,这部分日志丢了,但是事务并没有提交,所以日志丢了也不会有损失。可以保证ACID的D,数据绝对不会丢失,但是效率最差的。 一个事务可以包含若干条语句,每一条语句其实是由若干个mtr组成,每一个mtr又可以包含若干条redo日志。 每个mtr都会产生一组redo日志,用示意图来描述一下这些mtr产生的日志情况:图片不同的事务可能是并发执行的,所以T1、T2之间的mtr可能是交替执行的。
言归正传, 还是说说后面遇的问题吧: 生产环境zookeeper崩溃,查看日志发现是磁盘空间已经写满。 起初以为是很简单的操作,删除无用的日志文件释放磁盘空间(这是不得不吐槽下HDP的日志文件是超多的,奈何生产环境又不敢不预留长些的时间),然后重启zookeeper满心欢喜的等待着服务恢复正常。 折腾了一下,发现,把ZooKeeper安装目录下的data/log/version-2下的,大小为0(异常的)日志,删除掉后,再重启 ,问题解决! 检查了一下对应的目录就真的发现了一个大小为0的log文件,删除然后启动zookeeper, OK输出日志正常,通过zookeeper client连接查看数据恢复正常。
3.简单恢复模式 我们本篇的重点介绍该模式,该模式下不保存事务日志,由于检查点进程会截断事务日志,因此不需要维护事务日志。 如果把数据库从其他恢复模式切换到这个模式下,会破坏事务日志的连续性,因为无法备份事务日志,在这种模式下,无法进行到某个时间的恢复。 事务日志备份:仅仅备份自上次完整备份或日志备份之后的记录。 而在简单恢复模式下,为了保证事务的持久性,那些有可能回滚的数据会被写入日志。这些日志需要被暂时保存在日志以确保在特定条件下事务可以顺利回滚。 CheckPoint的开始LSN 还未结束的事务在日志的最小LSN 尚未传递给分发数据库的最早的复制事务起点的 LSN. 因此可以看出,简单恢复模式下日志是不保存的(当事务结束后,相关的会被截断)。仅仅是用于保证事务回滚和崩溃恢复的用途.所以备份日志也就无从谈起,更不能利用日志来恢复数据库。
上篇文章简单介绍了事务之后,我们来学习下什么是事务日志和MySQL中的事务。 1、事务日志 事务日志可以帮助提高事务效率。 事务开始和结束都会记录到事务日志中,存储引擎在修改表数据时,只修改其内存拷贝,并把修改行为记录到硬盘上的事务日志中,事务日志是按顺序追加的,因此写日志的操作磁盘上一小块区域内的顺序I/O,而不是随机IO ,需要在磁盘上移动磁头,所以记录事务日志很快,事务日志持久以后,内存中被修改的数据在后台,根据记录的事务日志再慢慢回写到磁盘上。 通常称之为预写式日志。 如果数据的修改只记录到了事务日志,内存中的数据还没有回写到磁盘时,系统崩溃了,存储引擎在重启的时候能够自动恢复这部分修改的数据。 如果不是显示的开始一个事务,那么每个查询都被当做一个事务提交。
把事务模式改成“简单”,然后收缩一下日记和数据文件 ? ? ? 命令可以参考这篇文章:http://www.cnblogs.com/dunitian/p/6047709.html 可以了,如果需要后期恢复之类的,建议不要把事务模式改成简单,直接收缩,然后扩盘或者移个磁盘吧 完事之后,恢复事务模式为原来的即可 我的解决方案:迁移下位置呗: 先分离,再附加 ?
事务的隔离性是通过锁实现,而事务的原子性、和持久性则是通过事务日志实现。 在MySQL中,事务日志分为两类,一个是Redo Log,也叫重做日志,另一个是Undo Log,也叫回滚日志;其中Redo Log保证事务的持久性,Undo Log保证的是事务的原子性;2.1 Redo Log2.1.1 Redo Log与持久性事务开启后,执行的所有的操作都是记录在事务日志中,这部分数据并没有写入磁盘表,需要把当前事务提交,才会将事务日志记录的数据写入到磁盘表中。 Tips:Redo Log主要保障的是事务的持久性,即只要事务提交成功,那么数据就能够永久保存到数据库中,否则就属于提交失败,就应该进行事务回滚(根据Undo 日志回滚),客户端也可以做一些事务提交失败的代码流程 Tips:上面流程中这种先写日志,再写磁盘,只有日志写入成功,才算事务提交成功的技术思想在MySQL也叫做WAL技术 (Write-Ahead Logging日志先行)。
我们前面几个小节都介绍了这个事务日志(Txn Log),那这个日志内部到底长什么样,今天我们就来通过ZooKeeper自带的工具来读取这个日志。 事务日志是二进制的文件,无法直接通过Linux的文件操作命令来读取,必须借助工具(可以是第三方的,也可以ZooKeeper自带的)。 localhost version-2]# file snapshot.0 snapshot.0: data [root@localhost version-2]# 下面是我们用ZooKeeper自带的工具来阅读事务日志
如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。 log”记录在undo log日志中,本次事务插入的所有的数据行的版本号字段都为当前事务的ID。 ,而这个缓冲池主要存放两类东西,一类是数据相关的缓冲,如索引、锁、表数据等,另一类则是各种日志的缓冲,如Undo、Redo....等日志。 Undo Buffer中的内容进行事务的回滚操作,除此之外,Undo Buffer提供了数据的快照读取,在事务未提交之前,Undo 日志可以作为并发读写时的读快照,来保证事务的可重复读;事务做到一半了, 2.1.5 Undo Log与Purge线程前面提到,事务提交后Undo Log日志并不会马上删除,因为其他事务很可能需要用到该数据。直接移除可能会导致其他事务读不到数据。
DUMPTRANSACTION[数据库名]WITHNO_LOGBACKUPLOG[数据库数据库
每个 SQL Server 数据库都具有事务日志,用于记录所有事务以及每个事务对数据库所做的修改。 必须定期截断事务日志以避免它被填满。 但是,一些因素可能延迟日志截断,因此监视日志大小很重要。 某些操作可以最小日志量进行记录以减少其对事务日志大小的影响。 事务日志是数据库的重要组件,如果系统出现故障,则可能需要使用事务日志将数据库恢复到一致状态。 删除或移动事务日志以前,必须完全了解此操作带来的后果。 事务日志支持以下操作: ? 恢复个别的事务。 ? 在 SQL Server 启动时恢复所有未完成的事务。 ? 事务日志记录了所有事务以及每个事务对数据库所做的修改,用于确保数据库的数据完整性以及用于数据恢复,(后面这个是个人理解)由于记录的主体对象是事务相关的日志,所以就叫事务日志。 截断事务日志 截断是对SQL逻辑日志的一个清除过程,清除非活动的逻辑事务日志。
什么是事务日志? 事务日志是每个SQL Server数据库的文件组成部分。它包含在SQL Server数据库中日志记录过程中生成的日志记录。 当涉及到灾难恢复时,事务日志是SQL服务器数据库中最重要的组件——但是,它必须是未损坏的。在每次数据库修改-事务发生之后,一个日志记录被写到事务日志中。 所有更改都是按顺序编写的 SQL Server事务日志存储什么? 事务日志存储对SQL服务器数据库所做的每一个事务,但有些事务的日志记录最少,比如批量导入或SELECT INTO。 日志序列号(LSN)标识事务日志中的每个事务。MinLSN是在线事务日志中最老的活动事务的起始点。 SQL Server数据库可以在没有事务日志的情况下工作吗? 在简单的恢复中,事务日志增长的可能性很小——只是在长时间运行的事务或事务创建许多更改的特定情况下 大容量日志恢复模型-定期支持和需要事务日志备份。
CLOG相关处理 CommitTransaction->RecordTransactionCommit XactLogCommitRecord//XLOG_XACT_COMMIT日志 XLogFlush //将本事务相关WAL全部刷写到磁盘包括上面的commit日志 TransactionIdCommitTree//更新CLOG数据页中事务状态 3、重启恢复时,恢复XLOG_XACT_COMMIT类型日志 恢复时从checkpoint位置开始进行恢复,将所有WAL全部回放,不管该WAL是否属于已提交的事务。若该事务未提交,那么日志恢复出来的数据是脏数据,这部分数据不应被用户看到。 当事务提交时,在XLogFlush后崩溃,则事务日志和commit日志都持久化完成,虽然事务状态未更新,但是可认为已提交,那么在恢复时,解析到commit时,将CLOG中事务状态更新。 若在XLogFlush前崩溃,那么事务未提交,如果其他事务将该事务的日志刷下去一部分,那么同样认为这是脏数据的日志,虽然将其回放恢复了,但在可见性判断时,未在CLOG中检查到其已提交,所以不可见。
MySQL系列之事务日志Redo log学习笔记 学习本博客之前需要储备知识: MySQL体系架构 InnoDB存储引擎 MySQL事务知识 在上篇博客,我们知道了undo log,继续上篇博客,学习另外一种重要的 InnoDB事务日志redo log 1、Redo Log 1.1、什么是Redo log? Redo :重做的意思,undo是撤销回滚意思 Redo log:被称之为重做日志,是在数据库发生意外时,进行数据恢复,redo log会备份是事务执行过程中的修改数据,redo log备份的是事务过程中最新的数据位置 ,从而实现某些数据未写入磁盘的数据写到磁盘进行持久保存 基于上一章博客的图,进行拓展,对比一下undo log和redo log undo log和redo logo都是InnoDB的功能,都是事务日志 undo log是逻辑日志,记录是操作记录日志,redo log是物理日志,记录的是新数据 undo log是为了保证事务原子性而设计的,redo log是为了保证事务持久性设置的。
,然后在操作,聊事务时,有个持久性(Durability)的特性,也就是事务提交后,系统崩溃,也不能丢失这个事务的修改。 而且也没必要每次事务提交时,将全部修改的页面刷新到磁盘上,只要把修改的内容记录一下就好,这样事务完成时,哪怕出现故障也可以快速恢复。 那么怎么去记录呢? 比如,某个事务将user表中的第6条纪录的第8个字段的值由1修改为2,而假设物理地址在第6个页面中偏移量为88处,只需要记录: 将user表空间第6号页面中偏移量为88处的值更新为2. 这样事务提交时,这种记录空间使用极小,而且采用顺序写入磁盘。这就是redo log(redo日志)。 redo日志格式 根据上面我们可以想象到redo日志的格式,如下。 type:这条redo 日志的类型。 space ID:表空间id。 page number:页号。 data:这条日志的具体内容。 其实这也是通用的数据格式。