LINUX.ORG.RU
ФорумAdmin

Хрень какая с БД :) Есть мысли, как избавить логи mysql-мастера от DROP DATABASE?

 , ,


0

1

Сегодня было весело. Задумал я бесшовное безостановочное перемещение БД с одного mysql-сервера на другой через репликацию. Сцепил сервера, на мастере сделал атомарный дамп, втянул на слейве (работы по втягиванию дампа на 2.5 часа), слейв догнал мастер, после чего на клиенте переключил сервер — и всё прекрасно. Пользователи даже не заметили подмены.

А дальше — fail. Я, забыва выключить синхронизацию, сделал DROP DATABASE на мастере :D Слейв оказался без БД.

Ладно, дамп есть. Печально, что без остановки не вышло, 2.5 часа простоя. И печально, что пропали сообщения форума за час или пол-часа (сколько реплика работала до того, как я на мастере базу прибил). Ну да хоть не так критично. Поднимаю базу из дампа, запускается... Опаньки. На форуме начинают резво появляться ночные сообщения o_O. Десяток-другой секунд не понимаю в чём дело. Потом смотрю в mytop... Оп-па! Сервер новый отрабатывает поток данных с сервера старого, мастера. Там же в бинлогах всё лежит! Базы уже нет, а логи остались. И при загрузке дампа на реплике произошло позиционирование и запуск репликации с мастера. Только и увидел в mytop'е, как прошёл снова DROP DATABASE ;)

Новость хорошая — введённые данные живы. В логах есть.

Новость плохая — логи завершаются DROP DATABASE :)

Можно тупо загрузиться с дампа (этого не избежать) и забить на введённые пользователями данные. Некомильфо, зато просто.

Можно попробовать как-то запретить DROP DATABASE в бинлогах. Есть мысли, как это сделать, кроме тупого поиска в бинлогах и исправлении в HEX-виде в файле? И то, если залоченный файл поменять удастся?

★★★★★

Я не уверен что так можно, т.к. точно не знаю как в mysql репликация реализована, но если она делается из под юзера mysql (например root), то может быть отобрать у него права на drop database?

pi11 ★★★★★
()
Ответ на: комментарий от pi11

но если она делается из под юзера mysql (например root), то может быть отобрать у него права на drop database?

Права настраиваются на стороне мастера. Реплика делает всё, что ей придёт с мастера. Увы, через права защититься от DROP'а не получится. Всё, что происходит на мастере — происходит на реплике :-/

KRoN73 ★★★★★
() автор топика

Короче, пока тупо забил в HEX-виде «DROP DATABASE» на мастере в двоичном файле. Дойдёт до этого места, выкинет ошибку :) Надеюсь…

KRoN73 ★★★★★
() автор топика

Детектив на ночь, прям :)

ovax ★★★
()
Ответ на: комментарий от rikardoac

Не... Это уже часа в три выльется :) 10 гигов база. Не стоит оно того :) Если сейчас вариант с забиванием DROP не прокатит (мало ли мастер из памяти отдаст), то смирюсь с потерей нескольких сообщений :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

На всякий случай перезапустил мастер (чтобы точно кеши пропали). Посмотрел через mysqlbinlog — в логах корректно выводится забитый текст. Так что должно прокатить :) Через 2.5 часа увидим…

KRoN73 ★★★★★
() автор топика

Ужасы какие... бинарные логи править =)

Неужели в MySQL нет возможности восстановления на определенный момент времени?

2.5 часа для 10-гигой базы... Да у меня 300-гиговая Оракловая база за 1,5 часа реплицируется на standby-сервер на отстойном по сегодняшним меркам железе.

Неужели в MySQL все так плохо?

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Короче, пока тупо забил в HEX-виде «DROP DATABASE» на мастере в двоичном файле. Дойдёт до этого места, выкинет ошибку :) Надеюсь…

Скажи мне, что ты ведь сначала проверил эту идею на тестовой мелкой БД? Или нет, не проверил...

geekless ★★
()
Ответ на: комментарий от tazhate

PURGE BINARY LOGS BEFORE '2012-03-05 11:20:23';

Теперь буду знать :) Хотя мой метод тоже сработал.

Update: топ. Это BEFORE. Пойду смотреть доку, может ли оно AFTER. Мне-то именно AFTER нужно.

Update2: Нет, не может. Так что не для моего случая :)

KRoN73 ★★★★★
() автор топика
Последнее исправление: KRoN73 (всего исправлений: 2)
Ответ на: комментарий от tazhate

Так ведь это сотрет логи ДО этого времени а не после.

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

shell> mysqlbinlog binlog_files > tmpfile

shell> ... edit tmpfile ...

Saving the output in a file is useful as a preliminary to executing the log contents with certain events removed, such as an accidental DROP DATABASE. You can delete from the file any statements not to be executed before executing its contents. After editing the file, execute the contents as follows:

shell> mysql -u root -p < tmpfile

hidden_4003
()
Ответ на: комментарий от nerve

Их, родных. Как сервер на хостинге стал глючить, пока вопрос с ним решается, домой перетащил. Домашняя файлопомойка слабенькая была (Q6600 и 4Гб ОЗУ), так что сайт там крутился, а БД к нему — на десктопе.

Сейчас «домашнюю файлопомойку» проапгрейдил до «домашнего сервера» (i5-2500K + 16Гб ОЗУ) и при переносе БД с десктопа на новый сервер сабжевый казус приключился :) В итоге всё перенёс, но несколько часов даунтайма вышло. Ну да ничего, в другой раз получится без остановки перенести :)



Хотя начинаю задумываться о том, чтобы тяжёлый текстовый контент хранить не в MySQL, а где-то отдельно. Хоть в NoSQL. Даже в простых текстовых файлах, вероятно, жизнеспособно будет :) Очень уж тяжело MySQL ворочает таблицы по несколько гигабайт, если встаёт вопрос экспорта/импорта/починки/оптимизации.

Т.е. видится такая структура — вся информация о постинге как и сейчас, в MySQL, а вот текст сообщений (и исходный, и компилированный в HTML) — где-то на стороне. Лишь бы читалось быстро. Надо будет попробовать варианты MongoDB, LevelDB и в текстовых файлах. Первый вариант удобен лёгкостью репликации, второй — модное слово (хотя обещают высокую производительность в key-value), третий — лёгкость версионности, можно сразу в репозитории хранить. На скорость, в целом, пофиг так как все сортировки/фильтры выборки идут в MySQL, поиск полнотекстовый через Sphinx, и итоговые страницы форума в основном в статическом html-кеше лежат.

KRoN73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.