2 биллинга одновременно работающих. нужна помощь в организации

[NiTr0 583]

Тормозить будет, юзеры по таймаутам отваливаться будут. Это только без нагрузки все нормально, а я думаю без нагрузки никто HA не заморачивается. Хотя это на HDD, на SSD наверное не так страшно уже.

Почему же. С мастера на слэйв перешлются только бинлоги. Слэйв же их потом накатывает на свою базу.

[ttttt 195]

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

Відредаговано 2013-09-16 21:10:04 ttttt

[NiTr0 583]

Транзакции лежат бинлогом, одним куском на диске. И вычитываются быстро...

Да, еще есть кеш. Где собссно и лежит бОльшая часть данных... А если база дергает при селектах винт - на сервере однозначно надо добавлять памяти...

[ttttt 195]

Транзакции лежат бинлогом, одним куском на диске. И вычитываются быстро...

Нет, если к диску в очередь еще толпа запросов.

 

А если база дергает при селектах винт - на сервере однозначно надо добавлять памяти...

Только вот HA так не получится

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

Совсем другое дело, если вся база всегда хранится в памяти, тогда подняться после ребута не проблема, т.к. нужно все-го последовательно подгрузить дамп/лог в память при запуске и не принимать запросы, пока это не произойдет. Некоторые, кстати, так и делают для HA, даже ndb в mysql, но это тоже костыль, с ним тоже есть проблемы, но уже другие, в пределах одного коммутатора все будет работать.

 

В общем, традиционные СУБД абсолютно не приспособлены для отказоустойчивой работы. Так что повторюсь: лучше не усложняйте.

Відредаговано 2013-09-16 22:57:53 ttttt

[NiTr0 583]

Нет, если к диску в очередь еще толпа запросов.

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%, делается вывод о неприспособленности СУБД к отказоустойчивой работе. Занятно...

[~AsmodeuS~ 34]

MySQL  кластер и все будет работать как надо уже проверяли, но как всегда есть нюанс иногда он разваливается и восстановление требует доп знаний и времени

[KJack 35]

всем спасибо за помощь и подсказки. настало новое поколение, прошу поделиться опытом.

Вопрос прежний - Фринибс и MySQL - не ищем дешёвых вариантов резервирования, ищем удобные варианты.

Частный облачный сервис для биллинга, кластерная система, или гибридные варианты... Кто подскажет, что самое надёжное решение этого вопроса на сегодняшний день?

[KJack 35]

p.s. если уже кто-то научился прикручивать ipv6 к фринибс - прошу поделиться опытом.

буду отдельно благодарен