да, бывает, что связность нод рвется.
Но за два года эксплуатации еще у нас еще ни разу не было совпадения рассинхронизации нод и аварии на мастер-сервере.
Рассинхронизация легко отлавливается отдельными скриптами и у ваших админов остается куча времени, чтобы спокойно в рабочее время все починить.
Для WEB-сайта, магазина это м.б. и приемлемо, а для системы с кучей транзакци в секунду, отчетами, биллингом — нельзя. работа должна быть с одной конкретной сущностью бд
тут же фишка в том, что всего 2 сервера применяется. 3 сервера в 1,5 раза дороже систему сделает и усложнит ее обслуживание.
Читать из slave — не годится. Т.к.
1. slave м.б. недоступен
2. БД на slave может отставать
3. производительность. У нас СМСка должна дойти за 4 секунды от момента отправки клиентом и до попадания на телефон — лишний трафик между серверами во время транзакции не целесообразен.
у нас примерно раз в 2 месяца чтото бывает. вот считайте…
я не хочу тут мериться циферками на самом деле. Просто имея реальный опыт эксплуатация аналогичных систем (СМС-севрисы и пр. операторские штуки) — вот такое решение себя очень и очень хорошо показало!
Многие крупные агрегаторы не могут похвастаться такой системой переклчюения на резерв.
я бы еще уточнил, что в жизни заявленный в SLA uptime мало кто соблюдает и мало кто его меряет. По своему опыту — многие провайдеры, с хорошим SLA не обеспечивают заявленной доступности.
облака не облака — какая разница. можете использовать облака в моем решение. Для нашего проекта облака получаются дороже.
Реплика — ок. Опять же — можете применять любые хитрости для повышения надежности реплики — это не возбраняется.
Stateless — Это хорошо. На любой stateless есть экскаватор дяди Пети, копающий через магистраль.
тут просто надо найти компромисс между степенью надежности и уровнем затрат (денежных и трудовых), которые вы готовы понести.
Вы предлагаете добавить еще +1 машину и усложнить схему.
С моей точки зрения это уже излишняя перестраховка.
Но, вообще, вы правы — проблема эта есть. И мы ее решили блокировкой переключения в слейв в случае разрыва коннекта между двумя серверами.
И вообще, я же не говорю, что наше решение — панацея. Система постоянно меняется и тюнингуется. Если есть проблемы с соединением между датацентрами мы переезжаем в другой дата-цетр
Я предложил решение для заданных условий. Оно реально работает.
У вас есть идеи лучше? поделитесь! давайте обмениваться фишками как обойти те или иные слабые места.
надо правильно настроить репликацию, следить, чтобы она была живой.
Как бы то ни было — я же говорил в статье, что слабые места есть. Но, объективно говоря, я не встречал ничего лучшего в пределах такого же бюджета!
Да, но это решение, которое доступно всем интернет проектам с самыми маленькими бюджетами. Это лучше чем ничего. И даже такие (или аналогичные) решения очень мало кто применяет на практике!
я предложил здесь реальную работающую надежную схему с временем простоя ок. 20 минут при любых самых жесткых крешах. Использовать эти идеи или не использовать — решать вам.
При ошибке ПО никакие решения по резервированию не помогут — поможет только откручивание головы программистам. Так же и по реплике — это не предмет для обсуждения. Репликация это базовый механизм — она должна работать без ошибок. Ставьте себе нормальные СУБД
дело в том, что на слейве база не пятиминутной давности, а репликация — т.е. это база актуальная ровно до тех пор пока мастер на перестанет работать как мастер.
Т.е. если клиент совершил транзакцию — она совершилась на мастере и эти данные в БД передались на слейв в реплике.
Конечно, возможна ситуация, когда пропало соединение между мастером и слейвом и нарушилась репликация — тогда да, это слабое место, — транзакцию мы потеряем. НО это отдельная ситуация, которую можно отдельно диагностировать и лечить
Но за два года эксплуатации еще у нас еще ни разу не было совпадения рассинхронизации нод и аварии на мастер-сервере.
Рассинхронизация легко отлавливается отдельными скриптами и у ваших админов остается куча времени, чтобы спокойно в рабочее время все починить.
Читать из slave — не годится. Т.к.
1. slave м.б. недоступен
2. БД на slave может отставать
3. производительность. У нас СМСка должна дойти за 4 секунды от момента отправки клиентом и до попадания на телефон — лишний трафик между серверами во время транзакции не целесообразен.
я не хочу тут мериться циферками на самом деле. Просто имея реальный опыт эксплуатация аналогичных систем (СМС-севрисы и пр. операторские штуки) — вот такое решение себя очень и очень хорошо показало!
Многие крупные агрегаторы не могут похвастаться такой системой переклчюения на резерв.
я бы еще уточнил, что в жизни заявленный в SLA uptime мало кто соблюдает и мало кто его меряет. По своему опыту — многие провайдеры, с хорошим SLA не обеспечивают заявленной доступности.
Реплика — ок. Опять же — можете применять любые хитрости для повышения надежности реплики — это не возбраняется.
Stateless — Это хорошо. На любой stateless есть экскаватор дяди Пети, копающий через магистраль.
Вы, по моему, вообще немного о другом…
Вы предлагаете добавить еще +1 машину и усложнить схему.
С моей точки зрения это уже излишняя перестраховка.
Но, вообще, вы правы — проблема эта есть. И мы ее решили блокировкой переключения в слейв в случае разрыва коннекта между двумя серверами.
И вообще, я же не говорю, что наше решение — панацея. Система постоянно меняется и тюнингуется. Если есть проблемы с соединением между датацентрами мы переезжаем в другой дата-цетр
У вас есть идеи лучше? поделитесь! давайте обмениваться фишками как обойти те или иные слабые места.
Как бы то ни было — я же говорил в статье, что слабые места есть. Но, объективно говоря, я не встречал ничего лучшего в пределах такого же бюджета!
я предложил здесь реальную работающую надежную схему с временем простоя ок. 20 минут при любых самых жесткых крешах. Использовать эти идеи или не использовать — решать вам.
Т.е. если клиент совершил транзакцию — она совершилась на мастере и эти данные в БД передались на слейв в реплике.
Конечно, возможна ситуация, когда пропало соединение между мастером и слейвом и нарушилась репликация — тогда да, это слабое место, — транзакцию мы потеряем. НО это отдельная ситуация, которую можно отдельно диагностировать и лечить