Was sind die Unterschiede zwischen Redo-Log und Binlog in MySQL?

Ich möchte mit Ihnen über zwei kleine Wissenspunkte in MySQL sprechen: redo log und binlog. redo log 和 binlog 。

redo log ：InnoDB 存储引擎层方面的日志，所以如果你使用的存储引擎不是 InnoDB 的话，那就根本谈不上 redo log。

binlog ： MySQL Server 层记录的日志，所以不管是用的什么存储引擎，只要是 MySQL 都是会有 binlog 的存在，在做 MySQL 主从复制的时候，利用的就是 binlog。

接下来，我们就详细来看看它们都分别做了啥？

redo log

为什么要有这个 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

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 log: Protokoll der InnoDB-Speicher-Engine-Ebene. Wenn die von Ihnen verwendete Speicher-Engine also nicht InnoDB ist, gibt es überhaupt kein Redo-Log. 🎜🎜binlog: Das von der MySQL-Serverschicht aufgezeichnete Protokoll. Unabhängig davon, welche Speicher-Engine verwendet wird, gibt es bei der MySQL-Master-Slave-Replikation ein Binlog. Es wird Binlog verwendet. 🎜🎜Als nächstes schauen wir uns an, was sie im Detail tun? 🎜

Redo-Log

🎜🎜

🎜Warum brauchen wir diese Redo-Log-Datei? 🎜

🎜Hier können wir die Daten in der Datenbank ändern. Im Allgemeinen wird die Aktualisierungsoperation von einer Abfrageoperation begleitet. und dann machen wir das Update, oder? 🎜🎜Wenn die Datenmenge relativ klein ist, ist es in Ordnung, sie kann schnell gefunden und aktualisiert werden, aber was ist, wenn die Datenmenge relativ groß ist und 100 Millionen Daten enthält? Darüber hinaus muss der Aktualisierungsvorgang auf die Festplatte geschrieben werden. Wie hoch sind also die IO-Kosten in der Mitte? 🎜🎜Was ist, wenn ich Dutzende von Update-Anweisungen nacheinander aktualisieren muss? Wenn Sie so darüber nachdenken, können Sie sich vorstellen, dass die Kosten dieser Operationen sehr hoch sind. Können diese Kosten also gesenkt werden? 🎜🎜Zu diesem Zeitpunkt kommt das Redo-Log ins Spiel. Wenn ein Datensatz aktualisiert wird, schreibt die InnoDB-Engine den Datensatz zunächst in das Redo-Protokoll und aktualisiert gleichzeitig den Speicher, sodass die Daten erfolgreich aktualisiert werden. 🎜🎜Aber zu diesem Zeitpunkt wurde es noch nicht auf der Festplatte aktualisiert, oder? Keine Sorge, InnoDB wird diesen Datensatz zu gegebener Zeit auf der Festplatte aktualisieren. 🎜🎜Diese Art von Idee oder Technologie hat einen richtigen Namen: WAL-Technologie, die WriteAheadLogging ist. Der Kern besteht darin, zuerst das Protokoll und dann auf die Festplatte zu schreiben. 🎜

🎜Redo-Protokoll Sie können nicht weiter schreiben? 🎜

🎜Die Größe des Redo-Logs ist festgelegt und der vorherige Inhalt wird überschrieben. Sobald es voll ist, wird die Synchronisierung des Redo-Logs mit der Festplatte ausgelöst, um Platz für die Aufzeichnung nachfolgender Änderungen zu schaffen. 🎜

🎜Auch wenn die Datenbank heruntergefahren oder neu gestartet wird, gehen die Daten nicht verloren. 🎜

🎜Aufgrund des Redo-Logs sind die zuvor übermittelten Datensätze immer noch vorhanden. Sie müssen sie nur entsprechend den Datensätzen im Redo-Log wiederherstellen. 🎜

binlog

🎜binlog ist das Aufzeichnungsprotokoll der MySQL-Serverschicht. 🎜🎜Der Unterschied zwischen Redo-Log und Binlog: 🎜

