---
aliases:
  - MySQL
tags:
  - type/zero-link
zero-link:
  - "[[00 Базы Данных]]"
---
- [Репликация в MySQL](Репликация%20в%20MySQL.md)
- [libslave](libslave.md)
- [Бекап в MySQL](Бекап%20в%20MySQL.md)

## Архитектура MySQL
![](Pasted%20image%2020240613195204.png)
![](Pasted%20image%2020240528082025.png)

Есть логический слой под названием MySQL, который занимается всяким общими и изолированными от хранения данных делами – сеть, оптимизатор, кэши и т.д. Конкретный физический слой, который отвечает за хранение данных, лежит на этаж ниже. Есть несколько встроенных, есть ставящиеся плагинами. Но даже встроенные MyISAM, InnoDB и т.д. живут на физическом слое. Плагинная архитектура позволяет устанавливать новый движок, но мгновенно возникает неоптимальность. В принципе, транзакционные write-ahead log'и (WAL), которые физический слой хранения все равно пишет, было бы хорошо использовать для репликации, и если система знает о том, что есть некий физический уровень, или достаточно хорошо сопряжена с этим физическим уровнем, то можно было бы отдельный лог на логическом уровне не писать, а использовать тот же самый WAL. Но у MySQL это невозможно концептуально, либо, если поменять интерфейс в PSE так, чтобы стало возможно концептуально, то будет очень много работы.

- [Журналы в MySQL](Журналы%20в%20MySQL.md)
## Идентификация транзакций
До версии 5.5 идентифицировать транзакцию можно было только по имени файла и позиции в этом файле. Потом появились GTID, но надо явно включить gtid_mode =ON. C 5.6.5 GTID используется по умолчанию.

binary log position:
- Пример: mysql-bin.00078:44
- Локальный для сервера
- Обязательно сломается

GTID:
- Пример: 7F33BC78-56CA-44B3-5E33-B34CC7689333:44
- Глобален, генерируется автоматически при коммите
- Бесплатная трассировка
- Простой slave promotion
- ==Используйте его==

## Заметки
- MySQL пишет на диск в три места – хранилище (tablespace), журнал (undo/redo log), и Binary Log
- mariadb -Форк Mysql, который пытается исправить архитектурные ошибки MySQL