66 lines
4.9 KiB
Markdown
66 lines
4.9 KiB
Markdown
|
---
|
|||
|
|
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, а в нем журнала нет.
|
|||
|
|
|
|||
|
|
|
|||
|
|
На рисунке вы можете видеть штуку, которая называется 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. Что это такое? Это просто файл, в который последовательно пишутся транзакция за транзакцией. Это выглядит примерно так:
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
В транзакции указывается БД, на которой совершаются эти обновления, указывается timestamp времени начала транзакции, и дальше идет сама транзакция.
|
|||
|
|
### Row-based Binary Log
|
|||
|
|
Второй тип называется Row-based репликация. Это журнал, в который пишутся не сами запросы, а те строчки, которые они меняют. Он состоит из двух частей – BEFORE image и AFTER image:
|
|||
|
|
|
|||
|
|
|
|||
|
|
На картинке BEFORE image сверху, а AFTER image – внизу.
|
|||
|
|
|
|||
|
|
В BEFORE image помещаются те строчки, которые были до выполнения транзакции. Красным цветом помечены строчки, которые удаляются:
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Они из BEFORE image наверху, но их нет внизу – в AFTER image, значит, они удаляются.
|
|||
|
|
|
|||
|
|
На следующей картинке зеленым помечены строчки, которые добавились:
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Синие 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) -->
|