Актуален ли железный рейд для пары SSD в raid1?

1. не верно, не предсказуем, в старых моделях была проблема смерти контроллера а сами ячейки памяти оставались живы, с новыми рекомендую не рисковать и все равно делать дублирование.

2. зависит от объемов, если все будет вмещаться в ssd то hdd это избыток.

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

Ну мониторить износ надо и заранее менять. Тогда норм будет. И как заметил Den73, все равно зеркало будет безопаснее.

1. Во-первых, не предсказуем, кучу SSD по гарантии меняли, как-то в одной машине 8 ссд сменили, контроллеры бракованные по всему миру продавали. Или тот же 8мб глюк Интелов со старой прошивкой...

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

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

3. На сэкономленные нервы и время, Ваше и Ваших пользователей, сделать еще один другой проект.

По умолчанию MySQL работает совсем не так. MySQL пишет в

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

http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

The default value of 1 is required for full ACID compliance. With this value, the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file.

Эта батарейка стоимостью 500 баксов тут будет бесполезна.

Чтобы данные были в сохранности - нужно знать как работает ПО, никакая батарейка вас не спасет.

Вы забываете, что могут иметь место проблемы технического характера, например, сбой контролера. Зеркалирование и бэкап - обязательны!

как раз поэтому батарейка и полезна. нагрузка от такого поведения mysql довольно высокая и батарейка позволяет ее избежать.

Но мы все-таки в разделе "Хостинг для нищего веба", поэтому следует понимать, что под mysql Pavel.Odintsov понимает myisam. Либо innodb, где обязательную запись транзакций отключают и всем рекомендуют потому что так модно.

У меня вот раздвоение мозга происходит. То темы возникают, подобные этой, где во внимание принимаются любые мелочи, любые тонкости. Речь идёт о высоких материях и нитях мысли...

И тут же фигакс, арендую самый дешевый кака-дедик на кака-дисках, десктопном проце в кака-ДЦ.

Кстати "вторых" тем порядка 99% :) Ыыыы

To all.

1. Согласен, есть другие проблемы с дисками кроме износа ячеек. Но в любом случае как правило в рейде ставится два диска одной модели, есть высокая вероятность, что именно в raid 1 у них будет один и тот же брак или случится одна и та же ошибка контролёра/кеша и проч. одновременно. Учитывая скорость работы SSD, можно сразу и не заметить, что один из дисков больше не работает, так что можно запросто лишится обоих дисков.

2. Простой CPU или памяти тут причём? Статика как правило не принимает участие в генерации страниц и обработке данных. Скорость чтения мелких файлов у HDD как правило на порядок выше пропускной способности канала дедика. Если не планируется загружать 1Gb на 100% отдачей мелких файлов, то смысла в SSD не вижу.

3. Бекап на локальном компе на отдельном диске для быстрого восстановления при любых поломках системных дисков, или, как уже говорили, для быстрого переноса сервера.

Кстати, vkontakte отказался от работы на raid системах они используют реплицирование файлов на программном уровне.

Хорошо, если мы включим sysvar_innodb_flush_log_at_trx_commit, то на каждую транзакцию будет вызываться fflush, верно? В данном случае это отчасти поможет, если SSD не будет нагло врать, что flush сделан, а на самом деле он не сделал. Ситуация когда диск врет о реальном сбросе данных - крайне распространенная и используется производителями для "видимого ускорения" работы диска, даже есть тулзы как это проверить.

Но даже если с MySQL Innodb это поможет, то на сервере есть еще файловая система (почти всегда ext4) у которой стандартный коммит аж 5 секунд (commit=nrsec) и она с радостью потеряет если не базы, то сопутствующие файлы ну или сама покрашится, это довольно легко.

Мораль - аппаратный/программный RAID, батарейки при наличии денег, максимально стабильный по питанию ДЦ и регулярные бэкапы :)

Кроме этого еще есть настройка innodb_flush_method, задает как именно делать flush.

ФС с журналированием может легко покрашиться?

Тут вопрос не в наличии денег, а в целесообразности их траты.