Комментарии 41
А можно добавить информацию почему не выбрали galera?
Тут существует несколько причин.
1) Кадровая — людей, которые умеют траблшутить галеру на рынке достаточно мало.
2) Галера работает на основе синхронной репликации. То есть в случае замедления работы на одном из серверов, это будет сказываться на всем кластере. Да и в штатном режиме такой режим работы медленнее. При этом наше ПО адекватно реагирует на вменяемое отставание реплик.
Когда мы начнем задумываться об отказоустойчивости по ДЦ, то мы обязательно вернемся к этому вопросу. Пока думаем, что наши проблемы решаются без получения дополнительной головной боли.
1) Кадровая — людей, которые умеют траблшутить галеру на рынке достаточно мало.
2) Галера работает на основе синхронной репликации. То есть в случае замедления работы на одном из серверов, это будет сказываться на всем кластере. Да и в штатном режиме такой режим работы медленнее. При этом наше ПО адекватно реагирует на вменяемое отставание реплик.
Когда мы начнем задумываться об отказоустойчивости по ДЦ, то мы обязательно вернемся к этому вопросу. Пока думаем, что наши проблемы решаются без получения дополнительной головной боли.
Да, синхронность галеры может доставить проблем там где нужна скорость. Но вроде как у вас сервис как раз таки требующий надежности хранения данных. Кроме того по идее можно иметь группу нод галеры + слейвы, то есть тормоза будут только на запись. Ну и получается что если сейчас возникнет проблема с ДЦ то сервис склеивает лапки, так?
На самом деле надежность хранения не сверхкритична. Поездки на такси более-менее стейтлесс штука. Нам куда важнее при непредсказуемом росте нагрузки осуществлять поездки.
Вероятность роста таких нагрузок все же много больше вероятности отказа ДЦ. Мы впервую очередь закрываем наиболее вероятные риски с наибольшей опасностью для аптайма.
На случай ухода ДЦ у нас есть свои механизмы восстановления работоспособности (пока с небольшим даунтаймом), но об этом в следующих сериях ;-)
Вероятность роста таких нагрузок все же много больше вероятности отказа ДЦ. Мы впервую очередь закрываем наиболее вероятные риски с наибольшей опасностью для аптайма.
На случай ухода ДЦ у нас есть свои механизмы восстановления работоспособности (пока с небольшим даунтаймом), но об этом в следующих сериях ;-)
Ну и да — с точки зрения надежности уход мастер-базы у нас не приводит к потере транзакций. Полусинхронная репликация же.
Важно иметь баланс между производительностью и надежностью.
По галере: для внедрения нужен как минимум опыт в команде по её использованию и сопровождению в продакшене под нагрузкой. Галера накладывает ряд ограничений на схему, допустимые операции, локи + обычно всплывают подводные камни во время использования такого рода систем. Поэтому решение выбираем, исходя из текущих реалий (об этом можно прочитать у Ивана в статье) и тем как быстро и на приемлемом уровне можем устранить SPOF.
По галере: для внедрения нужен как минимум опыт в команде по её использованию и сопровождению в продакшене под нагрузкой. Галера накладывает ряд ограничений на схему, допустимые операции, локи + обычно всплывают подводные камни во время использования такого рода систем. Поэтому решение выбираем, исходя из текущих реалий (об этом можно прочитать у Ивана в статье) и тем как быстро и на приемлемом уровне можем устранить SPOF.
А почему не решения на Consul KV для переключения типа как тут к примеру https://blog.pythian.com/mysql-high-availability-with-proxysql-consul-and-orchestrator/ ?
Есть в планах как дальнейшее улучшение схемы, но сначала собираемся интегрировать ProxySQL.
А сейчас без проксиsql какие проблемы или неудобства возникают?
И сколько у вас мастеров если не секрет?
И сколько у вас мастеров если не секрет?
Сейчас 5. Без proxysql сложно наращивать кластер web-серверов из-за линейного роста числа коннектов к базам.
А переназначение мастеров будете и в планах делать скриптами вызываемые оркестратором?
А сейчас у вас в конечных приложениях как стоит куда подключаться? К одному ипу?
с proxysql был негативный опыт, когда вдруг прокси перевел ноду из read-only в read-write и поломанная репликация в итоге
А удалось выяснить причину такого поведения?
Нет, так как из прода это сразу убрали, а на форуме proxysql по данной проблеме ничего особо не посоветовали. Кстати вспомнил что на предыдущей работе стоял haproxy для мускула и тоже пришлось отказаться — haproxy вносил ощутимые тормоза.
А какая там была версия и когда по времени это было?
Было в прошлом году, версия proxysql 2.0.2
Были созданы две группы, только-чтение для слейва и чтение-запись для мастера и несколько правил для роутинга запросов. Все работало примерно месяц, пока не случился факап.
UPD. Зашел к ним на гитхаб и сразу вижу такое github.com/sysown/proxysql/issues/2592
Были созданы две группы, только-чтение для слейва и чтение-запись для мастера и несколько правил для роутинга запросов. Все работало примерно месяц, пока не случился факап.
UPD. Зашел к ним на гитхаб и сразу вижу такое github.com/sysown/proxysql/issues/2592
Повесив вип на мастер вы создали себе головную боль сплитбрейнов сами. А могли бы поставить 2 или более хапрокси (лучше proxysql), на них вип и проксировать к мастеру, а у всех нод мускуля свои статичные адреса (лучше днс) и отстрел (из балансировщика и конфигов других нод мускуля) даже если стонит нельзя реализовать. Балансировщики stateless, их можно свободно уничтожать и поднимать и сервис за ними будет избавлен от более сложных в диагностике и исправлений ошибок. Так же получить зомби машину на более простом сервисе, как балансировщик, сложнее, что поднимет стабильность.
Мы сейчас изучаем и постепенно внедряем ProxySql. Когда решение отработаем, планируем перейти на Consul+Orchestrator+Proxy.
По splitbrain: ситуация возможна, если не смогли зайти по ssh на сервер и он не перезагружался. На этот случай подстелили соломку в виде бесконечного arping + ETA дежурного инженера около 3 минут. Эти риски сейчас приемлемы в сравнении с получаемыми преимуществами
А о vitess.io не думали? Очень интересный инструмент.
Сейчас используется в сервисе чатов для шардирования. Vitess имеет интеграцию с оркестратором для обеспечения отказоустойчивости. Но всё же vitess и оркестратор решают разные задачи.
Ну можно же полноценно использовать Vitess без оркестратора? Или отказоустойчивость штатными средствами Vitess будет недостаточно?
Я ещё не до конца дочитал документацию по Vitess, но раз уж вы его используете, то такой вопрос:
Умеет ли vitess.io без Orchestrator автоматически сделать слейв мастером в случае сбоя мастера?
Я ещё не до конца дочитал документацию по Vitess, но раз уж вы его используете, то такой вопрос:
Умеет ли vitess.io без Orchestrator автоматически сделать слейв мастером в случае сбоя мастера?
Использовать, конечно, можно. Но для переключения нужно использовать оркестратор. Вот из документации:
High availability: Vitess integrates with Orchestrator, which is capable of performing a failover to a new master within seconds of failure detection. This is usually sufficient for most applications.
parshinpn, добрый день.
Я вижу, что здесь Вы указываете Orchestrator-у считывать ClusterAlias из БД.
Значит существует таблица cluster в базе meta, которая реплицируется на другие хосты. В этой таблице хранится ClusterAlias одинаковый для всех хостов.
Вот здесь у Вас используется ClusterAlias.
Скажите, пожалуйста, не сталкивались ли Вы с такой ситуацией, когда Orchestrator присваивал ClusterAlias произвольным хостам, которые были вынесены в отдельные кластеры в процессе FailoverProcesses?
Что можете посоветовать в вот такой ситуации?
github.com/openark/orchestrator/issues/1132
Я вижу, что здесь Вы указываете Orchestrator-у считывать ClusterAlias из БД.
"DetectClusterAliasQuery": "select ifnull(max(cluster_name), '') as cluster_alias from meta.cluster where anchor=1",Значит существует таблица cluster в базе meta, которая реплицируется на другие хосты. В этой таблице хранится ClusterAlias одинаковый для всех хостов.
Вот здесь у Вас используется ClusterAlias.
Скажите, пожалуйста, не сталкивались ли Вы с такой ситуацией, когда Orchestrator присваивал ClusterAlias произвольным хостам, которые были вынесены в отдельные кластеры в процессе FailoverProcesses?
Что можете посоветовать в вот такой ситуации?
github.com/openark/orchestrator/issues/1132
Привет,
Да, мы используем ClusterAlias, создавая БД meta и реплицируя ее на все узлы кластера — согласно документации оркестратора.
Во время failover старый мастер автоматически не возвращается в кластер, это уже обязанность администратора сделать. При этом в UI он может показываться как новый кластер, но при его возврате все становится нормально.
Правильно ли я понял, что во время failover у вас кластер из 3 нод развалился на 3 отдельных нереплицирующихся узла?
С приведенным поведением в issue ни разу не доводилось встречаться. Хотя мы при тестировании и iptables, и kill пользовались. Возможно, это связанно с использованием консула
Правильно ли я понял, что во время failover у вас кластер из 3 нод развалился на 3 отдельных нереплицирующихся узла?
Да, но проблема не в этом. Это не просто 3 отдельных нереплицирующихся узла, а в понимании оркестратора 3 отдельных кластера у каждого по 1 нереплицирующемуся узлу.
У каждого из этих кластеров есть свои ClusterName и ClusterAlias:
1) Старый мастер, ClusterName = 10.0.0.31:3306, ClusterAlias = 10.0.0.31:3306
2) Новый мастер, ClusterName = 10.0.0.32:3306, ClusterAlias = testcluster
3) Реплика, которая не смогла подключиться, ClusterName = 10.0.0.33:3306, ClusterAlias = 10.0.0.33:3306
При такой схеме если мы попросим оркестратора отдать адрес мастера testcluster, он вернет 10.0.0.32:3306 и это врено.
Проблема заключается в том, что Оркестратор через некоторое время простоя без каких либо причин присвоил ClusterAlias = testcluster кластеру с репликой, то есть другому кластеру.
После этого картина изменилась следующим образом:
1) Старый мастер, ClusterName = 10.0.0.31:3306, ClusterAlias = 10.0.0.31:3306
2) Новый мастер, ClusterName = 10.0.0.32:3306, ClusterAlias = 10.0.0.32:3306
3) Реплика, которая не смогла подключиться, ClusterName = 10.0.0.33:3306, ClusterAlias = testcluster
А при такой схеме если мы попросим оркестратора отдать адрес мастера testcluster, он вернет 10.0.0.33:3306 и это ошибка!
И это не противоречит его логике.
Понятное дело, что 1 кластер развалился на 3 отдельных и требуется вмешательство администратора. Но реакция администратора может занять определенное время, за которое оркестратор уже создал проблему.
Зависит ли Ваша система от связи ClusterAlias и IP адреса, который хранится под этим ClusterAlias у оркестратора?
ClusterAlias мы используем для именования кластеров в оркестраторе. На основе этих имен мы также:
— используем имя в failover (на основе его определяем VIP, SSH параметры и т.п для этого кластера)
— используем имя в кронах выдачи приоритетов репликам по выбору мастера.
Все внешние клиенты ходят на мастер по VIP (сейчас через ProxySQL), на реплики через HAProxy. Также у оркестратора есть anti-flapping: когда ставится блокировка на failover, у нас она составляет один час.
Если вашу ситуацию можно стабильно воссоздать на тестовом стенде, то я мог бы посмотреть более детально.
— используем имя в failover (на основе его определяем VIP, SSH параметры и т.п для этого кластера)
— используем имя в кронах выдачи приоритетов репликам по выбору мастера.
Все внешние клиенты ходят на мастер по VIP (сейчас через ProxySQL), на реплики через HAProxy. Также у оркестратора есть anti-flapping: когда ставится блокировка на failover, у нас она составляет один час.
Если вашу ситуацию можно стабильно воссоздать на тестовом стенде, то я мог бы посмотреть более детально.
Баг «плавающий», но можете попробовать. Всю необходимую информацию о конфигурации можем предоставить.
Обсуждение данной проблемы и ответ разработчика orchestrator на github.com/openark/orchestrator/issues/1132
Обсуждение данной проблемы и ответ разработчика orchestrator на github.com/openark/orchestrator/issues/1132
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Orchestrator и VIP как HA-решение для кластера MySQL