Самый стабильный хостинг за скромные деньги

Я узнавал по этому вопросу у hetzner. Нет там батареек... по крайней мере не было...

Вполне вероятно, особенно если учесть, что ДЦ бюджетный.

Но вопрос: а так ли она нужна? Ну раздвоилась инфа, ну и что? А четность тогда для чего нужна?

Какой же это рейд, если он без батарейки не мужик?

bugsmoran, есть такие требования ACID, которым удовлетворяет почти любая СУБД. Это настолько обычные требования, что программисты даже не задумываются выполняются они или нет.

http://ru.wikipedia.org/wiki/ACID

у вас эти требования обеспечиваются?

Это Вы так решили, что они обеспечиваются по дефоту.

Их нереально обеспечить на 100%, можно только достигнуть прогресса в этом.

А что если обычный MySQL на обычном хостинге в процессе записи транзакции Вы получите kernel panic? MYD уничтожен! Гарантированно! И по frm и MYI Вы его не восстановите. А востановите только бэкапную копию суточной давности.

Ну и кто больше приблизился к ACID ? ;)

Не забывайте, что RCAT пока есть только у Oracle.

bugsmoran, разумеется речь о myisam не идет, так как ACID обсуждается применительно к транзакциям. А вот innodb не вернет ответ на commit, если операция пока запись на диск не завершится успешно. Так по дефолту и нужно еще постараться это сломать.

и че это за понты с ораклом? Repair table восстанавливает .MYD файлы, хотя и может отбросить несколько записей. myisamchk восстанавливает еще более агрессивно.

Я бы не был так категоричен. Есть мнение что таблица будет повреждена, но не уничтожена. И с вероятностью в 99% она восстановится автоматом при старте MySQL, либо будет поправлена руками через

repair table

mysqlcheck

myisamchk

Так а не важно уже будет вернет коммит или нет. Данные на файловой системе уже на тот момент будут неконсистентными. И если в случае myisam попортится одна табличка (и конечно не факт, что самая ценная), то вот в innodb до наступления отказа в коммите может грохнуться сколько угодно баз полностью.

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

Вот! 99%, а не 100%. Это уже чеснее. Но у нас тоже вероятность того что я описал не выше.

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

Можете показать show variables like 'sync_binlog' на основном сервере?

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| sync_binlog | 1 |

+---------------+-------+

Впрочем очень скоро будет 0. Нефиг баловаться.

bugsmoran добавил 21.07.2010 в 19:07

netwind, блин! Чувак! Спасибо за идею! Ты может и сам не понял что за идея, но она охеренная. Теперь не нужно распараллеливать запросы даже. Можно на одних бинлогах выехать. Это надежнее.

Просто у нас бинлоги пишутся в память парной машины, а дальше наверно намек понятен )))

Вот спасибо, дилему века нам решил!

на этом, для меня обсуждение закончено.

почитайте про рейды и их работу, для начала.

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