• 🎜Redo-Log ist einzigartig für die InnoDB-Engine; es wird von der Serverschicht von MySQL implementiert und ist für alle verfügbar Motoren. 🎜
• 🎜Redo-Protokoll ist ein physisches Protokoll, das „XXX-Änderungen wurden auf XXX-Seite vorgenommen“ aufzeichnet; Binlog ist ein logisches Protokoll, wie zum Beispiel „Füge 1 zum c-Feld der Zeile mit der ID = 2 hinzu.“ ". 🎜
• 🎜Das Redo-Protokoll hat eine feste Größe, sodass der Speicherplatz erschöpft ist. Wenn der Speicherplatz erschöpft ist, müssen Sie einige Schreibvorgänge auf der Festplatte ausführen, bevor Sie mit dem Schreiben fortfahren können Binlog hat kein Raumkonzept, schreibe einfach weiter. 🎜

🎜binlog zeichnet alle DDL- und DML-Anweisungen in Form von Ereignissen auf (da es Vorgänge statt Datenwerte aufzeichnet, handelt es sich um ein logisches Protokoll) und kann für die Master-Slave-Replikation verwendet werden und Datenwiederherstellung. 🎜🎜Wenn die Binlog-Funktion aktiviert ist, können wir das Binlog in SQL-Anweisungen exportieren und alle Vorgänge wiedergeben, um eine Datenwiederherstellung zu erreichen. 🎜

🎜Nachdem wir diese beiden Protokolle haben, werfen wir einen Blick darauf, wie eine Update-Anweisung ausgeführt wird (Redo kann nicht auf einmal geschrieben werden): 🎜

🎜🎜🎜Zum Beispiel eine Anweisung: update user set name=' small Ma' where id=1;🎜

• 🎜Fragen Sie zuerst diese Daten ab. Wenn ein Cache vorhanden ist, wird dieser auch verwendet. 🎜
• 🎜Ändern Sie den Namen in 小马, rufen Sie dann die API-Schnittstelle der Engine auf, schreiben Sie diese Datenzeile in den Speicher und zeichnen Sie gleichzeitig das Redo-Protokoll auf. Zu diesem Zeitpunkt wechselt das Redo-Protokoll in den Vorbereitungsstatus und teilt dem Ausführenden dann mit, dass die Ausführung abgeschlossen ist und jederzeit übermittelt werden kann. 🎜
• 🎜Nach Erhalt der Benachrichtigung zeichnet der Executor das Binlog auf, ruft dann die Storage-Engine-Schnittstelle auf und setzt das Redo-Log in den Commit-Status. 🎜
• 🎜Update abgeschlossen. 🎜

🎜Sie können feststellen, dass sich das Redo-Protokoll zuerst im Vorbereitungszustand befindet und sich nach Abschluss des Binlogs im Festschreibungszustand befindet. Diese Methode wird als „zweistufiges Festschreiben“ bezeichnet ". Warum ist das so? 🎜

🎜 Sowohl Redo-Log als auch Binlog können verwendet werden, um den Festschreibungsstatus einer Transaktion darzustellen, und zweiphasiges Festschreiben dient dazu, diese beiden Zustände logisch konsistent zu halten. 🎜

Sie können davon ausgehen, dass was passieren wird, wenn Sie diese Methode nicht verwenden, sondern zuerst das Redo-Protokoll und dann das Binlog schreiben? Wenn beim Schreiben des Binlogs eine Ausnahme auftritt und der Aktualisierungsvorgang im Redo-Log ausgeführt wurde, das Binlog jedoch zu diesem Zeitpunkt nicht aktualisiert wird, liegt dann eine Dateninkonsistenz vor?

Das Gleiche gilt für das Schreiben des Binlogs und dann des Redo-Logs. Versetzen Sie daher beim Schreiben zunächst das Redo-Protokoll in den Vorbereitungsstatus und versetzen Sie das Redo-Protokoll nach Abschluss des Binlog-Schreibvorgangs in den Festschreibungsstatus, um die logische Konsistenz aufrechtzuerhalten.

Das obige ist der detaillierte Inhalt vonWas sind die Unterschiede zwischen Redo-Log und Binlog in MySQL?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!