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

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

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

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

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

С уважением, Vasilisk
miksoft
Дата: 13.01.2013 22:13:17
_Vasilisk_
Сейчас таких систем развернуто порядка 300 и где-то раз в два-три месяца приходят жалобы о падении БД.
раз в два-три месяца - на каждый хост или в сумме на всю систему?
Если на всю систему, то это весьма неплохая надежность. Отказы железа и прочего, не связанного с БД, по моим представлениям, должны иметь в разы большую интенсивность.

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

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

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

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


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

_Vasilisk_
Периодичность запросов от 300 мс до 10 с. Используется движок InnoDB.
Ну дык InnoDB умеет сбрасывать данные на диск сразу после обновления, раз в секунду и может отдать это на усмотрение ОС (но там тоже задержка не будет большой). При таком раскладе до пяти минут оооочень далеко.
netwind
Дата: 14.01.2013 00:45:30
>оборудована Smart-UPS,
>В основном это происходит из-за частых пропаданий питания

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


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

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

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

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


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

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

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

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

В простейшем случае можно самому написать скриптики
для крона.
_Vasilisk_
Дата: 14.01.2013 02:08:13
miksoft
раз в два-три месяца - на каждый хост или в сумме на всю систему?
На систему. Раз в два-три месяца как минимум одна база падает
miksoft
Есть какая-нибудь статистика о точных причинах падений БД?
90% - отказы питания.

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

vkle
_Vasilisk_
В моем понимании лучшее, что можно сделать - это отказаться от БД и перейти на файловое хранилище.
И как это может улучшить надежность?
При повреждении одного файла можно будет пересоздать один файл, а не всю базу. Кроме того упрощается процедура валидации базы и можно автоматически определить в чем проблема и также автоматически ее ликвидировать
vkle
Ну дык InnoDB умеет сбрасывать данные на диск сразу после обновления, раз в секунду и может отдать это на усмотрение ОС (но там тоже задержка не будет большой). При таком раскладе до пяти минут оооочень далеко.
По логам это выглядит так:
- О! Нас тут нештатно выгрузили, но пофиг - восстанавливаем данные из журнала.
Используется три журнала по 50 мегабайт. Размер одного апдейта - килобайты. Но наступает момент, когда из журналов уже ничего восстановить нельзя и сервер уходит в аут

netwind
ну так батареи в упсах еще и менять надо.
Исходный вопрос в том, что в новой версии системы упсов не будет вообще
netwind
Вы хотя бы видели смотрели эти упавшие системы
Видел
netwind
Поняли почему именно они падают ?
В основном - повреждение табличного пространства InnoDB и невозможность восстановить данные из журналов. Еще было разрастание табличного пространства и сжирание всего доступного диска (после проведения OPTIMIZE TABLE все становилось на место). Но эту проблему решили жестким заданием размера табличного пространства. Еще пару раз было повреждение системной базы mysql
netwind
Система на innodb должна сама восстанавливаться будучи выключенной в любом состоянии, если данные не разрушены и ее не пытались "оптимизировать" испортив настройки фиксации транзакций.
В основном восстанавливаются. Но не всегда
tanglir
Дата: 14.01.2013 05:25:37
_Vasilisk_
При повреждении одного файла можно будет пересоздать один файл, а не всю базу.
Ну, чисто для справки, и в иннодб есть режим "одна таблица - один файл". Но поможет ли он вам, пока первоисточник проблем не выявлен? И будет ли нужен, когда тот наконец-то обнаружится?
_Vasilisk_
Но наступает момент, когда из журналов уже ничего восстановить нельзя
Почему нельзя? Сервер не умеет говорить "не хочу", он знает только "не могу по такой-то причине". Или он просто падает без всяких записей в логах?
_Vasilisk_
В основном - повреждение табличного пространства InnoDB и невозможность восстановить данные из журналов
Ну так а причины этого какие были?
_Vasilisk_
. Еще было разрастание табличного пространства и сжирание всего доступного диска
В этом тоже виноваты мускль и иннодб? Хотя отсутствие шринка "искаропки" - это, конечно, минус.
netwind
ScareCrow
бэкап пробовали?

бекап тут не пойдет ! судя по высокому служебному слогу, нужна Автоматизированная Система Создания Резервных Копий !
Для стабильного функционирования АССРК требуется достаточный объём дискового пространства, а у ТСа этого пространства даже на саму БД не хватает, о чём вообще речь...
bochkov
Дата: 14.01.2013 06:01:23
_Vasilisk_
miksoft
раз в два-три месяца - на каждый хост или в сумме на всю систему?
На систему. Раз в два-три месяца как минимум одна база падает

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

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