Почему нам все еще нужен журнал повторов innodb, когда binlog mysql включен?

Насколько я понимаю, mysql binlog может полностью функционировать как журнал повторов InnoDB.

Итак, после включения бинлога, почему InnoDB должен одновременно писать журнал повторов, а не просто переключаться на использование бинлога? Разве это не сильно снижает скорость записи в базу данных?

Помимо упрощения дизайна и реализации, есть ли в этом какая-то польза?

Насколько я знаю, чтобы включить два журнала одновременно, поскольку гарантируется соответствие ACID, возникнут следующие проблемы:

  1. Каждая запись журнала с одинаковым значением должна быть записана дважды отдельно.
  2. Сбрасывать два журнала каждый раз, когда фиксируется транзакция или группа транзакций.
  3. Чтобы обеспечить согласованность между двумя файлами журналов, используется сложный и неэффективный способ, такой как XA (2PC).

Таким образом, все другие продукты, по-видимому, используют только один набор журналов (SQL Server, называемый журналом транзакций, ORACLE, называемый журналом повторов, и PostgreSQL, называемый WAL) для выполнения всей необходимой работы. Только ли MySQL должен одновременно открывать два набора журналов, чтобы обеспечить соответствие требованиям ACID и строгую непротиворечивую репликацию master-slave?

Есть ли способ реализовать совместимость с ACID и строго согласованную полусинхронную репликацию, когда включен только один из них?


mysql mariadb transactions innodb acid
person ASBai    schedule 18.09.2019    source источник

Ответы (1)


arrow_upward
14
arrow_downward

Это интересная тема. В течение долгого времени я отстаивал идею объединения журнала упреждающей записи InnoDB и бинлога. Самая большая мотивация для этого будет заключаться в том, что исчезнет необходимость синхронизации двух отдельных журналов. Но, боюсь, что это может произойти не скоро.

В MariaDB мы предпринимаем некоторые шаги, чтобы уменьшить накладные расходы fsync(). Идея восстановления транзакций механизма MDEV-18959 с помощью постоянного двоичного журнала состоит в том, чтобы гарантировать, что двоичный журнал никогда не отставать от журнала повторов InnoDB и, таким образом, обеспечить надежную и безопасную фиксацию транзакции только с одним вызовом fsync() в файле binlog.

В то время как binlog реализует логическую регистрацию, журнал повторов InnoDB реализует физическую регистрацию (охватывающую изменения постоянных страниц данных, которые реализуют журналы отмены и деревья индексов). Как я объяснял в M|18 Deep Dive: InnoDB Transactions and Write Paths, пользовательская транзакция делится на несколько мини- транзакции, каждая из которых может атомарно изменять несколько страниц данных.

Журнал повторов — это «клей», который делает изменения на нескольких страницах данных атомарными. Я думаю, что журнал повторов абсолютно необходим для реализации атомарных изменений структур данных с обновлением на месте. Файловые структуры данных только для добавления, такие как LSM-деревья, могут быть журналами сами по себе и не обязательно нуждаются в отдельном журнале.

Для таблицы InnoDB, которая содержит вторичные индексы, каждая отдельная операция строки фактически делится на несколько мини-транзакций, работающих с каждым индексом отдельно. Таким образом, уровень транзакций требует большего «клея», который делает индексы таблицы согласованными друг с другом. Этот «клей» обеспечивается журналом отмен, реализованным на постоянных страницах данных.

InnoDB вносит изменения в страницы индекса заранее, а фиксация — это быстрая операция, просто изменяющая состояние транзакции в заголовке журнала отмены. Но откат обходится очень дорого, потому что журнал отмены придется воспроизводить в обратном порядке (и будет записано больше журнала повторного выполнения, чтобы охватить эти изменения страницы индекса).

В MariaDB Server MyRocks — это еще один механизм хранения транзакций, который делает обратное: буферизует изменения в памяти до самого конца, а при фиксации применяет их к файлам данных. Это делает откат очень дешевым, но размер транзакции ограничен объемом доступной памяти. Я понял, что MyRocks можно заставить работать так, как вы предлагаете.

person Marko Mäkelä    schedule 18.09.2019
comment
Привет, Марко, спасибо за хороший и исчерпывающий ответ. Но независимо от того, какой механизм хранения, совместимый с ACID, вы используете, binlog вызовет дополнительные записи, верно? Кажется, что только отключив binlog и реплицируя напрямую через журнал повторов, можно полностью избежать этих дополнительных накладных расходов? Я нашел это: medium.com/@Alibaba_Cloud/ Могут ли аналогичные функции появиться в основных дистрибутивах, таких как mariadb? - person ASBai; 18.09.2019
comment
@ASBai Ты прав. В течение многих лет я отстаивал идею записи всех событий журнала в один файл. В jira.mariadb.org/browse/MDEV-12353 я работаю над новым Формат журнала повторов InnoDB, который позволяет добавлять «внешние» события журнала. Более простой код для синтаксического анализа и применения журнала также может упростить реализацию физической репликации (без binlog). - person Marko Mäkelä; 31.01.2020
comment
Я думаю, что это большое улучшение, и я должен проголосовать за него :-) - person ASBai; 12.02.2020