Может быть, вы запушите код, который в конечном итоге приведет к сбою в кеше, обслуживающем данные миллионов людей,
Возможно, вы обновите приложение и в конечном итоге удалите информацию, для которой нет резервной копии,
Или, может быть, вы внесете изменение, которое «работает на вашем компьютере», но полностью лишает репозиторий системы контроля версий.

И есть масса других примеров. Я уверен, что вы сами сможете быстро назвать еще пять.

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

То есть у тех, кто работает с базами данных веб-приложений — это непонимание организации базы данных на уровне файловой системы и того, как можно реконструировать данные, даже если у вас нет стандартной резервной копии, с которой можно работать.

В этом посте я собираюсь глубоко погрузиться в организацию базы данных MySQL на уровне файловой системы, как вы можете восстановить информацию из этого файла по сравнению с файлом резервной копии, если вы окажетесь в такой ситуации, и предоставлю ссылки (или закладки), если они вам нужны.

Реконструкция данных MySQL

Чтобы было ясно, я буду говорить о базе данных MySQL, работающей в варианте операционной системы на базе *nix (так что вы смотрите на дистрибутив Linux или macOS).

Расположение файлов (которое я сейчас расскажу) будет различаться в системе на базе Windows, но вам придется обратиться к руководству MySQL или аналогичному ресурсу, чтобы найти их.

Дело в том, что прежде чем углубляться в эту статью, узнайте, где файлы находятся в вашей операционной системе. Например, если вы используете macOS, вы, скорее всего, найдете его в /usr/local/mysql/data.

Я предпочитаю использовать Homebrew, поэтому мои базы данных MySQL находятся в /usr/local/var/mysql . И, как вы можете видеть выше, вы заметите файлы с теми же именами, что и базы данных, которые есть в вашей системе. .

Как организованы базы данных

На поверхностном уровне это выглядит довольно просто. Но если вы откроете каталог, как упоминалось выше, вы обнаружите, что большая часть того, что вы видите, является каталогами, а не файлами как таковыми, в которых содержится больше информации.

Если вы углубитесь в один из каталогов, вы увидите множество файлов:

К ним относятся файлы следующих типов:

МИР
MYI
ФРМ
ВЗК

И каждый из этих типов файлов существует для каждой таблицы в базе данных.

Итак, давайте рассмотрим их более подробно, чтобы лучше понять, из чего именно состоит база данных.

1 База данных — это набор файлов

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

Но этот пост не о реляционном аспекте базы данных и не о том, как мы можем выполнять запросы к ней. (Если вам интересно, дерзайте — все это основано на исчислении кортежей .)

Вместо этого речь идет о понимании того, что для каждой таблицы существует набор файлов, которые ссылаются на информацию, содержащуюся в каждой таблице. А также

2 Понимание типов файлов

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

МД. Этот файл содержит данные, хранящиеся в строках таблицы базы данных. Этот файл тесно связан с файлом FRM.
ФРМ. Этот файл содержит данные формата таблицы (которые включают в себя такие вещи, как структура каждого столбца базы данных, тип данных, которые он содержит, и т. д.).
МИИ. Это индекс базы данных. Если вы используете базу данных MyISAM (большинство из нас использует InnoDB на данный момент), у вас будет этот файл. Кроме того, данные включают информацию о том, были ли данные закрыты надлежащим образом. Считайте, что это файл о целостности самой таблицы. Не информация внутри него, не его формат.
ВЗК. Это тип файла, связанный с таблицами базы данных InnoDB (поэтому вы можете не увидеть его в каталоге вашей базы данных). Однако если вы это сделаете, важно знать, что базы данных на основе InnoDB будут хранить информацию о каждой таблице в этом файле.

В приведенной выше информации есть еще две темы, которые стоит изучить.

MyISAM
ИнноБД

Прежде чем рассматривать каждый из них, обратите внимание, что MyISAM и InnoDB называются механизмами хранения. Звучит заманчиво, но это связано с тем, как программное обеспечение базы данных управляет операциями создания, чтения, обновления и удаления информации.

MyISAM и InnoDB: в чем разница?

Каждый из этих механизмов хранения отличается тем, как они работают с транзакциями, блокировками, откатами и поисками. Для тех, кто является администратором баз данных, вы знакомы со всем вышеперечисленным (но вы также, вероятно, не читаете это 🙃).

Не тот тип двигателя, конечно.

Для остальных из нас это то, что у нас есть:

