http://en.wikipedia.org/wiki/RAID

Костыль от нижегородских производителей

Перед каждым платежом записывать тестовый файл и читать его.

А вообще - да, RAID во все поля.

В пакете smartmontools есть демон smartd, который в случае обнаружения проблем умеет запускать какую-нибудь софтину или скриптик.

это платёжные терминалы, их сотни, ставить в каждый зеркальный рейд дорого.

Перед каждым платежом записывать тестовый файл и читать его.

А если сломается между чтением файла и записью Mysql?) Ну так, внезапно отвалится)

Специально для этого случая придуманы транзакции. База данных при синхронном коммите не ответит ОК пока данные не будут сохранены на диск.

SMART для этого придумали.
smartmontools - максимально автоматизировано
smartctl - вручную

Так, можно читать dmesg, как там начнутся «ругательства» про винт, значит что-то не в порядке. Хотя, как-то эта затяея выглядит странно, на моей памяти винты обычно уходили разом, так что с них потом сложно что-либо считать. То есть погибает вся база разом, в том числе и уже сохранённые записи. Или здесь другой случай?

P.S. Как я понимаю, прога, принимающая платежи модернизации не подлежит?

непрерывно чуть-чуть подгружать винт тестирующим мусорным трафиком. без тайм-аутов и ретрейнов. ну dd какой-нибудь.

перед сохранением файла
записать 100метров на диск
сделать sync раза 2 - замерить время от начала записи до окончания синков
сбросить кеш дисков echo 3 > /proc/sys/vm/drop_caches
прочитать файл - и замерить за сколько он прочитаеться
если скорость чтение и записи не будет выще обычьного времени на сколько то процентов - то все нормально
если нет - то техосблуживание

такую проверку можно устраивать - и вне платежей - скажем каждые минут 5 - и если проблема - то слать в центр сигнал

принимает бабки
mysql

Ну ты понел, где тут хрень, да? Если там еще и нет транзакций - то я вообще молчу...

ну хотя бы софтовый рейд, хотя бы RAID1 создай.

транзакции есть. тут проблема немного в другом. смысл не совсем в том, чтоб сохранить данные, а в том, чтоб система прекратила принимать платежи. Т.к. в терминал подключено 2 сети. 1-я gprs-инет, по которой я принпимаю транзакции от терминалов, а 2-я rs-485(через ридер электронных карт) - сеть держателя электронных карт, куда терминал говорит, что электронная карта №ХХХХХХ пополнена на сумму Y. Если ломается винчестер в сеть rs-485 сообщение о пополнении уходит, а транзакция ложится в базу. Раз в 5 мин терминал связывается с сервером через gprs-инет и ко мне приходят транзакции. Если винчестер сломался - в сеть держателя карт транзакция уходит, а ко мне - как повезет, смотря когда закрашится ОС. Т.е. надо как-то мониторить работоспособность HDD не реже чем раз в 3 сек. Платежей много, и быстро ( это метро ).

Надо , как-то сделать так, чтоб при отключении\ошибке винчестера всё остановилось. А сейчас происходит так: выдергиваю винт и провожу 10-15 платежей, пока ОС не раздуплится, что винта нет.

сбросить кеш дисков echo 3 > /proc/sys/vm/drop_caches

вот это интересно - ща попробую раз в секунду сбрасывать кеш. А чем этот метод отличается от sync ?? Sync почемуто не перестает работать, при выдергивании винчестера. Отрабатывает без ошибки, пока не закрашится вся ОС.

Специально для этого случая придуманы транзакции. База данных при синхронном коммите не ответит ОК пока данные не будут сохранены на диск.

А по умолчанию такая штука включена в mysql ? Или это на уровне организации БД ?

Функции клиента mysql не возвращают ошибок. Я предпологал, что это из-за дискового кеша. но монтирование раздела в режиме sync ничего не поменяло :(

это обычьный кеш - в не кеш записи
чтобы чтение этого файла происходила именно с диска
я это для того привел - чтобы проанализировать живет ли щас диск
а создание 100 метров файла и удаление - как раз проверка для новых данных что будет писать на диск mysql

я бы имхо в такой ситуации - както разделил диск на 2 части - и во второй держал такойже mysql и данные что записывал - записывал в обе базы
иль хотябы просто файликами клал на второй раздел отчеты о помешении данных - чтобы было откуда их потом выгребать
(или usb флешку мелкую - куда ты запись шла - в качестве вторичного носителя)
но диск именно разделенный чтоб был - чтоб другая фс была

smart юзай, он позволяет предсказать смерть харды задолго до того как перед фактом окажешься.

делаю в цикле с паузой 1 сек echo 3 > /proc/sys/vm/drop_caches и система сразу раздупляется, что нет винта. Общем помогло - спасибо.

интересное конечно решение - но
тогда оно изза каждого чиха будет дергать диск - причем прилично
какбы от этого дискам нестало еще хуже

Собери уже рейд :) Ты угробишь все своими костылями.

ТС, тебе правильно советуют транзакции в mysql'е. А те кто выше советуют использовать drop_caches - вендузятники, привыкшие любую дверь выбивать тараном вместо дёрганья ручки. Добавь sync в опциях монтирования, на том разделе, где лежит база.

Рейд или удалённая БД.

а если между приемом платежа и записью в базу? а если между первым и вторым запросом в базу? внезапно винты не ломаются. про SMART выше написали.

sync-frm
sync-binlog
innodb-flush-log-at-trx-commit = 1
innodb_support_xa = 1
innodb_doublewrite= 1

Как то так. Базу конечно в innodb. Ну а вообще, держать денежные базы в mysql - я бы плохо спал.

у меня MyISAM базы

деньги хранятся в оракле, mysql только, как стек транзакций внутри терминала.

у меня MyISAM базы

Ну вы поняли, кто тут буратино, ага.

Погуглил MyISAM vs InnoDB. То, что я прочел наводит на мысль о том, что ты прав. Я не dba, а структура баз мне досталась в наследство. Мой тех.директор, грамотный мужик, утверждает, что MyISAM не кешируется, а пишется сразу в файло. Насколько это соответствует истине, кто-то знает ?

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

Ну так пусть техдир и предложит решение. Спроси у него заодно что он скажет про гарантии записи в myisam и букву D из ACID.

PS: Ядро линукс кеширует все и вся, именно для этого есть синхронный коммит и fsync при записи лога транзакций.

Сложен ли процесс реорганизации такой ДБ.

Не сложен - ALTER TABLE blabla. Софт вероятно ничего не заметит, но точно сказать нельзя.

Вменяемые базы кешируют запись, и только лог транзакций пишут без кеша, делая fsync как можно чаще(как настроишь). Это обеспечивает высокую производительность потому что запись лога линейна, а не рандомна. В тоже время надежность не страдает.