Повышение надежности БД

Есть система на MySQL 5.1, WinXP Pro. В штатном режиме система может работать в режиме 24х7. В этой системе периодически выполняются запросы по вставке и обновлению BLOB полей. Периодичность запросов от 300 мс до 10 с. Используется движок InnoDB. Система необслуживаемая. Т.е. пользователь ни о какой БД не ведает. Сейчас система оборудована Smart-UPS, который, при пропадании питания штатно завершает работу Windows. Сейчас таких систем развернуто порядка 300 и где-то раз в два-три месяца приходят жалобы о падении БД. В основном это происходит из-за частых пропаданий питания.

Сейчас ведется проектирование новой версии системы. В этой версии для уменьшения размера планируется избавиться от UPS, а в качестве дискового накопителя использовать SSD диск. Мне поставлена задача обеспечить работоспособность.

В моем понимании лучшее, что можно сделать - это отказаться от БД и перейти на файловое хранилище. Но у меня нет столько времени. Можно ли, что-то сделать средствами самого MySQL, чтобы если не минимизировать вероятность падений, то хотя бы обеспечить автоматическое восстановление.

При штатной работе допускается пропадание данных за последние 5 минут. При автоматическом восстановлении допускается потеря данных после некоторой контрольной точки. Контрольные точки будут ставиться не чаще раза в месяц

С уважением, Vasilisk

_Vasilisk_
Сейчас таких систем развернуто порядка 300 и где-то раз в два-три месяца приходят жалобы о падении БД.

раз в два-три месяца - на каждый хост или в сумме на всю систему?
Если на всю систему, то это весьма неплохая надежность. Отказы железа и прочего, не связанного с БД, по моим представлениям, должны иметь в разы большую интенсивность.

Есть какая-нибудь статистика о точных причинах падений БД?

автор
моем понимании лучшее, что можно сделать - это отказаться от БД и перейти на файловое хранилище.

эм?

автор
то хотя бы обеспечить автоматическое восстановление.

бэкап пробовали?

_Vasilisk_
В моем понимании лучшее, что можно сделать - это отказаться от БД и перейти на файловое хранилище.

И как это может улучшить надежность? Так понимаю, что основная проблема упирается в пропадание питания?

_Vasilisk_
планируется избавиться от UPS, а в качестве дискового накопителя использовать SSD диск.

SSD не будет записывать данные без ляктричества. Можно говорить о каком-то снижении вероятности потери данных за счет сокращения времени записи из-за более высокой скорости обмена с накопителем. Вот подумалось, есть же рейд-контроллеры с батарейкой. После появления ляктричества они как бы продолжают прерванную операцию записи.

_Vasilisk_
При штатной работе допускается пропадание данных за последние 5 минут.

_Vasilisk_
Периодичность запросов от 300 мс до 10 с. Используется движок InnoDB.

Ну дык InnoDB умеет сбрасывать данные на диск сразу после обновления, раз в секунду и может отдать это на усмотрение ОС (но там тоже задержка не будет большой). При таком раскладе до пяти минут оооочень далеко.

>оборудована Smart-UPS,
>В основном это происходит из-за частых пропаданий питания

ну так батареи в упсах еще и менять надо.

ScareCrow
автор моем понимании лучшее, что можно сделать - это отказаться от БД и перейти на файловое хранилище. эм? автор то хотя бы обеспечить автоматическое восстановление. бэкап пробовали?

бекап тут не пойдет ! судя по высокому служебному слогу, нужна Автоматизированная Система Создания Резервных Копий !


Вы хотя бы видели смотрели эти упавшие системы или уровень бюрократизма не позволяет это сделать ?
Поняли почему именно они падают ?
Система на innodb должна сама восстанавливаться будучи выключенной в любом состоянии, если данные не разрушены и ее не пытались "оптимизировать" испортив настройки фиксации транзакций.

_Vasilisk_,

обычно , для повышения надежности ставят
какой-нибудь сервис/демон, который мониторит
указануе ему программы. напромер GOD , MINT,
(сушествуют ли аналоги на виндосе -- не в курсе)

http://godrb.com/
http://mmonit.com/monit/

идея на поверхности -- простая --
такой демон пингует и или делает тестовый
запрос каждые 5-60 сек на каждый зарегистрированый
процес (апач, мускл, СПЮ, память) и знает когда и как
рестартовать -- в смысле ему заранее задают правила.

