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