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

права на дроп убрать у базы на слейве реально?

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

Опередил.

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

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

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

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

Попробуй добавить триггер на drop, который будет дампить базу?

http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_add-dr...

http://answers.oreilly.com/topic/176-how-to-use-a-trigger-to-log-changes-to-a...

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

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

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

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

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

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

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

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

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

https://dev.mysql.com/doc/refman/5.0/en/purge-binary-logs.html

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

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

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

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

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

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

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

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

Это я на всякий случай сделал :)

это балансер ру и авиабазу ты так мучаешь?:)

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

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

…

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

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

Есть start slave until... Соответственно указать там бинлог и позицию drop-а.

О! Это могло бы помочь.