Comments 25
Подскажите, пожалуйста, кто-нибудь как можно топик из песочницы перенести в рубрику MySQL? Это мой первый топик на Хабре, и кроме как в песочницу я его опубликовать не мог. Но его место — в MySQL.
Узнаю гос учреждение с их бардаком по управлению it инфраструктурой.
Если у вас сохранился весь datadir, то никаких пустых баз с идентичной структурой создавать не нужно. Достаточно просто заменить все файлы и откорректировать размер логов InnoDB.
Далее стартуем MySQL и внимательно смотрим лог. Должен стартануть и выполнить восстановление.
Если восстановление не проходит, тогда в конфиге ставим innodb_force_recovery=1 (http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html) и пробуем стартовать. Если не стартуем, ставим innodb_force_recovery=2 и пробуем стартовать. И т.д. до 6.
Если сразу стартуете с innodb_force_recovery=6, то вы рискуете получить БД в inconsistent state. Т.е. целостность (согласованность) данных может быть нарушена.
Если вы дошли до innodb_force_recovery=6 и это не помогло, то очень грустно — нужно восстанавливать в полуручном режиме.
Далее стартуем MySQL и внимательно смотрим лог. Должен стартануть и выполнить восстановление.
Если восстановление не проходит, тогда в конфиге ставим innodb_force_recovery=1 (http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html) и пробуем стартовать. Если не стартуем, ставим innodb_force_recovery=2 и пробуем стартовать. И т.д. до 6.
Если сразу стартуете с innodb_force_recovery=6, то вы рискуете получить БД в inconsistent state. Т.е. целостность (согласованность) данных может быть нарушена.
Если вы дошли до innodb_force_recovery=6 и это не помогло, то очень грустно — нужно восстанавливать в полуручном режиме.
Спасибо за ценные замечания!
Уточните пожалуйста, насчет этого:
>>> Если у вас сохранился весь datadir, то никаких пустых баз с идентичной структурой создавать не нужно. Достаточно просто заменить все файлы и откорректировать размер логов InnoDB.
Это Вы имеете в виду, на чистую свежеустановленную MySQL в том числе? Т.е. вопрос в том, можем ли мы просто закинуть файлы в datadir, и MySQL будет их видеть сразу как базу?
PS. Я, кстати, думал попробовать сначала просто закинуть файлы, но не зная до конца, как оно работает, решил перестраховаться, создав пустую базу, чтобы потом не делать это все заново. А так, это зависит от того, регистрирует ли MySQL при создании базы и таблиц (и использует ли потом при работе с ними) информацию о них где-то еще, кроме datadir.
PPS. Вы не против, если я дополню статью Вашими советами?
Уточните пожалуйста, насчет этого:
>>> Если у вас сохранился весь datadir, то никаких пустых баз с идентичной структурой создавать не нужно. Достаточно просто заменить все файлы и откорректировать размер логов InnoDB.
Это Вы имеете в виду, на чистую свежеустановленную MySQL в том числе? Т.е. вопрос в том, можем ли мы просто закинуть файлы в datadir, и MySQL будет их видеть сразу как базу?
PS. Я, кстати, думал попробовать сначала просто закинуть файлы, но не зная до конца, как оно работает, решил перестраховаться, создав пустую базу, чтобы потом не делать это все заново. А так, это зависит от того, регистрирует ли MySQL при создании базы и таблиц (и использует ли потом при работе с ними) информацию о них где-то еще, кроме datadir.
PPS. Вы не против, если я дополню статью Вашими советами?
>>>Это Вы имеете в виду, на чистую свежеустановленную MySQL в том числе? Т.е. вопрос в том, можем ли мы просто закинуть файлы в datadir, и MySQL будет их видеть сразу как базу?
Да.
Для MyISAM достаточно .MYD, .MYI, .frm положить в каталог схемы. Кстати, можно даже на ходу.
Для InnoDB нужен ibdata — метаинформация хранится там (даже при использовании innodb_file_per_table) + .frm + .ibd (если стоит innodb_file_per_table)
>>>PPS. Вы не против, если я дополню статью Вашими советами?
Не против.
Да.
Для MyISAM достаточно .MYD, .MYI, .frm положить в каталог схемы. Кстати, можно даже на ходу.
Для InnoDB нужен ibdata — метаинформация хранится там (даже при использовании innodb_file_per_table) + .frm + .ibd (если стоит innodb_file_per_table)
>>>PPS. Вы не против, если я дополню статью Вашими советами?
Не против.
Именно так поступил в декабре прошлого года, когда рухнула FreeBSD на сервере (рухнула конкретно, пришлось потом переустанавливать ОС)*. При этом знакомый «cool admin»** уверял, что надо обязательно заливать вытащенные файлы баз именно на фрю, дескать, на другой ОС ничего не выйдет. Тем не менее, под виртуальной XP мускуль нормально подхватил все файлы, и я спокойно сделал дамп баз, для заливки на свежеустановленную ОС.
*Не хотелось терять данные за день (за предыдущий день бэкапы были).
**Для себя сделал вывод о степени компетентности этого знакомого. Кстати, фрю именно он и уронил, во время обновления. Но это уже другая история.
*Не хотелось терять данные за день (за предыдущий день бэкапы были).
**Для себя сделал вывод о степени компетентности этого знакомого. Кстати, фрю именно он и уронил, во время обновления. Но это уже другая история.
UFO just landed and posted this here
Неправильные у вас выводы.
1. Ненадо в процессе разработки озадачиваться бэкапами. Это должны делать те кто внедряет и сопровождает. Грамотный админ сделает это лучше а вы своими костылями только мешать будете.
2. См п1.
3. «Четкое регламентирование обязанностей каждого сотрудника» — закономерно приводит к игнорированию сотрудником всего что его не касается. Нет что бы дать начальству пару ссылок на подобные топики, так оно само админов распинает на бэкапы и покарает анально.
1. Ненадо в процессе разработки озадачиваться бэкапами. Это должны делать те кто внедряет и сопровождает. Грамотный админ сделает это лучше а вы своими костылями только мешать будете.
2. См п1.
3. «Четкое регламентирование обязанностей каждого сотрудника» — закономерно приводит к игнорированию сотрудником всего что его не касается. Нет что бы дать начальству пару ссылок на подобные топики, так оно само админов распинает на бэкапы и покарает анально.
> Нет что бы дать начальству пару ссылок на подобные топики, так оно само админов распинает на бэкапы и покарает анально.
Плюсик поставила вот за это
Плюсик поставила вот за это
Не буду с Вами спорить, но в данном случае внедряем и сопровождаем по большому счеты мы сами — разработчики. Грамотным же админом в данном контексте мне пока что, к сожалению, только предстоит стать, т.к. опыт в этой области (реального администрирования СУБД в «боевых условиях»), увы, мизерный. Другой путь — инициировать разговоры с начальством о необходимости перекладывания этой задачи (конкретно этой задачи, с базой этого проекта, т.к. с базами других проектов подобных проблем, слава Богу, нет) на админов. Я пока не определился, какой путь выбрать :) думаю. Выводы же не абсолютные, а относительные для меня в моей конкретной ситуации, да и выводы эти не на всю оставшуюся жизнь, а на данный момент. Но спасибо за высказанное мнение, оно тоже актуально и интересно.
Если вдруг вы напишете что то реально полезное и это захотят внедрять у себя люди без вашего участия, натыканные костыли будут всем мешать, а маты в сторону разработчика будут вам икаться.
В принципе, особо «тыкать костыли» никто и не собирался. Штатными средствами несложно заставить мускул делать бекап регулярно, я и подразумевал прежде всего это, когда говорил «если можешь сделать сам». Остается только автоматизировать копирование этих бэкапов на удаленный комп/сервер для полноты «счастья». Ну и во-вторых, системы, которые мы пишем, реально полезны там, куда они внедряются. Внедрять же их своими силами эти структуры, как правило, не только не могут (в виду отсутствия в штате IT-специалистов), но и изначально задумано в этом плане тесное сотрудничество с нами. Если бы мы занимались этим как бизнесом, и клиенты были бы другого типа, то и подходы бы во многом отличались. Но это уже отдельная тема.
Ну а там, где сами внедрять будут, бэкап и подобные вещи — это уже и, естественно, не мое дело.
У вас хороший повествовательный стиль изложения. Читать было интересно, несмотря на внутренние ухмылки про mysql & windows :)
да и «сервера» на десктопном железе тоже вызывают умиление.
а вы считаете, что сервером может называться только параллелограмм в стойке?
Я считаю, что отказоустойчивость продакшна обеспечиваться серверной «прочностью» и избыточностью.
Примеры в стиле «тестовый сервер» стоят на чем попало, а ставить критичные сервисы на несерверное железо мы зареклись.
«только параллелограмм в стойке?»
Можно прикопаться к тому, что далеко не все сервера rack-mount и привести примеры. Мысль, я думаю, была не в этом. Речь именно о десктопном и серверном железе, можно десктопную мать со всем фаршем засунуть в 4u и оставить работать.
Примеры в стиле «тестовый сервер» стоят на чем попало, а ставить критичные сервисы на несерверное железо мы зареклись.
«только параллелограмм в стойке?»
Можно прикопаться к тому, что далеко не все сервера rack-mount и привести примеры. Мысль, я думаю, была не в этом. Речь именно о десктопном и серверном железе, можно десктопную мать со всем фаршем засунуть в 4u и оставить работать.
а вы считаете, что сервером может называться только параллелограмм в стойке?
<зануда>Скорее, прямоугольный параллелепипед. Ибо сервер все же имеет объем. И углы у него, как правило, прямые.</зануда>
Показательная история =)
В целом согласна с PhantomTLT, что было сделано много лишних телодвижений. Тем более техника восстановления binary backup (а у вас фактически был именно он) подробно описана в мануале.
С другой стороны многим пользователям будет полезно.
В целом согласна с PhantomTLT, что было сделано много лишних телодвижений. Тем более техника восстановления binary backup (а у вас фактически был именно он) подробно описана в мануале.
С другой стороны многим пользователям будет полезно.
Как я понял есть два варианта резервного копирования:
1. «дамп» базы в sql-файл (недостаток — огромный размер файла, превосходящий по размару саму базу данных)
2. «Холодное» копирование папки с данными (недостаток — нужно останавливать базу)
а есть у mysql нормальный вариант — дамп базы в ДВОИЧНЫЙ файл без останова?
1. «дамп» базы в sql-файл (недостаток — огромный размер файла, превосходящий по размару саму базу данных)
2. «Холодное» копирование папки с данными (недостаток — нужно останавливать базу)
а есть у mysql нормальный вариант — дамп базы в ДВОИЧНЫЙ файл без останова?
Если следовать логике, и опереться на ответ PhantomTLT выше, а также на официальную документацию MySQL, то получается, что при использовании исключительно MyISAM можно делать «дамп» базы вручную, копируя файлы без останова базы (но, наверное, желательно запретить [LOCK] на время запись в базу, оставив доступным только чтение). Чтобы делать горячий бинарный бэкап InnoDB, предлагается воспользоваться специальным отдельным инструментом MySQL Enterprise Backup (как я понимаю, доступен только в виде платной версии?), или же, воспользоваться другой — и как утверждает разработчик (и я ему охотно верю), не менее качественной — бесплатной и открытой альтернативой Percona XtraBackup.
Продукция последнего разработчика — в т.ч. и (точнее, в первую очередь) альтернативная совместимая с мускулом СУБД Percona Server — пробуждает определенный к ней интерес, но пока что не пробовал, хотя планирую на будущее. Как я понимаю, этот их флагманский продукт является интересным форком MySQL, сохранившим совместимость с последним, но при пошедший вперед по весьма интересному, и вероятно, достойному пути.
Продукция последнего разработчика — в т.ч. и (точнее, в первую очередь) альтернативная совместимая с мускулом СУБД Percona Server — пробуждает определенный к ней интерес, но пока что не пробовал, хотя планирую на будущее. Как я понимаю, этот их флагманский продукт является интересным форком MySQL, сохранившим совместимость с последним, но при пошедший вперед по весьма интересному, и вероятно, достойному пути.
В то же время, если просто скопировать «на горячую» InnoDB-шные файлы и логи, то есть вероятность того, что из них получится восстановить базу :) Но, хоть и вероятность эта может быть достаточно высокой, называть это полноценным дампом я бы все-таки не стал.
Хотя, опять же, я не уверен, что InnoDB-файлы можно скопировать «на горячую». Проверить бы, да сейчас не могу. Что-то мне подсказывает, что они могут быть либо «заперты», либо может иметь место отсутствие целостности данных. В документации горячий бэкап InnoDB описан только в варианте использования вышеупомянутого инструмента.
Sign up to leave a comment.
История восстановления базы MySQL из файлов (InnoDB)