Направляйте связанные запросы на одну и ту же реплику ClickHouse Cloud для временных таблиц, сеансов, повторного использования кэша и согласованности чтения после записи
Маршрутизация с учетом реплик (также известная как липкие сеансы, липкая маршрутизация или привязка сеанса) направляет связанные запросы на одну и ту же реплику ClickHouse. Используйте ее, если временные таблицы или именованное состояние сеанса должны оставаться доступными между запросами, если связанные запросы должны повторно использовать локальный кэш одной и той же реплики или если требуется согласованность чтения после записи между записью и последующими операциями чтения.Она работает по принципу best-effort и не гарантирует изоляцию. Прокси сопоставляет каждое значение маршрутизации с одной репликой. Сопоставление остается стабильным, пока число реплик не изменяется; при масштабировании сервиса значение может быть сопоставлено с другой репликой.
Требуется HTTP-интерфейсМаршрутизация с учетом реплик применяется на уровне прокси через интерфейс HTTP/HTTPS. ClickHouse Cloud переводит маршрутизацию с учетом реплик с session_id на заголовок X-ClickHouse-Replica-Tag. На вкладках ниже описаны оба метода на время этого перехода.Маршрутизация с учетом реплик в настоящее время недоступна через собственный протокол (собственный порт, например драйвер clickhouse-go, работающий в режиме собственного протокола по умолчанию). Клиентам собственного протокола необходимо перейти на HTTP и передавать значение маршрутизации в каждом запросе.
Откройте тикет в службу поддержки и попросите включить HTTP-маршрутизацию запросов к репликам с закреплением сеанса. Укажите ID вашего сервиса и причину, по которой она вам нужна (временные таблицы, состояние сеанса, повторное использование кэша или согласованность чтения после записи). Перед миграцией существующего сервиса попросите службу поддержки подтвердить, что для него включена маршрутизация на основе заголовков. Продолжайте использовать session_id, пока не получите подтверждение; X-ClickHouse-Replica-Tag не обеспечит липкую маршрутизацию, пока развертывание не дойдет до вашего сервиса. Перезапуск не требуется.
Чтобы закрепить рабочую нагрузку за репликой, передавайте заголовок X-ClickHouse-Replica-Tag через HTTPS-интерфейс. Прокси применяет согласованное хеширование к значению заголовка, поэтому запросы с одинаковым значением направляются к одной и той же реплике, пока число реплик не меняется. Другое значение хешируется независимо и может попасть на ту же или другую реплику, но выбрать, какой именно реплике будет соответствовать значение, нельзя.Используйте существующее имя хоста сервиса. Специальные закреплённые имена хостов или изменения DNS не требуются. Значением заголовка может быть любая строка на ваш выбор, например имя приложения, идентификатор пользователя или метка рабочей нагрузки. Для запросов без заголовка сохраняется обычная балансировка нагрузки.Указывайте заголовок X-ClickHouse-Replica-Tag в каждом запросе:
X-ClickHouse-Replica-Tag обеспечивает закрепление за репликой без создания HTTP-сеанса ClickHouse. Параллельные запросы могут использовать один и тот же тег, не сталкиваясь с SESSION_IS_LOCKED.
В сервисе с несколькими репликами запись, выполненная на одной реплике, может быть не видна на других, пока репликация не завершится. Отправьте запись с заголовком X-ClickHouse-Replica-Tag, а затем используйте то же значение заголовка при последующих операциях чтения. Прокси направит оба запроса на одну и ту же реплику, поэтому вы сможете прочитать собственную запись, даже если другие реплики всё ещё отстают. Этот подход подходит для рабочих нагрузок, при которых данные записываются, а затем сразу считываются, например для интерактивных приложений или задач ETL, проверяющих вставки перед продолжением работы.Для более строгих гарантий на всех репликах можно также установить select_sequential_consistency в значение 1 в ClickHouse Cloud.
Снова выполните пример SELECT hostName() с тем же значением X-ClickHouse-Replica-Tag. Пока число реплик не изменится, вы должны получить то же имя хоста. Другое значение заголовка может соответствовать другой реплике.
X-ClickHouse-Replica-Tag заменяет session_id для маршрутизации с учетом реплик. Продолжайте использовать session_id, пока служба поддержки не подтвердит, что для вашего сервиса включена маршрутизация по заголовкам.
Поскольку session_id создает HTTP-сеанс ClickHouse, в одном сеансе одновременно может выполняться только один запрос.
После включения маршрутизации по заголовкам для вашего сервиса рабочие нагрузки, которым нужна только привязка к реплике, могут перейти на X-ClickHouse-Replica-Tag. Параллельные запросы могут использовать один и тот же тег реплики.
Если вам требуется состояние HTTP-сеанса ClickHouse, выполняйте последовательно запросы с общим session_id.
Чтобы закрепить рабочую нагрузку за репликой, передавайте параметр запроса session_id через HTTPS-интерфейс. Прокси применяет согласованное хеширование к значению параметра, поэтому запросы с одинаковым значением направляются на одну и ту же реплику, пока число реплик не меняется. Другое значение хешируется независимо и может попасть на ту же или другую реплику, но выбрать, какой именно реплике будет соответствовать значение, нельзя.Используйте существующее имя хоста сервиса. Специальные sticky-имена хостов или изменения DNS не требуются. Значением session_id может быть любая выбранная вами строка, например имя приложения, идентификатор пользователя или метка рабочей нагрузки. Для запросов без session_id сохраняется обычная балансировка нагрузки.Указывайте параметр запроса session_id в каждом запросе:
В сервисе с несколькими репликами запись, выполненная на одной реплике, может быть недоступна на других, пока репликация не завершится. Выполните запись с session_id, а затем используйте тот же session_id для последующих операций чтения. Прокси направит обе операции на одну и ту же реплику, поэтому вы сможете прочитать собственную запись, даже если другие реплики всё ещё отстают. Этот подход подходит для рабочих нагрузок, в которых данные записываются, а затем сразу считываются, например для интерактивных приложений или задач ETL, проверяющих вставки перед дальнейшей обработкой.Чтобы получить более строгие гарантии для всех реплик, в ClickHouse Cloud также можно установить select_sequential_consistency в значение 1.
Проверка реплики, на которую направляет session_id
Снова выполните пример SELECT hostName() с тем же session_id. Пока количество реплик не изменится, вы должны получить то же имя хоста. Другой session_id может быть сопоставлен с другой репликой.
Маршрутизация на основе поддоменов больше не включается для новых сервисов. Если вы уже используете sticky-поддомены, обратитесь в поддержку, чтобы перейти на метод с HTTP-заголовком.
Как работает устаревшая маршрутизация на основе поддоменов
Ранее включение маршрутизации с учетом реплик позволяло использовать подстановочный поддомен для имени хоста сервиса. Для сервиса с именем хоста abcxyz123.us-west-2.aws.clickhouse.cloud любое имя хоста, соответствующее шаблону *.sticky.abcxyz123.us-west-2.aws.clickhouse.cloud (например, aaa.sticky.abcxyz123.us-west-2.aws.clickhouse.cloud), Envoy по хешу направлял на одну и ту же реплику. Исходное имя хоста по-прежнему использовало балансировку нагрузки LEAST_CONNECTION — алгоритм маршрутизации по умолчанию.
Масштабирование наружу или внутрь меняет кольцо хеширования маршрутизации. В результате запросы с одинаковым значением маршрутизации могут попасть на другую реплику. Если вы используете временные таблицы или настройки на уровне сеанса, будьте готовы создать их заново после переназначения.
Маршрутизация с учетом реплик не является изоляцией рабочих нагрузок
Липкая маршрутизация определяет только то, какая реплика обрабатывает запрос. Эта реплика по-прежнему может обслуживать и другой трафик. Для выделенных вычислительных ресурсов используйте compute-compute separation.
Маршрутизация на основе HTTP работает с частным сетевым подключением на стандартном хосте вашего сервиса. Дополнительные записи DNS не требуются.Устаревший метод с поддоменом так не работает: нужно добавить DNS для шаблона хоста *.sticky.*, а неправильная настройка может привести к неравномерному распределению нагрузки между репликами.
Для маршрутизации с учетом реплик требуется HTTP-протокол
Липкая маршрутизация использует HTTP-заголовок или параметр запроса в зависимости от метода маршрутизации, доступного для вашего сервиса. Собственный бинарный протокол не передает ни одного из этих значений, по которым HTTP-прокси мог бы вычислить хеш, поэтому маршрутизация с учетом реплик недоступна через собственный протокол. Чтобы использовать эту возможность, клиентам собственного протокола необходимо перенести соответствующую рабочую нагрузку на HTTP-интерфейс.
Запросы по-прежнему направляются на разные реплики при одном и том же значении маршрутизации
Убедитесь, что используете метод маршрутизации, доступный для вашего сервиса: заголовок X-ClickHouse-Replica-Tag или устаревший URL-параметр запроса session_id.
Убедитесь, что во всех запросах используется точно одно и то же значение маршрутизации.
Немного подождите после включения. Изменения могут вступить в силу менее чем за минуту.
Проверьте, не изменилось ли недавно количество реплик: после масштабирования ожидается переназначение. Используйте SELECT hostName(), чтобы определить новое соответствие.