В простейшем случае можно самому написать скриптики
для крона.

miksoft
раз в два-три месяца - на каждый хост или в сумме на всю систему?

На систему. Раз в два-три месяца как минимум одна база падает

miksoft
Есть какая-нибудь статистика о точных причинах падений БД?

90% - отказы питания.

ScareCrow
бэкап пробовали?

А смысл? Все равно нужно в итоге посылать человека, который, сделает Restore. Хотелось бы обойтись без этого человека. Тем более, что с ликвидацией упса я предчувствую более высокую статистику отказов

vkle
_Vasilisk_ В моем понимании лучшее, что можно сделать - это отказаться от БД и перейти на файловое хранилище. И как это может улучшить надежность?

При повреждении одного файла можно будет пересоздать один файл, а не всю базу. Кроме того упрощается процедура валидации базы и можно автоматически определить в чем проблема и также автоматически ее ликвидировать

vkle
Ну дык InnoDB умеет сбрасывать данные на диск сразу после обновления, раз в секунду и может отдать это на усмотрение ОС (но там тоже задержка не будет большой). При таком раскладе до пяти минут оооочень далеко.

По логам это выглядит так:
- О! Нас тут нештатно выгрузили, но пофиг - восстанавливаем данные из журнала.
Используется три журнала по 50 мегабайт. Размер одного апдейта - килобайты. Но наступает момент, когда из журналов уже ничего восстановить нельзя и сервер уходит в аут

netwind
ну так батареи в упсах еще и менять надо.

Исходный вопрос в том, что в новой версии системы упсов не будет вообще

netwind
Вы хотя бы видели смотрели эти упавшие системы

Видел

netwind
Поняли почему именно они падают ?

В основном - повреждение табличного пространства InnoDB и невозможность восстановить данные из журналов. Еще было разрастание табличного пространства и сжирание всего доступного диска (после проведения OPTIMIZE TABLE все становилось на место). Но эту проблему решили жестким заданием размера табличного пространства. Еще пару раз было повреждение системной базы mysql

netwind
Система на innodb должна сама восстанавливаться будучи выключенной в любом состоянии, если данные не разрушены и ее не пытались "оптимизировать" испортив настройки фиксации транзакций.

В основном восстанавливаются. Но не всегда

_Vasilisk_
При повреждении одного файла можно будет пересоздать один файл, а не всю базу.

Ну, чисто для справки, и в иннодб есть режим "одна таблица - один файл". Но поможет ли он вам, пока первоисточник проблем не выявлен? И будет ли нужен, когда тот наконец-то обнаружится?

_Vasilisk_
Но наступает момент, когда из журналов уже ничего восстановить нельзя

Почему нельзя? Сервер не умеет говорить "не хочу", он знает только "не могу по такой-то причине". Или он просто падает без всяких записей в логах?

_Vasilisk_
В основном - повреждение табличного пространства InnoDB и невозможность восстановить данные из журналов

Ну так а причины этого какие были?

_Vasilisk_
. Еще было разрастание табличного пространства и сжирание всего доступного диска

В этом тоже виноваты мускль и иннодб? Хотя отсутствие шринка "искаропки" - это, конечно, минус.

netwind
ScareCrow бэкап пробовали? бекап тут не пойдет ! судя по высокому служебному слогу, нужна Автоматизированная Система Создания Резервных Копий !

Для стабильного функционирования АССРК требуется достаточный объём дискового пространства, а у ТСа этого пространства даже на саму БД не хватает, о чём вообще речь...

_Vasilisk_
miksoft раз в два-три месяца - на каждый хост или в сумме на всю систему? На систему. Раз в два-три месяца как минимум одна база падает

так это считай на 300 серверов, очень неплохо
чтобы сократить количество падений не думали сократить количество серверов?
У вас я так понимаю постоянные перебои электричества, а тут вообще хотите отказаться от упсов,
раньше вы восстанавливали только базы, теперь будете восстанавливать еще и системы с железом.
Если хотите с восстановлением файлов заморочиться, переходите на MyISAM, бекап - простое копирование, рестор- простое копирование, только во время бэкапа таблицы лочить надо.

_Vasilisk_,

innodb_flush_log_at_trx_commit в какое значение установлен?
Если быстродействие не жмет, то установите в единицу.