Comments 10
- Малдер, сколько на этом диске данных?
- примерно миллион данных, Скалли
+7
Оно было основано на Hashicorp vault (в качестве бэкенда для него выступил Consul)
Разве Consul не умеет хранить переменные сам по себе? Vault вроде бы нужен только для их шифрования?
+1
Тут было важно организовать всё так, чтобы они корректно регистрировались в протоколе обнаружения сервисов, который, в свою очередь, управлял работой ДНС.
А как тут организовано всё? Через DNS Interface консула?
0
Надежность системы: проблемы наблюдались в июле 2019-го — заказы не оформлялись в течении часа. Но это было до глобального переезда. В дальнейшем крупных инцидентов не наблюдалось.
Не сочтите за попытку дискредитировать, но просто вот 14 февраля 2020 года мы с женой решили провести романтический вечер, тогда еще COVID-19 был далеко и домашний вечер со свечами казался чем-то очень необычным, но как всегда помешали «тупые проблемы», пришлось даже написать в маркетинг Тануки. Правда ответа так и не последовало…
Расскажите что за проблемы были в этот день?
+11
Забавно когда коммент, который явно несет в себе дискредитацию начинается с фразы «не сочтите за попытку дискредитировать. Не понимаю, зачем это делать :)
Я хочу ответить на него только этим сообщением, потому что любой другой диалог будет развитием троллинга, который технически начинается с фразы „А я вот видел!“.
Я хочу ответить на него только этим сообщением, потому что любой другой диалог будет развитием троллинга, который технически начинается с фразы „А я вот видел!“.
+3
К сожалению, никак не упомянут колл-центр. Он в обработке заказов участия не принимает?
Не знаю как сейчас, но ранее у них все заказы обрабатывались живыми людьми.
Т.е. можно построить сайт, который не "падает", но если колл-центр "умер", то большая часть пришедших заказов обработана не будет.
0
Отличный кейс! Ещё кейсы в студию!
0
Решения по первому направлению были, прежде всего, связаны со стабилизацией работы кластера MySQL. Отказываться от мастер-мастер репликации не хотелось, но и продолжать работать с плавающим IP было невозможно. Периодически наблюдались нарушения сетевой связанности, что приводило к нарушениям работы кластера.
Если использовался keepalived, то сервера должны были находиться в одной сети.
Наблюдались нарушения сетевой связанности в сети хостера?
Прежде всего, мы решили отказаться от плавающего IP в пользу прокси-сервера, где между мастерами будет контролируемо переключаться апстрим, так как в качестве прокси для MySQL мы задействовали nginx. Второй шаг — выделение двух отдельных серверов под слейвы. Работа с ними была также организована через прокси-сервер. И с момента реорганизации мы забыли о проблемах, связанных с работой с БД.
Т.е. один прокси без резервирования?
0
Довольно поверхностно описаны изменения. Хотелось бы больше технических подробностей (например о резервировании балансера, если таковое имеется), мы же на хабре.
И про 550 RPS не совсем понятно — это же не так много
И про 550 RPS не совсем понятно — это же не так много
+2
Sign up to leave a comment.
Инфраструктура еды: как мы саппортим «Тануки»