珠海北京网站建设,淄博周村网站建设报价,蓝色门户网站,外行怎么做网站一、什么是binlog、redo log
binlog属于逻辑日志#xff0c;是逻辑操作。innodb redo属于物理日志#xff0c;是物理变更。逻辑日志有个缺点是难以并行#xff0c;而物理日志可以比较好的并行操作。
binlog是MySQL Server层记录的日志#xff0c; redo log是InnoDB存储引…一、什么是binlog、redo log
binlog属于逻辑日志是逻辑操作。innodb redo属于物理日志是物理变更。逻辑日志有个缺点是难以并行而物理日志可以比较好的并行操作。
binlog是MySQL Server层记录的日志 redo log是InnoDB存储引擎层的日志。 两者都是记录了某些操作的日志(不是所有)自然有些重复但两者记录的格式不同。选择binlog日志作为replication
二、binlog
即二进制日志,它记录了数据库上的所有改变并以二进制的形式保存在磁盘中它可以用来查看数据库的变更历史、数据库增量备份和恢复、Mysql的复制主从数据库的复制。语句以“事件”的形式保存它描述数据更改。
因为有了数据更新的binlog所以可以用于实时备份与master/slave复制。高可用与数据恢复。
1.恢复使能够最大可能地更新数据库因为二进制日志包含备份后进行的所有更新。 2.在主复制服务器上记录所有将发送给从服务器的语句。
2.1 binlog格式
binlog有三种格式Statement、Row以及Mixed。从安全性来看ROW最安全、MIXED不推荐、STATEMENT不推荐。
–基于SQL语句的复制(statement-based replication,SBR) –基于行的复制(row-based replication,RBR) –混合模式复制(mixed-based replication,MBR)。
2.1.1 Statement
每一条会修改数据的sql都会记录在binlog中。在5.6.24中默认格式。
优点不需要记录每一行的变化减少了binlog日志量节约了IO提高性能。
缺点由于记录的只是执行语句为了这些语句能在slave上正确运行因此还必须记录每条语句在执行的时候的一些相关信息以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能slave可与master上要保持一致会有很多相关问题。
ps相比row能节约多少性能与日志量这个取决于应用的SQL情况正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量但是考虑到如果带条件的update操作以及整表删除alter表等操作ROW格式会产生大量日志因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况其所产生的日志量会增加多少以及带来的IO性能问题。
2.1.2 Row
5.1.5版本的MySQL才开始支持row level的复制,它不记录sql语句上下文相关信息仅保存哪条记录被修改。
优点 binlog中可以不记录执行的sql语句的上下文相关的信息仅需要记录那一条记录被修改成什么了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题.
缺点:所有的执行的语句当记录到日志中的时候都将以每行记录的修改来记录这样可能会产生大量的日志内容。
ps:新版本的MySQL中对row level模式也被做了优化并不是所有的修改都会以row level来记录像遇到表结构变更的时候就会以statement模式来记录如果sql语句确实就是update或者delete等修改数据的语句那么还是会记录所有行的变更。
2.1.3 Mixed
从5.1.8版本开始MySQL提供了Mixed格式实际上就是Statement与Row的结合。
在Mixed模式下一般的语句修改使用statment格式保存binlog如一些函数statement无法完成主从复制的操作则采用row格式保存binlogMySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式也就是在Statement和Row之间选择一种。
2.1.4 查看与配置binlog格式
查看binlog_format
show variables like binlog_format 三、Undo Log
Undo Log是为了实现事务的原子性在MySQL数据库InnoDB存储引擎中还用UndoLog来实现多版本并发控制(简称MVCC)。 -事务的原子性(Atomicity) 事务中的所有操作要么全部完成要么不做任何操作不能只做部分操作。如果在执行的过程中发了错误要回滚(Rollback)到事务开始前的状态就像这个事务从来没有执行过。
-原理 Undo Log的原理很简单为了满足事务的原子性在操作任何数据之前首先将数据备份到一个地方这个存储数据备份的地方称为UndoLog。 然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句系统可以利用UndoLog中的备份将数据恢复到事务开始之前的状态。 除了可以保证事务的原子性Undo Log也可以用来辅助完成事务的持久化。
-事务的持久性(Durability) 事务一旦完成该事务对数据库所做的所有修改都会持久的保存到数据库中。为了保证持久性数据库系统会将修改后的数据完全的记录到持久的存储上。
-用Undo Log
实现原子性和持久化的事务的简化过程
假设有A、B两个数据值分别为1,2。 A.事务开始. B.记录A1到undolog. C.修改A3. D.记录B2到undolog. E.修改B4. F.将undolog写到磁盘。 G.将数据写到磁盘。 H.事务提交 这里有一个隐含的前提条件‘数据都是先读到内存中然后修改内存中的数据最后将数据写回磁盘’。 之所以能同时保证原子性和持久化是因为以下特点 A.更新数据前记录Undo log。 B.为了保证持久性必须将数据在事务提交前写到磁盘。只要事务成功提交数据必然已经持久化。 C.Undo log 必须先于数据持久化到磁盘。如果在G,H之间系统崩溃undo log是完整的可以用来回滚事务。
D.如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
缺陷每个事务提交前将数据和Undo Log写入磁盘这样会导致大量的磁盘IO因此性能很低。 如果能够将数据缓存一段时间就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化即Redo log
四、Redo log
记录的是新数据的备份。在事务提交前只要将Redo Log持久化即可不需要将数据持久化。当系统崩溃时虽然数据没有持久化 但是RedoLog已经持久化。系统可以根据RedoLog的内容将所有数据恢复到最新的状态。
InnoDB有buffer pool简称bp。bp是数据库页面的缓存对InnoDB的任何修改操作都会首先在bp的page上进行然后这样的页面将被标记为dirty并被放到专门的flush list上后续将由master thread或专门的刷脏线程阶段性的将这些页面写入磁盘disk or ssd。这样的好处是避免每次写操作都操作磁盘导致大量的随机IO阶段性的刷脏可以将多次对页面的修改merge成一次IO操作同时异步写入也降低了访问的时延。然而如果在dirty page还未刷入磁盘时server非正常关闭这些修改操作将会丢失如果写入操作正在进行甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生Innodb将所有对页面的修改操作写入一个专门的文件并在数据库启动时从此文件进行恢复操作这个文件就是redo log file。这样的技术推迟了bp页面的刷新从而提升了数据库的吞吐有效的降低了访问时延。带来的问题是额外的写redo log操作的开销顺序IO当然很快以及数据库启动时恢复操作所需的时间。
