Redo Log记录的是redo,那么redo是什么呢?通俗来讲,redo记录的是对应的记录改变的物理 *** 作。说实话,过去的很长一段时间内,我对redo的认识也仅限于此,并没有好好深入理解redo记录的到底是什么。这次从redo的物理结构上深入理解下redo到底是什么。
Redo Log逻辑&物理结构
从逻辑上来讲,redo log记录是连续递增的,但是对应到物理文件就不一样了,考虑到磁盘空间,redo log被设计成了多个可循环写入的文件。InnoDB要求Redo Log,文件至少有2个,初始文件为 ib_logfile0和 ib_logfile1, ib_logfile0写完以后写 ib_logfile1,等到 ib_logfile1也写完了,从头又开始写 ib_logfile0,这样就形成了一个环形写入的结构。但是覆盖写入的前提是要确定哪个位置点是可以覆盖写的,哪些位置是不能覆盖写的,这个就是check point的工作了
可以说mysql的多数特性都是围绕日志文件实现,而其中最重要的有以下三种
innodb 为了提高磁盘I/O读写性能,存在一个 buffer pool 的内存空间,数据页读入会缓存到 buffer pool,事务的提交则实时更新到 buffer pool,而不实时同步到磁盘(innodb 是按 16KB 一页同步的,一事务可涉及多个数据页,实时同步会造成浪费,随机I/O)。事务暂存在内存,则存在一致性问题,为了解决系统崩溃,保证事务的持久性,我们只需把事务对应的 redo 日志持久化到磁盘即可(redo 日志占用空间小,顺序写入磁盘,顺序I/O)
sql 语句在执行的时候,可能会修改多个页面,还会更新聚簇索引和二级索引的页面,过程产生的redo会被分割成多个不可分割的组(Mini-Transaction)。MTR怎么理解呢?如一条 insert 语句可能会使得页分裂,新建叶子节点,原先页的数据需要复制到新数据页里,然后将新记录插入,再添加一个目录项指向新建的页子。这对应多条 redo 日志,它们需要在原子性的 MTR 内完成
MTR 产生的 redo 日志先会被复制到一个 log buffer 里(类似 buffer pool)。而同步到磁盘的时机如下:
事务需要保证原子性,也是说事务中的 *** 作要么全部完成,要么什么也不做。如果事务执行到一半,出错了怎么办-回滚。但是怎么回滚呢,靠 undo 日志。undo 日志就是我们执行sql的逆 *** 作
binlog有三种格式:Statement、Row以及Mixed。
redolog 中的事务如果经历了二阶段提交中的prepare阶段,则会打上 prepare 标识,如果经历commit阶段,则会打上commit标识(此时redolog和binlog均已落盘)。崩溃恢复逻辑如下:
调整Oracle Redo Logfile日志文件的大小:1. 首先检查日志文件大小及使用状态
SYS@TESTDB >select bytes/1024/1024 from v$log
BYTES/1024/1024
---------------
50
50
50
SYS@TESTDB >select member from v$logfile
MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/TESTDB/redo03.log
/u01/app/oracle/oradata/TESTDB/redo02.log
/u01/app/oracle/oradata/TESTDB/redo01.log
2. 增加3组新的500M的日志组
SYS@TESTDB >alter database add logfile group 4 ('/u01/app/oracle/oradata/TESTDB/redo04.log') size 500m
Database altered.
SYS@TESTDB >alter database add logfile group 5 ('/u01/app/oracle/oradata/TESTDB/redo05.log') size 500m
Database altered.
SYS@TESTDB >alter database add logfile group 6 ('/u01/app/oracle/oradata/TESTDB/redo06.log') size 500m
Database altered.
3. 删除3组旧的50M的日志组,第二组报错,原因是他目前是current 的日志组,不能被删除。
SYS@TESTDB >alter database drop logfile group 1
Database altered.
SYS@TESTDB >alter database drop logfile group 2
alter database drop logfile group 2
*
ERROR at line 1:
ORA-01623: log 2 is current log for instance TESTDB (thread 1) - cannot drop
ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/TESTDB/redo02.log'
SYS@TESTDB >alter database drop logfile group 3
Database altered.
4. 切换当前日志组,再删除第2组日志。报错原因是第2组日志仍为活动日志组,不能被删除。
SYS@TESTDB >alter system switch logfile
System altered.
SYS@TESTDB >alter database drop logfile group 2
alter database drop logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance TESTDB (thread 1)
ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/TESTDB/redo02.log'
SYS@TESTDB >select group#,status from v$log
GROUP# STATUS
---------- ----------------
2 ACTIVE
4 CURRENT
5 UNUSED
6 UNUSED
5. 做全局检查点,使redo日志文件改变为非活动
SYS@TESTDB >alter system checkpoint
System altered.
SYS@TESTDB >select group#,status from v$log
GROUP# STATUS
---------- ----------------
2 INACTIVE
4 CURRENT
5 UNUSED
6 UNUSED
6. 再次删除第2组redo日志组
SYS@TESTDB >alter database drop logfile group 2
Database altered.
SYS@TESTDB >select group#,status from v$log
GROUP# STATUS
---------- ----------------
4 CURRENT
5 UNUSED
6 UNUSED
7. 验证日志组文件及大小
SYS@TESTDB >select group#,bytes/1024/1024 from v$log
GROUP# BYTES/1024/1024
---------- ---------------
4 500
5 500
6 500
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)