Comments 28
Спасибо за инфу!
Желаю всем, чтобы не пригодилась!
Желаю всем, чтобы не пригодилась!
Пожалуйста!
Мне вчера ночью как раз и пригодилось бы. Завалил по-неосторожности данные, которые месяц собирал. Решение проблемы не сразу нашёл.
Мне вчера ночью как раз и пригодилось бы. Завалил по-неосторожности данные, которые месяц собирал. Решение проблемы не сразу нашёл.
и у тебя совершенно случайно включены бинлоги? :-)
имхо — если бинлоги включены, значит человек знает, зачем они нужны и как с ними работать.
имхо — если бинлоги включены, значит человек знает, зачем они нужны и как с ними работать.
Эм… Я их на сервере не включал. Получается, что случайно. :)
На домашней машине проверил — не включены по умолчанию. Сейчас в заметку добавлю. Спасибо!
На домашней машине проверил — не включены по умолчанию. Сейчас в заметку добавлю. Спасибо!
хех, везунчик :-) но, как ты заметил в статье, одних бинлогов мало — нужен ещё и дамп :-)
или ты дважды везунчик, что у тебя и бинлоги, и дамп, сделанный от начала их ведения (или уже во время)
или ты дважды везунчик, что у тебя и бинлоги, и дамп, сделанный от начала их ведения (или уже во время)
Если не трижды. Оказывается, ещё и сбрасываться логи могут при достижении определённых размеров или спустя какое-то время. В настройках задаётся.
Мне дамп не понадобился (его и не было) все изменения базы попали в логи.
Мне дамп не понадобился (его и не было) все изменения базы попали в логи.
в текущих стабильных версиях в бинлог не попадают изменения. туда — попадают запросы, которые затрагивают > 1 записи.
если там были UPDATE/DELETE, то я не верю, что по бинлогам можно что-то получить без дампа.
если там были UPDATE/DELETE, то я не верю, что по бинлогам можно что-то получить без дампа.
В лог попадают все запросы, которые изменяют данные, а не просто затрагивают. ;) И, наверное, всё-таки изменяют > 0 записей.
У меня были UPDATE и DELETE, но перед ними в логи попали и все CREATE с INSERT'ами. Поэтому всё без дампа и обошлось.
У меня были UPDATE и DELETE, но перед ними в логи попали и все CREATE с INSERT'ами. Поэтому всё без дампа и обошлось.
Если бинлог ведется с момента создания базы — то все изменеия будут в нем, и дамп не потребуется.
Угу, только надо не забывать про следующее:
1. Восстановление из бинлогов возможно только тогда, когда они велись с самого начала. Либо если есть слепок первоначального состояния базы данных, после которого начали вестись логи.
2. На нагруженных серверах бинлоги быстро убивают пространство на диске, поэтому их хранят не все, а некоторое количество последних. Предыдущие же либо пакуются, либо вовсе удаляются. Понятно, что в последнем случае восстановить ничего не удастся.
3. Еще одно назначение бинлогов — репликация. Если есть реплика, безусловно легче восстановить данные с нее, чем из бинлогов.
1. Восстановление из бинлогов возможно только тогда, когда они велись с самого начала. Либо если есть слепок первоначального состояния базы данных, после которого начали вестись логи.
2. На нагруженных серверах бинлоги быстро убивают пространство на диске, поэтому их хранят не все, а некоторое количество последних. Предыдущие же либо пакуются, либо вовсе удаляются. Понятно, что в последнем случае восстановить ничего не удастся.
3. Еще одно назначение бинлогов — репликация. Если есть реплика, безусловно легче восстановить данные с нее, чем из бинлогов.
И ещё вопрос снижения производительности при включённых логах — ведь ничего бесплатно не бывает
Благодарю за комментарий.
То есть, после удаления старых логов нужно обязательно слепок делать? Расскажите, пожалуйста подробнее, можно ссылкой на описание этой процедуры.
Кстати, я восстанавливал удалённую базу по одному последнему лог-файлу. Причём, пробовал и копировать его в отдельную папку, где более старых логов не было. Всё прекрасно восстановилось. Как-то можете это прокомментировать?
То есть, после удаления старых логов нужно обязательно слепок делать? Расскажите, пожалуйста подробнее, можно ссылкой на описание этой процедуры.
Кстати, я восстанавливал удалённую базу по одному последнему лог-файлу. Причём, пробовал и копировать его в отдельную папку, где более старых логов не было. Всё прекрасно восстановилось. Как-то можете это прокомментировать?
1. Зависит от многих факторов, например есть ли реплика? Если есть, то дамп надо делать на ней, это не потребует залочки мастера. Если нет, основной алгоритм такой — лочим базу, делаем дамп, делаем purge bunary logs, разлочиваем базу. Имеем — свежий слепок БД и бинлоги начавшиеся с момента бэкапа.
2. Вероятно все ваши операции с вашей удаленной базой уложились как раз в один бинлог-файл, потому и смогли восстановить.
2. Вероятно все ваши операции с вашей удаленной базой уложились как раз в один бинлог-файл, потому и смогли восстановить.
Спасибо большое. Пригодится.
UFO just landed and posted this here
Можно использовать бэкап + записи в бинлоге после создания бекапа. Утилита mysqlbinlog может выбирать записи в бинлоге начиная с определенного времени.
mysqlbinlog --start-datetime=«2005-12-25 11:25:56» binlog.000003
mysqlbinlog --start-datetime=«2005-12-25 11:25:56» binlog.000003
Раз в 10 дней:
— Лочите все таблицы
— Делаете дамп
— Выполняете PURGE BINARY LOGS
— Разлочиваете таблицы
— Удаляете старые логи
При сбое в любой момент можете восстановить все данные. Каждый день дампы делать нет смысла, если используете бинарный журнал.
— Лочите все таблицы
— Делаете дамп
— Выполняете PURGE BINARY LOGS
— Разлочиваете таблицы
— Удаляете старые логи
При сбое в любой момент можете восстановить все данные. Каждый день дампы делать нет смысла, если используете бинарный журнал.
поставил в закладки, спасибо
Еще важно помнить, что по умолчанию MySQL не синхронизирует бинарный лог с диском для каждой операции. Т.е. если машина упала, то с большой долей вероятности у вас будут разные данные в базе и в логах (бинарных). Проблему можно решить установкой параметра sync_binlog=1. Это значить, что MySQL будет синхронизировать лог с диском для каждой операции (если поставить 5, то для каждые 5 операций). Естественно, это отразиться на производительности, но это уже другая история.
Ё-маё. С каких пор изложение мана своими словами стало называться статьей? Если уж затронули тему восстановления БД, так сделали бы обзор ВСЕХ способов, их плюсы и минусы, в каких условиях приемлимы и т.д. А то одни вершки, которые новичкам только мозг запудрят. Вот, например, почему в «статье» о бинарных логах MySQL не упоминается о BLACKHOLE? Да потому что автор не затруднил себя детальным изучением вопроса и скорее всего вообще о BH не слышал.
Не согласен в вами. Хабр — это сообщество, поэтому, если пишите статью — пишите для всех. А «заметки для себя» лучше писать в блокноте. Инет итак переполнен подобными отрывочными, однобокими заметками. В гугле они находятся за одну секунду по 20 штук на страницу выдачи. Давайте уже как-то повышать качество материалов на хабре.
Я не считаю у меня достаточно знаний для толковой статьи посвященной бэкапу БД. Поэтому и не спешу пересказывать на хабре только что прочитанные маны.
Простите за суровое отношение, ваш материал (хоть я и не в восторге от него) лучше многих, что в последнее время публикуют «авторы». Но, повторюсь еще раз, вам есть куда расти.
Я не считаю у меня достаточно знаний для толковой статьи посвященной бэкапу БД. Поэтому и не спешу пересказывать на хабре только что прочитанные маны.
Простите за суровое отношение, ваш материал (хоть я и не в восторге от него) лучше многих, что в последнее время публикуют «авторы». Но, повторюсь еще раз, вам есть куда расти.
После очередного краха ценной инфы решил проверить бинлоги в деле… давно о них слышал, но никогда не использовал, ограничивался бекапами…
Вообщем, настроил сервер как полагается, логи ведутся, всё ок.
Намеренно удаляю 15 записей в таблице…
Вытаскиваю из бинлога sql… и вижу там свой delete запрос… отлично, но чем это мне поможет? мне же важны были именно удалённые данные…
Попытался сделать insert в очищенную таблицу, и он в логах вообще не зафиксировался…
Вообщем, настроил сервер как полагается, логи ведутся, всё ок.
Намеренно удаляю 15 записей в таблице…
Вытаскиваю из бинлога sql… и вижу там свой delete запрос… отлично, но чем это мне поможет? мне же важны были именно удалённые данные…
Попытался сделать insert в очищенную таблицу, и он в логах вообще не зафиксировался…
Sign up to leave a comment.
Восстановление базы MySQL из бинарных логов