mysql의 두 가지 작은 지식 포인트인 redo log와 binlog에 대해 이야기하고 싶습니다. redo log 和 binlog 。
redo log ：InnoDB 存储引擎层方面的日志，所以如果你使用的存储引擎不是 InnoDB 的话，那就根本谈不上 redo log。
binlog ： MySQL Server 层记录的日志，所以不管是用的什么存储引擎，只要是 MySQL 都是会有 binlog 的存在，在做 MySQL 主从复制的时候，利用的就是 binlog。
接下来，我们就详细来看看它们都分别做了啥？
为什么要有这个 redo log 日志文件呢？
这里，我们可以举个例子，现在我们想对数据库的数据进行修改操作，现在一条 update 语句过来，一般 update 操作都伴随着查询的操作，得先找到这条数据，然后再进行更新操作对吧。
如果数据量比较小还好，很快就能找到并且更新完毕，但是如果数据量比较大，里面有一亿条数据，怎么办？而且更新操作肯定是要写到磁盘上去的，那这中间的 IO 成本呢？
如果我有好几十条 update 语句先后更新呢？这样想的话，你就能想到，就这些操作，成本就高的不行，那能不能降低一下这些成本呢？
这时候，redo log 就起到作用了。 当有一条记录更新的时候， InnoDB 引擎就会先把记录写到 redo log 里面去，同时更新内存，这样就算是更新这条数据成功了。
但是此时，它并没有更新到磁盘上去对吧？别担心， InnoDB 会在恰当的时候，把这条及记录更新到磁盘上去。
这样的思想或者技术，有个专有名词: WAL 技术，也就是 WriteAheadLogging ，核心就是先写日志，再写磁盘。
redo log 不能一直写吧？
redo log 的大小是固定的，前面的内容会被覆盖，一旦写满，就会触发 redo log 到磁盘的同步，以便腾出空间记录后面的修改。
数据库发生宕机或者重启，数据也将不会丢失。
因为有了 redo log ，之前提交的记录都还在，只需要根据 redo log 里面的记录进行相应恢复就可以了。
binlog 是 MySQL Server 层的记录日志。
redo log 和 binlog 的区别：
redo log 是 InnoDB 引擎特有的； binlog 是 MySQL 的 Server 层实现的，所有的引擎都是可以的。
redo log 是物理日志，记录的是”在 XXX 页上做了 XXX 修改”；binlog 是逻辑日志，比如” 给 id = 2 这一行的 c 字段加 1”。
redo log 是有固定大小的，所以它的空间会用完，如果用完的话，一定要进行一些写入磁盘的操作才可以继续；binlog 是可以追加写入的，也就是 binlog 没有空间的概念，一直写就行了。
binlog 以事件的形式记录了所有的 DDL 和 DML 语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。
在开启了 binlog 功能的情况下，我们可以把 binlog 导出成 SQL 语句，把所有的操作重放一遍，来实现数据的恢复。
有了这两个日志之后，我们来看一下一条更新语句是怎么执行的（redo 不能一次写入了）：
例如一条语句：update user set name='小马' where id=1;
先查询到这条数据，如果有缓存，也会用到缓存。
把 name 改成小马，然后调用引擎的 API 接口，写入这一行数据到内存，同时记录 redo log。这时 redo log 进入 prepare 状态，然后告诉执行器，执行完成了，可以随时提交。
执行器收到通知后记录 binlog，然后调用存储引擎接口，设置 redo log为 commit 状态。
更新完成。
你能发现 redo log 竟然是先 prepare 状态，等 binlog 写完之后，才是 commit 状态，这种方式就叫”两阶段提交”。为什么会有这种方式呢？
redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交
redo 로그: InnoDB 스토리지 엔진 계층 로그이므로 사용하는 스토리지 엔진이 InnoDB가 아닌 경우 redo 로그가 전혀 없습니다. 🎜🎜binlog: MySQL 서버 계층에서 기록하는 로그이므로 어떤 스토리지 엔진을 사용하든 MySQL이라면 MySQL 마스터-슬레이브 복제를 수행할 때 binlog가 발생합니다. binlog를 사용합니다. 🎜🎜다음으로 어떤 일을 하는지 자세히 살펴볼까요? 🎜🎜🎜이 리두 로그 파일이 필요한 이유는 무엇입니까? 🎜🎜여기서 예를 들어 보겠습니다. 이제 데이터베이스의 데이터를 수정하려고 합니다. 이제 업데이트 문이 옵니다. 일반적으로 업데이트 작업에는 쿼리 작업이 수반됩니다. 그리고 업데이트를 해볼까요? 🎜🎜데이터의 양이 상대적으로 적으면 괜찮고 빠르게 찾아 업데이트할 수 있습니다. 하지만 1억 개의 데이터가 들어갈 정도로 데이터의 양이 상대적으로 크다면 어떨까요? 게다가 업데이트 작업은 디스크에 기록해야 하는데 중간에 IO 비용은 얼마일까요? 🎜🎜연속 업데이트해야 할 업데이트 문이 수십 개 있으면 어떻게 되나요? 이렇게 생각해보면 이러한 운영 비용이 엄청나게 높다고 생각할 수 있는데, 이러한 비용을 줄일 수 있을까요? 🎜🎜이때, redo log가 작동하게 됩니다. 레코드가 업데이트되면 InnoDB 엔진은 먼저 해당 레코드를 리두 로그에 기록하고 동시에 메모리를 업데이트하므로 데이터가 성공적으로 업데이트됩니다. 🎜🎜근데 이때는 디스크에 업데이트가 안됐죠? 걱정하지 마십시오. InnoDB는 적절한 시간에 이 레코드를 디스크에 업데이트합니다. 🎜🎜이러한 아이디어나 기술에는 WAL 기술, 즉 WriteAheadLogging이라는 고유한 이름이 있습니다. 핵심은 로그를 먼저 쓴 다음 디스크에 쓰는 것입니다. 🎜
🎜redo log 계속 쓸 수 없나요? 🎜🎜리두 로그의 크기는 고정되어 있으며 이전 내용을 덮어쓰게 됩니다. 용량이 가득 차면 후속 수정 사항을 기록할 공간을 확보하기 위해 디스크에 대한 리두 로그 동기화가 시작됩니다. 🎜
🎜데이터베이스가 다운되거나 재시작되더라도 데이터는 손실되지 않습니다. 🎜🎜리두 로그로 인해 이전에 제출한 기록이 그대로 남아 있으므로, 리두 로그의 기록에 따라 복원하면 됩니다. 🎜
🎜이 두 개의 로그를 얻은 후 업데이트 문이 어떻게 실행되는지 살펴보겠습니다(redo는 한 번에 작성할 수 없음): 🎜🎜
🎜🎜예를 들어 다음 명령문은 다음과 같습니다. update user set name=' small Ma' where id=1;🎜小马로 변경한 다음 엔진의 API 인터페이스를 호출하고 이 데이터 줄을 메모리에 쓰는 동시에 redo 로그를 기록합니다. 이때 redo log는 prepare 상태로 진입한 후 executor에게 실행이 완료되어 언제든지 제출할 수 있음을 알려준다. 🎜🎜리두 로그가 먼저 준비 상태이고, 빈로그가 완료된 후에는 커밋 상태인 것을 확인할 수 있습니다. 이 방법을 "2단계 커밋"이라고 합니다. ". 왜 이런가요? 🎜🎜 redo log와 binlog는 모두 트랜잭션의 커밋 상태를 나타내는 데 사용될 수 있으며
2단계 커밋은 이 두 상태를 논리적으로 일관되게 유지하는 것입니다. 🎜이 방법을 사용하지 않고 redo log를 먼저 작성한 다음 binlog를 작성하면 어떻게 될까요? binlog 작성시 Exception이 발생하고 redo log에서 update 작업을 수행했는데, 이때 binlog가 update되지 않는다면 데이터 불일치가 있는 것인가?
binlog를 먼저 작성한 다음 redo log를 작성하는 경우에도 마찬가지입니다. 따라서 쓰기 시에는 먼저 Redo 로그를 준비 상태로 두고, binlog 쓰기가 끝난 후 리두 로그를 커밋 상태로 두어 논리적 일관성을 유지한다.
위 내용은 mysql에서 redo 로그와 binlog의 차이점은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
