怎么做网站的优化排名,佳木斯城乡建设局官方网站,广州品牌网站建设公司,做网站教学书一个最基本的数据库#xff0c;应当可以做到以下几点 数据持久化#xff0c;可以将数据保存到磁盘#xff0c;服务重启数据依然存在。 可以按照某种关系存储数据#xff0c;如果你用过IO流#xff0c;那么你会发现整理数据也是一件复杂的事情。我是该追加写呢还是找到某条…一个最基本的数据库应当可以做到以下几点 数据持久化可以将数据保存到磁盘服务重启数据依然存在。 可以按照某种关系存储数据如果你用过IO流那么你会发现整理数据也是一件复杂的事情。我是该追加写呢还是找到某条数据位置再进行写呢这是个很复杂的问题。 快速查找。你想想自己如果将数据写入txt那又如何高效的去找到某条数据支持随机查找吗 故障恢复与数据回滚倘若你的服务断电了如何确保数据一定是写入到文件的若是误删或误改了某条数据你又如何进行恢复
MySQL的架构
关于MySQL的简单架构图。 MySQL大致可以分为服务层与存储引擎层。在单独抽离了存储引擎层后你可以选择合适的引擎例如InnoDbMyIsamMemory等等。
关于不同的存储引擎使用的方式可能不同。我主要想讲的是InnoDb引擎MySQL 5.5 版本后默认的存储引擎。
MySQL的日志系统 MySQL有三大日志分别是重做日志(redo log)二进制日志(bin log)以及回滚日志(undo log)。这三个日志非常重要学习MySQL数据库一定免不了要和他们打交道。 bin log
bin log是Server层的日志无论使用的是什么引擎都可以使用这种日志。这个日志记录的是逻辑日志就是SQL语句。例如insert into table set xx xx 在bin log中记录的也是这样的一条SQL。而且bin log 采用的是追加写的形式也即是说在写完一个bin log文件之后不会覆盖前面的而是新开一个文件继续追加写。
redo log
redo log 是存储引擎InnoDB所提供的日志模块。个日志记录的是物理日志。记录的是当前SQL在哪一个数据页上将什么数据修改为了什么数据。 关于redo log我很喜欢林晓斌老师在《MySQL实战45讲》中讲的例子酒馆的账本与黑板的例子。在古时候的酒馆中老板会有一本账本以及身后的一块黑板。倘若今天有人去喝酒赊账。在很忙的时候老板会将这条记录写在黑板上后续等到酒馆打烊了不忙的时候才将这个记录写进自己的账本中。 事实上在MySQL也是这么做的如果每一次的更新操作都需要写进磁盘然后磁盘也要找到对应的那条记录然后再更新整个过程 IO 成本、查找成本都很高。
而黑板和账本配合的整个过程其实就是 MySQL中常说到的 WAL Write-Ahead Logging技术WAL 的全称是 它的关键点就是先写日志再写磁盘也就是先写黑板等不忙的时候再写账本。
具体来说当有一条记录需要更新的时候InnoDB 引擎就会先把记录写到 redo log黑板里面并更新内存这个时候更新就算完成了。同时InnoDB 引擎会在适当的时候将这个操作记录更新到磁盘里面而这个更新往往是在系统比较空闲的时候做这就像酒馆打烊之后老板做的事。
如果今天赊账的不多掌柜可以等打烊后再整理。但如果某天赊账的特别多黑板写满了又怎么办呢这个时候掌柜只好放下手中的活儿把粉板中的一部分赊账记录更新到账本中然后把这些记录从粉板上擦掉为记新账腾出空间。
与此类似InnoDB 的 redo log 是固定大小的比如可以配置为一组 4 个文件每个文件的大小是 1GB那么这块“黑板”总共就可以记录 4GB 的操作。从头开始写写到末尾就又回到开头循环写如下面这个图所示。 write pos 是当前记录的位置一边写一边后移。checkpoint 是当前要擦除的位置也是往后推移并且循环的擦除记录前要把记录更新到数据文件。
write pos 和 checkpoint 之间的是“黑板”上还空着的部分可以用来记录新的操作。如果 write pos 追上 check point表示“黑板”满了这时候不能再执行新的更新得停下来先擦掉一些记录把 checkpoint 推进一下。
有了 redo logInnoDB 就可以保证即使数据库发生异常重启之前提交的记录都不会丢失这个能力称为crash-safe。
要理解 crash-safe 这个概念可以想想我们前面赊账记录的例子。只要赊账记录记在了粉板上或写在了账本上之后即使掌柜忘记了比如突然停业几天恢复生意后依然可以通过账本和粉板上的数据明确赊账账目。
undo log
undo log 记录的是与执行SQL相反的SQL。例如在user表id为1的用户age为32那么执行update table user set age 45 where id 1那么undo log中则会记录update table user set age 32 where id 1如果执行的是delete语句那么相应的它会记录一条insert语句。 undo log是MySQL用于事务模块的重要日志其中的MVCC多版本并发控制技术就与undo log版本链强相关。这篇文章重点不在此因此不再多说。 MySQL如何做数据恢复
假如在今天的12点钟你误删了一个表。这种情况下该怎么恢复数据首先在使用MySQL时通常会对其进行全量备份。一般是一天、三天或每周一次。 那么此时应当找到最近的一次全量备份放入临时库中。 找到从全量备份的那一刻开始将bin log重放到误操作今天的12点钟。 如此你便拿到了误操作之前的数据此时你可以将临时库中的数据按需要恢复回去。
MySQL如何做到故障恢复Crash-Safe的能力 在InnoDB引擎下MySQL支持事务。因此故障恢复还需要考虑到已提交的数据与未提交的数据。单独靠bin log 或 redo log 是无法保证crash-safe的。 两阶段提交
一条update语句的简单执行过程
我们再来看执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程。 执行器先找向存储引擎找到 id 1 这一行。id 作为主键存储引擎直接用B树搜索找到这一行。如果id1 这行所在的数据页已经在内存中就直接返回给执行器否则就先从磁盘读入内存中再返回。 执行器拿到存储引擎给的行数据把这个值加上 1比如原来是 n现在为 n1得到了一行新的数据再调用存储引擎的接口写入这一行新的数据。 引擎将这行新数据更新到内存中同时将这个更新操作记录到 redo log 里面此时 redo log 处于 prepare 状态。 执行器生成这个操作的 binlog并把 binlog 写入磁盘。 执行器调用引擎的提交事务接口引擎把刚刚写入的 redo log 改成提交commit状态。 最后三步看起来有点复杂InnoDB将 redo log 的写入分为了两个步骤prepare阶段和commit阶段这就是两阶段提交。
图中白色框表示是在 InnoDB引擎内部执行的绿色框表示的是在执行器中执行的。
为什么日志需要“两阶段提交”。
由于 redo log 与 bin log 是两个层单独的日志如果不采用两阶段提交的方式要么是先写 redo log 再写 bin log或采用反的顺序。
下面看看这两种方式会出现什么问题。
仍然使用用前面的 update 语句来做例子。假设当前 id1 的行字段 a 的值是 0再假设执行 update 语句过程中在写完第一个日志后第二个日志还没有写完期间发生了 crash会出现什么情况呢 先写 redo log 后写 binlog。假设在 redo log 写完binlog 还没有写完的时候MySQL 进程异常重启。由于我们前面说过的redo log 写完之后系统即使崩溃仍然能够把数据恢复回来所以恢复后这一行 a 的值是 1。但是由于 binlog 没写完就 crash 了这时候 binlog 里面就没有记录这个语句。因此之后备份日志的时候存起来的 binlog 里面就没有这条语句。然后你会发现如果需要用这个 binlog 来恢复临时库的话由于这个语句的 binlog 丢失这个临时库就会少了这一次更新恢复出来的这一行 a 的值就是 0与原库的值不同。 先写 binlog 后写 redo log。如果在 binlog 写完之后 crash由于 redo log 还没写崩溃恢复以后这个事务无效所以这一行 a 的值是 0。但是 binlog 里面已经记录了 “把 a 从 0 改成 1” 这个日志。所以在之后用 binlog 来恢复的时候就多了一个事务出来恢复出来的这一行 a 的值就是 1与原库的值不同。
可以看到如果不使用“两阶段提交”那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
简单说redo log 和 binlog 都可以用于表示事务的提交状态而两阶段提交就是让这两个状态保持逻辑上的一致。
总结 学习了挺久的MySQL突然又对其的数据恢复和故障恢复起了兴趣往深入了解又发现了之前一些之前无法理解的问题突然迎刃而解了。 MySQL的数据恢复与故障恢复依赖着几个日志bin log 与 redo log。bin log 是逻辑日志记录的是原始SQL语句redo log 是InnoDB引擎支持的是物理日志记录了在哪个数据页修改了哪些数据并且redo log 是循环写日志。 MySQL需要按照一定时间进行全量备份这样我们可以依靠最近一次全量备份点以及从该点开始记录的bin log进行数据重放恢复 MySQL在使用了InnoDB引擎后支持了事务因此故障恢复需要确保可以区分已提交事务与未提交事务。这个依赖于redo log 的二阶段提交。
