netwind: смысл в чем : вы не увидите сообщения "оплата произведена" пока данные не записаны в надежное хранилище. Может быть вы увидите внутреннюю ошибку, но это не важно.
Можете показать show variables like 'sync_binlog' на основном сервере?
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
Впрочем очень скоро будет 0. Нефиг баловаться.
bugsmoran добавил 21.07.2010 в 19:07
netwind, блин! Чувак! Спасибо за идею! Ты может и сам не понял что за идея, но она охеренная. Теперь не нужно распараллеливать запросы даже. Можно на одних бинлогах выехать. Это надежнее.
Просто у нас бинлоги пишутся в память парной машины, а дальше наверно намек понятен )))
Так а не важно уже будет вернет коммит или нет. Данные на файловой системе уже на тот момент будут неконсистентными. И если в случае myisam попортится одна табличка (и конечно не факт, что самая ценная), то вот в innodb до наступления отказа в коммите может грохнуться сколько угодно баз полностью.
В любом случае это совершенно идиалистическая картина, когда падает все и вся как по сговору. На практике же она бывает только на краш-тестах. Даже если произойдет что-то невероятное и развернутся небеса, придет дьявол, пустит молнию на 220 вольт, накроет ей весь Нюрнберг и все процессы в нем происходящие (в том числе хостинговые) и умрут одновременно две машины, которые не успели сбросить данные на диск, то мы потеряем только 4 часа для баз, которым это важно (например интернет-магазины), коих единицы. Просто все они получат деньги, и не просто за хостинг, а куда как большие (сколько потеряли). Но вероятность этого настолько ничтожна, что я готов вернуть эти деньги.
VH2: Я бы не был так категоричен. Есть мнение что таблица будет повреждена, но не уничтожена. И с вероятностью в 99% она восстановится автоматом при старте MySQL, либо будет поправлена руками через repair table mysqlcheck myisamchk
Вот! 99%, а не 100%. Это уже чеснее. Но у нас тоже вероятность того что я описал не выше.
Это Вы так решили, что они обеспечиваются по дефоту.
Их нереально обеспечить на 100%, можно только достигнуть прогресса в этом.
А что если обычный MySQL на обычном хостинге в процессе записи транзакции Вы получите kernel panic? MYD уничтожен! Гарантированно! И по frm и MYI Вы его не восстановите. А востановите только бэкапную копию суточной давности.
netwind: то есть перезагрузка (не поломка, а бросок питания) двух серверов в течении 4 часов cчитается невероятным событием? это дойчебанковский стандарт надежности штоле?
Да? А два дизельных генератора тоже случайно упадут?
Это нереальная ситуация, что в двух отсеках одновременно упадут по четыре независимых источника питания, а вслед за ними еще и генераторы. Кстати у второго сервера со всеми его электроканалами есть 10 минут чтобы упасть, потому что если стендбайная нода увидела падение первой, то сразу скидывает на диск базы.
netwind:
странная вообще идея запихать базы в ramdrive. встречал простенькие на вид запросы на поиск связей с самообъединением - очень сильно грузят процессор. даже загрузка такой базы в память не сильно поможет. понятно, что умный клиент решает эту задачу иначе, но раз уж вы наобещали, то будет решать наивно и положит вам mysql.
Здесь было много тех, кто рассказывал как мы будем падать, но почему-то никто не положил. Может Вы попробуете? )))
lissyara: запрос к таблице из двух строк - тоже можно считать не обращающимся к дискам.
======= чё там про батарейку-то и кэширование записи на диски? =)
Про батарейку сам ничего не знаю. Серверы в другом государстве относительно меня.
Что касается сброса баз на диск (Вы это имеете ввиду в вопросе?) - оно редкое. Раз в 4 часа. Но все запросы параллелятся на парный сервер, так что этот кэш может понадобиться только в случае одновременного падения обоих серверов
P.S. Напоминаю клиентам серверов Питер16, Питер17 - с полуночи и до утра будет происходить перенос, все сервисы будут опущены.
Зачем Вы так переносите? Можно ведь не класть серверы, сначала всю инфу скопировать, затем сменить DNS-ы, положить апач и после этого слить дамп всего мускула и вгрузить актуальную версию на новый сервер.
А можно вообще без даунтайма: Не класть DNS, а сделать редирект всех сайтов c company.com на new.company.com, где new - просто алиас на новом сервере для такого же company.com. Если зон много, то можно заксриптовать, чтобы пробежаться по всем зонам и сделать cat >> этой записи
Работы админу макстмум на пол часа, но зато сервис не прервете.
смысл в чем : вы не увидите сообщения "оплата произведена" пока данные не записаны в надежное хранилище. Может быть вы увидите внутреннюю ошибку, но это не важно.
Можете показать show variables like 'sync_binlog' на основном сервере?
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
Впрочем очень скоро будет 0. Нефиг баловаться.
bugsmoran добавил 21.07.2010 в 19:07
netwind, блин! Чувак! Спасибо за идею! Ты может и сам не понял что за идея, но она охеренная. Теперь не нужно распараллеливать запросы даже. Можно на одних бинлогах выехать. Это надежнее.
Просто у нас бинлоги пишутся в память парной машины, а дальше наверно намек понятен )))
Вот спасибо, дилему века нам решил!
Так а не важно уже будет вернет коммит или нет. Данные на файловой системе уже на тот момент будут неконсистентными. И если в случае myisam попортится одна табличка (и конечно не факт, что самая ценная), то вот в innodb до наступления отказа в коммите может грохнуться сколько угодно баз полностью.
В любом случае это совершенно идиалистическая картина, когда падает все и вся как по сговору. На практике же она бывает только на краш-тестах. Даже если произойдет что-то невероятное и развернутся небеса, придет дьявол, пустит молнию на 220 вольт, накроет ей весь Нюрнберг и все процессы в нем происходящие (в том числе хостинговые) и умрут одновременно две машины, которые не успели сбросить данные на диск, то мы потеряем только 4 часа для баз, которым это важно (например интернет-магазины), коих единицы. Просто все они получат деньги, и не просто за хостинг, а куда как большие (сколько потеряли). Но вероятность этого настолько ничтожна, что я готов вернуть эти деньги.
Я бы не был так категоричен. Есть мнение что таблица будет повреждена, но не уничтожена. И с вероятностью в 99% она восстановится автоматом при старте MySQL, либо будет поправлена руками через
repair table
mysqlcheck
myisamchk
Вот! 99%, а не 100%. Это уже чеснее. Но у нас тоже вероятность того что я описал не выше.
Это Вы так решили, что они обеспечиваются по дефоту.
Их нереально обеспечить на 100%, можно только достигнуть прогресса в этом.
А что если обычный MySQL на обычном хостинге в процессе записи транзакции Вы получите kernel panic? MYD уничтожен! Гарантированно! И по frm и MYI Вы его не восстановите. А востановите только бэкапную копию суточной давности.
Ну и кто больше приблизился к ACID ? ;)
Не забывайте, что RCAT пока есть только у Oracle.
Вполне вероятно, особенно если учесть, что ДЦ бюджетный.
Но вопрос: а так ли она нужна? Ну раздвоилась инфа, ну и что? А четность тогда для чего нужна?
Какой же это рейд, если он без батарейки не мужик?
то есть перезагрузка (не поломка, а бросок питания) двух серверов в течении 4 часов cчитается невероятным событием? это дойчебанковский стандарт надежности штоле?
Да? А два дизельных генератора тоже случайно упадут?
Это нереальная ситуация, что в двух отсеках одновременно упадут по четыре независимых источника питания, а вслед за ними еще и генераторы. Кстати у второго сервера со всеми его электроканалами есть 10 минут чтобы упасть, потому что если стендбайная нода увидела падение первой, то сразу скидывает на диск базы.
странная вообще идея запихать базы в ramdrive. встречал простенькие на вид запросы на поиск связей с самообъединением - очень сильно грузят процессор. даже загрузка такой базы в память не сильно поможет. понятно, что умный клиент решает эту задачу иначе, но раз уж вы наобещали, то будет решать наивно и положит вам mysql.
Здесь было много тех, кто рассказывал как мы будем падать, но почему-то никто не положил. Может Вы попробуете? )))
запрос к таблице из двух строк - тоже можно считать не обращающимся к дискам.
=======
чё там про батарейку-то и кэширование записи на диски? =)
Про батарейку сам ничего не знаю. Серверы в другом государстве относительно меня.
Что касается сброса баз на диск (Вы это имеете ввиду в вопросе?) - оно редкое. Раз в 4 часа. Но все запросы параллелятся на парный сервер, так что этот кэш может понадобиться только в случае одновременного падения обоих серверов
Кстати RAID у нас 5E, а не 5
Нет, они невольные подставленные. У них нет возможности различать. Так же как аукционы не судят за проданные на них ворованные картины.
Это незаконное распространение чужой собственности. И не важно как Вы это делаете - своими руками (ресурсами) или чужими.
А вот в случае если дело дошло до суда, то распространение не своими силами Вам зачтется и наказание дадут меньше.
P.S. Напоминаю клиентам серверов Питер16, Питер17 - с полуночи и до утра будет происходить перенос, все сервисы будут опущены.
Зачем Вы так переносите? Можно ведь не класть серверы, сначала всю инфу скопировать, затем сменить DNS-ы, положить апач и после этого слить дамп всего мускула и вгрузить актуальную версию на новый сервер.
А можно вообще без даунтайма: Не класть DNS, а сделать редирект всех сайтов c company.com на new.company.com, где new - просто алиас на новом сервере для такого же company.com. Если зон много, то можно заксриптовать, чтобы пробежаться по всем зонам и сделать cat >> этой записи
Работы админу макстмум на пол часа, но зато сервис не прервете.
Может быть у Вас интернет отломался и все гораздо прозаичнее? :)