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

4.9 KiB
Raw Blame History

aliases tags date zero-link parents linked
InnoDB
maturity/🌱
2024-05-28
../../../meta/zero/00 MySQL
../garden/ru/dev/database/mysql/Архитектура MySQL
Репликация в MySQL

Изначально в MySQL не было никаких журналов. Был движок MyISAM, а в нем журнала нет.

На рисунке вы можете видеть штуку, которая называется Storage Engines: это такая сущность, которая занимается вопросами, как писать данные на диск и как нам их оттуда читать, как по ним искать и пр.

Потом прикрутили репликацию. Репликация это одна строчка в самом левом верхнем квадратике Management Services&Utilites. Для репликации потребовался журнал. Его начали писать. Он называется Binary Log. Никто не думал про то, чтобы его использовать как-то иначе, просто сделали.

Примерно в это же время MySQL подарили новый Storage Engine, который называется InnoDB. Это широко используемая штука, и в InnoDB свой журнал. Получилось два журнала InnoDB и Binary Log. Этот момент стал точкой невозврата, после чего появились проблемы, которые решить очень тяжело.

Binary Log не используется для Point In Time Recovery, а 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 Родитель:: Архитектура MySQL Источник:: Автор:: Создана:: 2024-05-28

Дополнительные материалы

Дочерние заметки