Транзакции происходят всякий раз, когда по крайней мере два оператора, таких как SELECT и UPDATE или INSERT и DELETE, или любая комбинация этих двух (или более) используются вместе друг с другом. Таким образом, если бы вы ВЫБЕРИЛИ информацию, а затем УДАЛИЛИ результаты, у вас была бы транзакция.
- MyISAM не поддерживает транзакции. Это означает, что если «транзакция» будет прервана, это повлияет на любые данные, которые обрабатывались во время операции. Нужно сказать, что это не используется.
- InnoDB, с другой стороны, гарантирует, что изменения не будут внесены в таблицу до тех пор, пока транзакция не будет завершена. Другими словами, изменения не будут зафиксированы в базе данных.
Для каждого из механизмов хранения блокировка различается на уровне таблицы или на уровне строки. Всякий раз, когда вы выполняете запрос к таблице, MyISAM блокирует всю таблицу до завершения процесса. InnoDB, с другой стороны, будет блокировать только затронутые строки. Это важное различие, потому что оно означает, что вы можете продолжать работать с таблицей, но не с теми же строками, всякий раз, когда вы используете InnoDB.
Откаты невозможны в MyISAM. Это означает, что как только изменение сделано, оно сделано. InnoDB предлагает откаты. Итак, допустим, вы внесли изменения в таблицу, вы случайно сделали что-то, чего не хотели делать, тогда вы можете откатить ее до прежнего состояния. Однако это не следует путать с резервным копированием. Это больше похоже на операцию «отмены» для транзакции.
Поиск, особенно в том, как мы структурируем наши базы данных, играет ключевую роль в том, как мы организуем данные в наших базах данных. Проще говоря, InnoDB поддерживает полнотекстовое индексирование (начиная с MySQL 5.6.4). Но если ваш хост или провайдер не разрешает использовать индексы FULLTEXT, я бы сказал, что это не нарушение условий сделки.

Учитывая всю приведенную выше информацию, каждый должен видеть, что преимущества механизма хранения InnoDB намного перевешивают преимущества механизма хранения MyISAM, особенно если вы используете версию MySQL, по крайней мере, равную 5.6.4.

3 Воссоздание базы данных

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

Возможно, это предыдущая резервная копия, возможно, вы можете найти файлы на диске или, возможно, вы можете получить их каким-либо другим способом — и вам нужно восстановить базу данных до предыдущей точки.

1 Не делайте этого на производстве

Прежде чем что-либо делать, создайте пустую базу данных на локальном компьютере, а затем импортируйте информацию. Но, опять же, это не похоже на простое использование внешнего интерфейса базы данных для импорта файла SQL.

Вместо этого создайте каталог, соответствующий имени базы данных, которую вы хотите создать. В этом посте я буду использовать пример trunkdev (поскольку именно здесь я работаю с самой последней версией из магистрали WordPress ).

2 Резервное копирование существующей базы данных

Затем сделайте резервную копию существующей базы данных, насколько это возможно, будь то интерфейс базы данных или копия файлов. После этого скопируйте файлы из исходного местоположения в созданный вами каталог.

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

3 Не устанавливайте другое программное обеспечение

Обратите внимание, что на данный момент я бы не стал устанавливать на него другое программное обеспечение, такое как WordPress или любую другую информацию. Вместо этого работайте непосредственно с данными. Предполагая, что он виден в вашем внешнем интерфейсе, сделайте правильную резервную копию или экспортируйте файл в файл SQL, чтобы вам было легче восстановить информацию в будущем.

Некоторые внешние интерфейсы дадут вам возможность экспортировать только определенные таблицы. В этом случае сделайте резервную копию всего. Для некоторых баз данных это займет много времени; для других не очень. Все зависит от размера проекта.

4 Работа с данными

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

Как только вы поверите, что у вас есть информация в месте, которое готово для восстановления в любое приложение, потерявшее информацию, поврежденную информацию или просто искаженные данные, пришло время подготовиться к тому, чтобы взять информацию с вашего локального компьютера и отправить ее обратно на сервер. источник.

Назад к источнику

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

Затем сделайте резервную копию базы данных, прежде чем начать с ней работать. Сохраните файл в местоположении, которое вы можете легко вспомнить и легко получить к нему доступ, чтобы, если что-то пойдет не так с использованием информации, которую вы собираетесь импортировать, вы были защищены и просто восстановили то, что уже было там. Чтобы было ясно, экспортируйте всю базу данных в формате SQL.

Теперь возьмите базу данных, которая у вас есть на вашем локальном компьютере, и экспортируйте эту информацию в файл SQL. Откройте экспортированный файл и убедитесь, что он использует оператор CREATE для создания базы данных с правильным именем и таблиц с правильными именами.

Если все пойдет хорошо, все, что вы импортировали, будет восстановлено именно так, как должно быть и как вы видите на своем локальном устройстве. Если вы этого не видите, импортируйте файл, который вы экспортировали ранее; в противном случае, вы можете идти.

Что, если это не сработает?

Если это не сработает, вам придется перейти к корневой проблеме:

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

Если на данный момент это не работает, обычно это происходит из-за чего-то вроде того, что указано выше. Впрочем, это может быть и что-то другое. Я сделал все возможное, чтобы предоставить как можно больше информации о базах данных MySQL, о том, как они структурированы, и о шагах, необходимых для восстановления базы данных из файлов, но я не могу охватить все потенциальные крайние случаи.

Всегда делайте резервные копии данных (и не думайте, что это делается)

Тем не менее, я надеюсь, что вся приведенная выше информация даст более глубокое понимание того, что скрывается под WordPress, если вы столкнетесь с этой проблемой самостоятельно или с клиентом.

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

Если вы это сделаете, вам не придется беспокоиться обо всем вышеперечисленном.

Источник записи: tommcfarlin.com