NiTr0 583 Posted 2013-09-16 20:24:00 Share Posted 2013-09-16 20:24:00 Тормозить будет, юзеры по таймаутам отваливаться будут. Это только без нагрузки все нормально, а я думаю без нагрузки никто HA не заморачивается. Хотя это на HDD, на SSD наверное не так страшно уже.Почему же. С мастера на слэйв перешлются только бинлоги. Слэйв же их потом накатывает на свою базу. Link to post Share on other sites
ttttt 195 Posted 2013-09-16 21:08:17 Share Posted 2013-09-16 21:08:17 (edited) А мастер диск не дергает, из воздуха данные берет? А к нему в это время еще и реальные юзеры лезут со своими транзакциями. У механических дисков ресурсов очень мало, их слишком легко загрузить и не предусмотреть, что он должен в это время еще и успевать синхронизироваться с другим сервером/диском на случай замены. Edited 2013-09-16 21:10:04 by ttttt Link to post Share on other sites
NiTr0 583 Posted 2013-09-16 21:50:04 Share Posted 2013-09-16 21:50:04 Транзакции лежат бинлогом, одним куском на диске. И вычитываются быстро... Да, еще есть кеш. Где собссно и лежит бОльшая часть данных... А если база дергает при селектах винт - на сервере однозначно надо добавлять памяти... Link to post Share on other sites
ttttt 195 Posted 2013-09-16 22:56:48 Share Posted 2013-09-16 22:56:48 (edited) Транзакции лежат бинлогом, одним куском на диске. И вычитываются быстро...Нет, если к диску в очередь еще толпа запросов. А если база дергает при селектах винт - на сервере однозначно надо добавлять памяти...Только вот HA так не получится Серверы иногда ребутаются, это неизбежно, и если полагаться на кэш для производительности, то подыматься после ребута будут до тех пор, пока интенсивность запросов не спадет настолько, что их потянет диск, т.е. обычно до ночи. Главное, для чего нужны кэши - это минимизировать отклики и защититься от кратковременных всплесков запросов (мини досов), но никак не для того, чтобы диск не дергать. Совсем другое дело, если вся база всегда хранится в памяти, тогда подняться после ребута не проблема, т.к. нужно все-го последовательно подгрузить дамп/лог в память при запуске и не принимать запросы, пока это не произойдет. Некоторые, кстати, так и делают для HA, даже ndb в mysql, но это тоже костыль, с ним тоже есть проблемы, но уже другие, в пределах одного коммутатора все будет работать. В общем, традиционные СУБД абсолютно не приспособлены для отказоустойчивой работы. Так что повторюсь: лучше не усложняйте. Edited 2013-09-16 22:57:53 by ttttt Link to post Share on other sites
NiTr0 583 Posted 2013-09-21 19:23:26 Share Posted 2013-09-21 19:23:26 Нет, если к диску в очередь еще толпа запросов.SATA винт легко вытягивает до 200 иопс на БД порядка гига объемом. При 40-50 иопс винт гуляет. А это, при грамотном тюнинге, порядка 40 операций insert/update в секунду. Или же, при интервале аккаунтинга в 1 минуту, порядка 1500 сессий онлайн. Т.е. абонбаза порядка 3к. Т.е., до 150 иопс можно не напрягаться, тазик с парой десктопных 7200 об/мин винтов вытянет 10к абонбазу легко, и не скукожится во время репликации. Далее, при репликации выгребается один кусок бинлога, блоком максимального размера (сколько там - 2к секторов? или больше?), и даже если будет 20 конкурирующих запросов со средним размером блока в 5-7 секторов, бинлог будет вытягиваться весьма шустро. Только вот HA так не получится Серверы иногда ребутаются, это неизбежно, и если полагаться на кэш для производительности, то подыматься после ребута будут до тех пор, пока интенсивность запросов не спадет настолько, что их потянет диск, т.е. обычно до ночи. Главное, для чего нужны кэши - это минимизировать отклики и защититься от кратковременных всплесков запросов (мини досов), но никак не для того, чтобы диск не дергать. Совсем другое дело, если вся база всегда хранится в памяти, тогда подняться после ребута не проблема, т.к. нужно все-го последовательно подгрузить дамп/лог в память при запуске и не принимать запросы, пока это не произойдет. Некоторые, кстати, так и делают для HA, даже ndb в mysql, но это тоже костыль, с ним тоже есть проблемы, но уже другие, в пределах одного коммутатора все будет работать. С какой такой радости? Размер нашей БД биллинга за 5 лет работы всего 2.7 гига. База естественным образом поднимается в кеш, и из кеша работает. Оперативные данные, типа детализированного аккаунтинга сессий, ессно, периодически удаляются. Если же у вас база намного больше оперативной памяти - flashcache в помощь. В общем, традиционные СУБД абсолютно не приспособлены для отказоустойчивой работы. Так что повторюсь: лучше не усложняйте.Из допущения, что дисковая подсистема должна быть всенепременно загружена на 101%, делается вывод о неприспособленности СУБД к отказоустойчивой работе. Занятно... Link to post Share on other sites
~AsmodeuS~ 34 Posted 2013-09-22 06:48:00 Share Posted 2013-09-22 06:48:00 MySQL кластер и все будет работать как надо уже проверяли, но как всегда есть нюанс иногда он разваливается и восстановление требует доп знаний и времени Link to post Share on other sites
KJack 35 Posted 2016-03-28 19:10:52 Author Share Posted 2016-03-28 19:10:52 всем спасибо за помощь и подсказки. настало новое поколение, прошу поделиться опытом. Вопрос прежний - Фринибс и MySQL - не ищем дешёвых вариантов резервирования, ищем удобные варианты. Частный облачный сервис для биллинга, кластерная система, или гибридные варианты... Кто подскажет, что самое надёжное решение этого вопроса на сегодняшний день? Link to post Share on other sites
KJack 35 Posted 2016-03-28 19:12:32 Author Share Posted 2016-03-28 19:12:32 p.s. если уже кто-то научился прикручивать ipv6 к фринибс - прошу поделиться опытом. буду отдельно благодарен Link to post Share on other sites
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now