Как именно движок InnoDB в MySQL обновляет свои основные файлы хранения данных?

251
mike rodent

В ходе тестирования утилиты резервного копирования Linux In In Time мне стало известно, что я не могу понять, как MariaDB на самом деле сохраняет данные.

После добавления фиктивной записи в таблицу и оставления ее до следующего снимка я с удивлением обнаружил, что восстановление более старого снимка (сделанного до добавления фиктивной записи) не привело к удалению фиктивной записи.

Я попробовал это еще два раза: добавлена ​​фиктивная новая запись, происходит моментальный снимок (автоматически, потому что это то, что я сказал Back In Time) ... и восстановление не делает то, что я ожидал.

Глядя на настоящие файлы «Modified by», в главном каталоге (где все базы данных являются подкаталогами) я обнаружил, что изменились только два файла: ib_logfile0иib_logfile1 . При настройке моей работы Back In Time я сознательно пропустил их из конфигурации, потому что я предположил, что они были «просто журналами». Ясно, что нет.

Чтобы решить мою непосредственную проблему, кажется, что все, что мне нужно сделать, это включить эти два файла в мои снимки. Но как или каким образом ibdata1обновляется новая информация? Возможно, когда служба MySQL закрыта? Или пустили?

Что странно, так это то, что я не нахожу много информации об этом.

0
Эта проблема не столько в MySQL, сколько в методах, используемых механизмом хранения InnoDB. Насколько я знаю, вам даже не нужно копировать файлы `ibdata1`,` ib_logfile0` и `ib_logfile1`. Просто закройте MySQL, удалите эти файлы, и MySQL просто перестроит их при перезапуске. JakeGould 6 лет назад 0
Спасибо ... это полезная подсказка. Специфично для InnoDB, хорошо. Выключи и удали, ОК. Но для непрерывного процесса создания снимков во время работы с базой данных, очевидно, необходимо сохранять снимки разных версий `ib_logfile0 / 1` ... Вы, похоже, подразумеваете, что MySQL действительно обновляет` ibdata1`, когда он выключается ... но что происходит в случае жестокого отключения машины? Очевидно, я сам могу провести эксперименты, чтобы попытаться найти ответы ... mike rodent 6 лет назад 0
Исправление: требуется `ibdata1`. `ib_logfile0` и` ib_logfile1` не являются. JakeGould 6 лет назад 0
Майк - я расскажу вам, какую конфигурацию я предпочитаю с MySQL InnoDB Engine - это [Табличные пространства файлов на таблицы] (https://dev.mysql.com/doc/refman/5.7/en/innodb-file-per-table -intro.html) .... гораздо больше гибкости, когда вы начнете использовать это. Это буквально файл на конфигурацию таблицы .... Сумасшедший !!! Pimp Juice IT 6 лет назад 0

1 ответ на вопрос

0
danblack

Вы не можете использовать универсальную утилиту резервного копирования, такую ​​как Back in Time, для резервного копирования баз данных.

Как вы обнаружили, вам нужен согласованный снимок файлов базы данных, чтобы иметь работоспособную резервную копию. Без этого вы получите что-то неправильное или просто не запускающееся. Проблема в том, что ib_logfile*они временно хранятся, а затем переносятся в табличные пространства. Вы можете удалить их, только если вы чисто завершили работу (что больше, чем systemctl stop mysqld), чего, очевидно, не произошло, когда вы делали резервную копию.

Таким образом, вкратце для MySQL, используйте программу резервного копирования, которая знает о MySQL (mysqldump, mydumper, xtrabackup), или инструмент согласованных снимков (llvm моментальные снимки или согласованные функции моментальных снимков на основе файловой системы) или подчиненный репликации один из предыдущих методов.

Возникновение файлов данных MySQL извне MySQL приведет только к потере данных. Не делай этого.

Спасибо ... как я начинаю понимать: целая банка червей. Что происходит, когда машина с базами данных MySQL получает жестокое отключение питания, например, не имеющее ничего общего с волевым действием пользователя? Я уверен, что есть ответы там, и я должен попытаться искать (снова). Я непременно попробую поискать в этих "инструментах для создания моментальных снимков". У вас нет полезных ссылок? Или намеки на то, какие протоколы вы лично используете? mike rodent 6 лет назад 0
MySQL, как и другие базы данных, основывается на принципах ACID, в основном это долговечность. Жестокая сила - это форма моментального снимка. Достаточное состояние было принято, поэтому каждая транзакция, возвращенная пользователю как успешная, будет существовать в файлах журнала innodb, которые будут воспроизводиться / применяться при перезапуске службы. Журнал отмены транзакций в процессе откатывается. Можно использовать снимок lvm (не так, как я опечатал), mysqldump имеет --single-транзакцию, размер базы данных, пропускную способность io, приемлемое время восстановления - все играют роль в использовании механизма (ов). Я предлагаю новый вопрос :-) danblack 6 лет назад 0