В течение ночи моему провайдеру пришлось принудительно перезагрузить сервер (отключить), после загрузки возникла проблема с сервером MySQL (я использую MariaDB).
После нескольких часов исследований я не могу найти основной источник проблемы или способ ее решить. Веб-сайт довольно большой, работает с биткойнами, на счетах, возможно, утеряны тысячи долларов (не совсем потеряны, просто не связаны с их соответствующими «владельцами»), и я паникую.
Каким-то образом папка / var / lib / mysql 'трансформировалась' в файл с таким же именем, mysql, он содержит тарабарщину: http://pastebin.com/XbY5YLpG
Я также просмотрел файлы журналов MariaDB, и в этих файлах есть несколько ГБ запросов.
Есть ли способ получить базу данных? Я очень расстроен.
Есть программа mysqlcheck который поставляется с mysql, который позволяет вам восстанавливать таблицы, если вы можете запустить mysql и ваши таблицы повреждены. Не похоже, что это так. Есть еще одна программа myisamchk, который позволяет вам гарантировать целостность ваших таблиц MyISAM (вы не использовали для этого innodb, не так ли?), пока у вас есть файлы, относящиеся к ним; он будет использовать их ключевые ограничения и журнал.
Однако, поскольку кажется, что ваша файловая система сломалась и потеряла файлы базы данных, вы не можете использовать ни одну из этих вещей.
Даже если предположить, что ваши данные все еще существуют (если запись каталога была преобразована в файл, возможно, все ссылки на ваши файлы исчезли, а дисковое пространство было освобождено), если это в этом файле, у вас нет возможности восстановить его в удобный формат. Если случайно ваша файловая система может быть исправлена, и на данные все еще ссылаются (используйте fsck в соответствии с вашей файловой системой), и вы можете получить файлы и вернуть их в правильном порядке, см. Первый абзац.
Если честно, я думаю, вы, наверное, только что выучили очень дорогой урок. Храните резервные копии!
После того, как я написал это, кто-то другой узнал кто ты и что-то еще связанное с этим. Я предполагаю, что вы хранили резервные копии, и на самом деле вам нужно будет восстановить из них, и вы перенесете потерю, насколько это может быть неудобно.
Если вы не можете переносить резервное копирование даже двухдневной давности, более частое резервное копирование - очевидное решение; другое решение - сохранить живые наборы реплик, на которые вы можете переключиться (и восстановить). Они похожи на резервные копии, но работают только в подобных ситуациях (то есть не при уничтожении данных злоумышленниками и т. Д.).
Вам следует особенно по возможности сохраняйте резервные копии перед переходом между поставщиками или серверами Powercycle. Кроме того, приведенные вами симптомы могут указывать на неисправный диск, что быстро многое объяснит.
Также имейте в виду, что если база данных работает медленно, очень высоки шансы, что она выполняет какую-то дорогостоящую операцию, такую как повторная попытка записи или индексация, или повторная балансировка или что-то еще. Это точное время, когда горячая перезагрузка нарушит целостность данных.
Удачи в восстановлении после этого с точки зрения бизнеса. Я считаю, что ваши данные после последней точки резервного копирования закончены.
Еще один важный урок заключается в том, что если вы взимаете плату с людей, а непрерывность бизнеса важна, а потеря данных недопустима, вам необходимо создать избыточность в своей системе. Единственный узел, на котором запущен mysql, как вы так удачно продемонстрировали, недостаточно надежен или избыточен. Это вдвойне верно для одиночного VPS. Правильный вариант - использовать поставщика VPS, который позволяет вам явно размещать серверы в разных местах и в разных сетях, или, в конечном итоге, покупать собственные серверы и размещать их в разных центрах обработки данных.