В основе любой технологии лежат ключевые базовые технологии. Эти ключевые технологии, скорее всего, будут ключевыми технологиями для других технологий. Изучение этих базовых технологий может помочь вам быстро освоить другие технологии. Как хранить данные на диске, как использовать файлы журналов, чтобы данные не были потеряны, и как разместить их на диске — это не только ключевые технологии для таких баз данных, как MySQL, но и одна из ключевых технологий для очередей сообщений MQ или другое промежуточное ПО.
Основные дисковые файлы InnoDB в основном разделены на три блока: один — системное табличное пространство, другой — пользовательское табличное пространство, а третий — файл журнала повторов и файл архива. Файлы, такие как двоичные файлы (binlog), являются файлами, поддерживаемыми уровнем сервера MySQL, поэтому они не включены в дисковые файлы InnoDB.
Системное табличное пространство и пользовательское табличное пространство
Системное табличное пространство InnoDB содержит словарь данных InnoDB (метаданные и связанные объекты) и область хранения для буфера двойной записи, буфера изменений, журналов отмены. Системное табличное пространство также содержит по умолчанию табличные данные и данные индекса, созданные любым пользователем в системном табличном пространстве. Системное табличное пространство является общим табличным пространством, поскольку оно совместно используется несколькими таблицами.
Системное табличное пространство состоит из одного или нескольких файлов данных. По умолчанию файл системных данных с начальным размером 10 МБ с именем ibdata1 создается в каталоге данных MySQL. Пользователи могут использовать innodb_data_file_path для настройки размера и количества файлов данных.
Формат innodb_data_file_path выглядит следующим образом:
innodb_data_file_path=datafile1[,datafile2]...
Пользователи могут формировать табличное пространство из нескольких файлов и одновременно указывать атрибуты файлов:
innodb_data_file_path = /db/ibdata1:1000M;/dr2/db/ibdata2:1000M:autoextend
Здесь два файла /db/ibdata1 и /dr2/db/ibdata2 образуют системное табличное пространство. Если два файла находятся на разных дисках, нагрузка на диски может быть усреднена, что повышает общую производительность базы данных. За именами двух файлов следуют атрибуты, указывающие, что размер файла ibdata1 составляет 1000 МБ, а размер файла ibdata2 — 1000 МБ, и он может автоматически увеличиваться (авторасширяться) после исчерпания места.
После установки параметра innodb_data_file_path данные таблицы на основе механизма хранения InnoDB будут записаны в системное табличное пространство.Если установлен параметр innodb_file_per_table, пользователь может создать независимое пользовательское табличное пространство для каждой таблицы на основе механизма хранения InnoDB. Правила именования для пользовательских табличных пространств: tablename.ibd. Таким образом, пользователю не нужно хранить все данные в системном табличном пространстве по умолчанию, но пользовательское табличное пространство хранит только данные, индексирует и вставляет буфер BITMAP и другую информацию таблицы, а остальная информация по-прежнему хранится в табличное пространство по умолчанию.
На приведенном выше рисунке показано, как механизм хранения InnoDB хранит файлы.Файл frm представляет собой файл определения структуры таблицы, в котором записано определение структуры каждой таблицы.
Файлы журнала повторов и архивные файлы
По умолчанию в каталоге данных механизма хранения InnoDB будет два файла с именами ib_logfile0 и ib_logfile1.Это файл журнала повторов InnoDB, который записывает журнал транзакций для механизма хранения InnoDB. Файлы журнала повторного выполнения пригодятся, когда файлы хранилища данных InnoDB терпят неудачу. Механизм хранения InnoDB может использовать файлы журналов повторного выполнения для восстановления данных в правильное состояние, чтобы гарантировать правильность и целостность данных.
Каждый механизм хранения InnoDB имеет по крайней мере одну группу (группу) файлов журналов повторного выполнения, и каждая файловая группа имеет как минимум два файла журнала повторного выполнения, например файлы по умолчанию ib_logfile0 и ib_logfile1. Для повышения надежности пользователи могут настроить несколько групп зеркальных журналов и поместить разные группы файлов на разные диски, чтобы повысить доступность журналов повторного выполнения.
Размер каждого файла журнала повторов в группе журналов одинаков, и он работает в режиме циклической записи. Механизм хранения InnoDB сначала записывает в файл журнала повторов 1. Когда файл заполнен, он переключается на файл журнала повторов 2. Когда файл журнала повторов 2 также полон, он переключается на файл журнала повторов 1.
Пользователи могут использовать innodb_log_file_size для установки размера файла журнала повторов, что оказывает большое влияние на производительность механизма хранения InnoDB.
Если файл журнала повторов задан слишком большим, восстановление после потери данных может занять много времени; с другой стороны, если файл журнала повторов задан слишком маленьким, это вызовет частую очистку грязных страниц на основе проверок контрольных точек. .. на диск, вызывая колебания производительности. Журнал повторов и механизм Checkpoint можно прочитать в соответствующей главе моей предыдущей статьи.Тайна MySQL (3): структура памяти и особенности InnoDB
Механизм сброса журнала повторов
InnoDB соответствует правилам WAL (упреждающая запись в журнал повторов) и Force-log-at-commit для файлов данных и файлов журналов, которые обеспечивают надежность транзакций. WAL требует, чтобы перед записью изменений данных на диск сначала был записан журнал в памяти; Force-log-at-commit требует, чтобы при фиксации транзакции все сгенерированные журналы были сброшены на диск, если журнал After сброс выполняется успешно, происходит сбой базы данных до того, как данные из пула буферов будут сброшены на диск, и база данных может восстановить данные из журнала при перезапуске.
Как показано на рисунке выше, когда InnoDB изменяет данные в пуле буферов, она сначала запишет соответствующие изменения в буфер журнала повторов, а затем запишет на диск вовремя или после фиксации транзакции, что соответствует принудительному принцип log-at-commit; после того, как журнал повторов будет записан на диск, измененные данные в пуле буферов будут записаны на диск по механизму контрольных точек, который соответствует принципу WAL. В механизме синхронизации контрольной точки есть мнение, что файл журнала повторов заполнен, поэтому, как упоминалось выше, если файл журнала повторов слишком мал и часто полон, это часто приводит к тому, что контрольная точка записывает измененные данные на диск. , что приводит к дрожанию производительности.
Файловая система операционной системы кэшируется.Когда InnoDB записывает данные на диск, они могут быть записаны только в кэш файловой системы, и настоящей «безопасности» нет. Атрибут InnoDB innodb_flush_log_at_trx_commit может управлять поведением InnoDB каждый раз, когда транзакция фиксируется. Когда значение атрибута равно 0, когда транзакция зафиксирована, журнал повторов не будет записываться, а будет ждать, пока основной поток запишет вовремя; когда значение атрибута равно 1, когда транзакция зафиксирована, журнал повторов будет быть записаны в файл Система кэширует и вызывает fsync файловой системы для фактической записи данных из буфера файловой системы в дисковое хранилище, чтобы гарантировать отсутствие потери данных; когда значение атрибута равно 2, файл журнала будет также быть записаны в файловую систему, когда транзакция фиксируется кешем, но fsync не вызывается, оставляя файловой системе решать, когда записывать кеш на диск. Механизм сброса журнала показан на рисунке ниже.
innodb_flush_log_at_commit — это базовый параметр для настройки производительности InnoDB, который включает в себя эффективность записи InnoDB и безопасность данных. При значении параметра 0 эффективность записи самая высокая, но безопасность данных самая низкая; при значении параметра 1 эффективность записи самая низкая, но безопасность данных самая высокая; при значении параметра 2 , оба средние. Обычно рекомендуется устанавливать значение этого свойства равным 1, чтобы обеспечить более высокий уровень безопасности данных, и только при значении 1 можно гарантировать надежность транзакции.
постскриптум
В будущем мы изучим механизм размещения файла binlog и файла данных, а также другие знания, связанные с транзакциями InnoDB, пожалуйста, продолжайте обращать внимание.