digital-garden/dev/database/mysql/Журналы в MySQL.md

66 lines
4.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
aliases:
- InnoDB
tags:
- maturity/🌱
date:
- - 2024-05-28
zero-link:
- "[[../../../meta/zero/00 MySQL|00 MySQL]]"
parents:
- "[[../garden/ru/dev/database/mysql/Архитектура MySQL|Архитектура MySQL]]"
linked:
- "[[Репликация в MySQL]]"
---
Изначально в MySQL не было никаких журналов. Был движок MyISAM, а в нем журнала нет.
![](Pasted%20image%2020240528082025.png)
На рисунке вы можете видеть штуку, которая называется Storage Engines: это такая сущность, которая занимается вопросами, как писать данные на диск и как нам их оттуда читать, как по ним искать и пр.
Потом прикрутили репликацию. Репликация это одна строчка в самом левом верхнем квадратике Management Services&Utilites. Для репликации потребовался журнал. Его начали писать. Он называется Binary Log. Никто не думал про то, чтобы его использовать как-то иначе, просто сделали.
Примерно в это же время MySQL подарили новый Storage Engine, который называется InnoDB. Это широко используемая штука, и в InnoDB свой журнал. Получилось два журнала InnoDB и Binary Log. Этот момент стал точкой невозврата, после чего появились проблемы, которые решить очень тяжело.
Binary Log не используется для [Point In Time Recovery](Point%20In%20Time%20Recovery%20(PITR).md), а InnoDB Undo/Redo Log не используется в репликации. Получилось, что у PostgreSQL журнал один, а у MySQL их, как бы, два.
## InnoDB Undo/Redo Log
## Binary Log
У Binary Log, который нужен для репликации, есть два или три формата (типа).
### Statement-based Binary Log
Самый первый тип, который появился, который было проще всего сделать, это Statement-based Binary Log. Что это такое? Это просто файл, в который последовательно пишутся транзакция за транзакцией. Это выглядит примерно так:
![](Pasted%20image%2020240528082432.png)
В транзакции указывается БД, на которой совершаются эти обновления, указывается timestamp времени начала транзакции, и дальше идет сама транзакция.
### Row-based Binary Log
Второй тип называется Row-based репликация. Это журнал, в который пишутся не сами запросы, а те строчки, которые они меняют. Он состоит из двух частей BEFORE image и AFTER image:
![](Pasted%20image%2020240528082516.png)
На картинке BEFORE image сверху, а AFTER image внизу.
В BEFORE image помещаются те строчки, которые были до выполнения транзакции. Красным цветом помечены строчки, которые удаляются:
![](Pasted%20image%2020240528082538.png)
Они из BEFORE image наверху, но их нет внизу в AFTER image, значит, они удаляются.
На следующей картинке зеленым помечены строчки, которые добавились:
![](Pasted%20image%2020240528082552.png)
Синие UPDATE'ы есть и в BEFORE image, и в AFTER image. Это обновления.
Проблема такого решения связана с тем, что до недавнего времени в Row-based репликации писались в log все колонки, даже если мы обновили одну. В MySQL 5.6 это починили, и с этим должно стать полегче.
### Mixed-based
Он работает либо как Statement-based, либо как Row-based, но он широко не распространен.
***
## Мета информация
**Область**:: [[../../../meta/zero/00 MySQL|00 MySQL]]
**Родитель**:: [[Архитектура MySQL]]
**Источник**::
**Автор**::
**Создана**:: [[2024-05-28]]
### Дополнительные материалы
- [[Репликация в MySQL]]
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->