А можно немного подробнее про long polling: в случае множества параллельных запросов как определяется кому какие сообщения отдавать? Допустим мы ожидаем для первого сообщения пока наберется нужное количество. Что в этот момент делают остальные запросы?
Нет ли в тарантуле инструмента миграций? Например, есть спейс с заданным форматом, необходимо его обновить. Или удалить, добавить индекс. Правильно понимаю, что сейчас это делается руками через консоль?
`APP_DEBUG` был включен, отключение сильно не повлияло. Думаю, это связано с тем что до этого явно отключил логирование в Doctrine.
По paratest: разные настройки крутил, но результат чуть лучше чем без него либо даже хуже в случае использования functional (в документации у них как раз сказано, что functional даже медленнее будет из-за накладных расходов). По ядрам: запускал с 2, 4 и 8.
А вот что помогло, это использование `--runner WrapperRunner`. Вышел за 2 минуты: `Time: 01:59.494`
ClusterAlias мы используем для именования кластеров в оркестраторе. На основе этих имен мы также:
— используем имя в failover (на основе его определяем VIP, SSH параметры и т.п для этого кластера)
— используем имя в кронах выдачи приоритетов репликам по выбору мастера.
Все внешние клиенты ходят на мастер по VIP (сейчас через ProxySQL), на реплики через HAProxy. Также у оркестратора есть anti-flapping: когда ставится блокировка на failover, у нас она составляет один час.
Если вашу ситуацию можно стабильно воссоздать на тестовом стенде, то я мог бы посмотреть более детально.
С приведенным поведением в issue ни разу не доводилось встречаться. Хотя мы при тестировании и iptables, и kill пользовались. Возможно, это связанно с использованием консула
Привет,
Да, мы используем ClusterAlias, создавая БД meta и реплицируя ее на все узлы кластера — согласно документации оркестратора.
Во время failover старый мастер автоматически не возвращается в кластер, это уже обязанность администратора сделать. При этом в UI он может показываться как новый кластер, но при его возврате все становится нормально.
Правильно ли я понял, что во время failover у вас кластер из 3 нод развалился на 3 отдельных нереплицирующихся узла?
Зависит от задачи, может вам шардирование и не нужно. Лично не знаком с витессом, но коллеги вроде довольны, хорошо справляется со своей основной функцией — шардированием данных в MySQL
Использовать, конечно, можно. Но для переключения нужно использовать оркестратор. Вот из документации:
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.
Сейчас используется в сервисе чатов для шардирования. Vitess имеет интеграцию с оркестратором для обеспечения отказоустойчивости. Но всё же vitess и оркестратор решают разные задачи.
Мы сейчас изучаем и постепенно внедряем ProxySql. Когда решение отработаем, планируем перейти на Consul+Orchestrator+Proxy.
По splitbrain: ситуация возможна, если не смогли зайти по ssh на сервер и он не перезагружался. На этот случай подстелили соломку в виде бесконечного arping + ETA дежурного инженера около 3 минут. Эти риски сейчас приемлемы в сравнении с получаемыми преимуществами
Важно иметь баланс между производительностью и надежностью.
По галере: для внедрения нужен как минимум опыт в команде по её использованию и сопровождению в продакшене под нагрузкой. Галера накладывает ряд ограничений на схему, допустимые операции, локи + обычно всплывают подводные камни во время использования такого рода систем. Поэтому решение выбираем, исходя из текущих реалий (об этом можно прочитать у Ивана в статье) и тем как быстро и на приемлемом уровне можем устранить SPOF.
Будет статья на эту тему. В целом все зависит от механизма переключения, поэтому и готового решения нет. Оркестратор предназначен для обнаружения проблем с кластером и запуска пользовательских механизмов восстановления топологии.
А можно немного подробнее про long polling: в случае множества параллельных запросов как определяется кому какие сообщения отдавать? Допустим мы ожидаем для первого сообщения пока наберется нужное количество. Что в этот момент делают остальные запросы?
По paratest: разные настройки крутил, но результат чуть лучше чем без него либо даже хуже в случае использования functional (в документации у них как раз сказано, что functional даже медленнее будет из-за накладных расходов). По ядрам: запускал с 2, 4 и 8.
А вот что помогло, это использование `--runner WrapperRunner`. Вышел за 2 минуты: `Time: 01:59.494`
— используем имя в failover (на основе его определяем VIP, SSH параметры и т.п для этого кластера)
— используем имя в кронах выдачи приоритетов репликам по выбору мастера.
Все внешние клиенты ходят на мастер по VIP (сейчас через ProxySQL), на реплики через HAProxy. Также у оркестратора есть anti-flapping: когда ставится блокировка на failover, у нас она составляет один час.
Если вашу ситуацию можно стабильно воссоздать на тестовом стенде, то я мог бы посмотреть более детально.
С приведенным поведением в issue ни разу не доводилось встречаться. Хотя мы при тестировании и iptables, и kill пользовались. Возможно, это связанно с использованием консула
Привет,
Да, мы используем ClusterAlias, создавая БД meta и реплицируя ее на все узлы кластера — согласно документации оркестратора.
Во время failover старый мастер автоматически не возвращается в кластер, это уже обязанность администратора сделать. При этом в UI он может показываться как новый кластер, но при его возврате все становится нормально.
Правильно ли я понял, что во время failover у вас кластер из 3 нод развалился на 3 отдельных нереплицирующихся узла?
Использовать, конечно, можно. Но для переключения нужно использовать оркестратор. Вот из документации:
Мы сейчас изучаем и постепенно внедряем ProxySql. Когда решение отработаем, планируем перейти на Consul+Orchestrator+Proxy.
По splitbrain: ситуация возможна, если не смогли зайти по ssh на сервер и он не перезагружался. На этот случай подстелили соломку в виде бесконечного arping + ETA дежурного инженера около 3 минут. Эти риски сейчас приемлемы в сравнении с получаемыми преимуществами
А удалось выяснить причину такого поведения?
По галере: для внедрения нужен как минимум опыт в команде по её использованию и сопровождению в продакшене под нагрузкой. Галера накладывает ряд ограничений на схему, допустимые операции, локи + обычно всплывают подводные камни во время использования такого рода систем. Поэтому решение выбираем, исходя из текущих реалий (об этом можно прочитать у Ивана в статье) и тем как быстро и на приемлемом уровне можем устранить SPOF.
Будет статья на эту тему. В целом все зависит от механизма переключения, поэтому и готового решения нет. Оркестратор предназначен для обнаружения проблем с кластером и запуска пользовательских механизмов восстановления топологии.