Любой крупный проект начинался с пары серверов. Cначала был один DB-сервер, потом к нему добавились слейвы, чтобы масштабировать чтение. И тут — стоп! Мастер один, а слейвов много; если уйдет один из слейвов, то всё будет хорошо, а если уйдет мастер — будет плохо: даунтайм, админы в мыле поднимают сервер. Что делать? Резервировать мастер. Мой коллега Павел уже писал об этом статью, я не буду ее повторять. Вместо этого расскажу, почему вам обязательно нужен Orchestrator для MySQL!
Читать полностью »
Рубрика «Orchestrator»
Orchestrator для MySQL: почему без него нельзя строить отказоустойчивый проект
2020-05-18 в 7:08, admin, рубрики: mysql, Orchestrator, Блог компании Ситимобил, системное администрированиеOrchestrator и VIP как HA-решение для кластера MySQL
2020-03-04 в 12:35, admin, рубрики: database, devops, high availability, highload, mysql, Orchestrator, Percona, бд mysql, Блог компании СитимобилВ Ситимобил мы используем базу данных MySQL в качестве основного хранилища постоянных данных. У нас есть несколько кластеров баз данных под различные сервисы и цели.
Постоянная доступность мастера является критическим показателем работоспособности всей системы и ее отдельных частей. Автоматическое восстановление кластера в случае отказа мастера сильно снижает время реагирования на инцидент и время простоя системы. В этой статье я рассмотрю схему обеспечения высокой доступности (HA) кластера MySQL на основе MySQL Orchestrator и виртуальных IP адресов (VIP).
Анализ инцидента 21 октября на GitHub
2018-10-31 в 15:29, admin, рубрики: github, mysql, Orchestrator, бд, внесение неисправностией, высокая производительность, репликация, Серверное администрирование, согласованность, Тестирование IT-систем, хаос-инжиниринг, хранение данныхРоковые 43 секунды, которые вызвали суточную деградацию сервиса
На прошлой неделе в GitHub произошёл инцидент, который привёл к деградации сервиса на 24 часа и 11 минут. Инцидент затронул не всю платформу, а только несколько внутренних систем, что привело к отображению устаревшей и непоследовательной информации. В конечном счете данные пользователей не были потеряны, но ручная сверка нескольких секунд записи в БД выполняется до сих пор. На протяжении почти всего сбоя GitHub также не мог обрабатывать вебхуки, создавать и публиковать сайты GitHub Pages.
Все мы в GitHub хотели бы искренне извиниться за проблемы, которые возникли у всех вас. Мы знаем о вашем доверии GitHub и гордимся созданием устойчивых систем, которые поддерживают высокую доступность нашей платформы. С этим инцидентом мы вас подвели и глубоко сожалеем. Хотя мы не можем отменить проблемы из-за деградации платформы GitHub в течение длительного времени, но можем объяснить причины произошедшего, рассказать об усвоенных уроках и о мерах, которые позволят компании лучше защититься от подобных сбоев в будущем.
Читать полностью »