Маршрутизация с учетом реплик

Направляйте связанные запросы на одну и ту же реплику ClickHouse Cloud для временных таблиц, сеансов, повторного использования кэша и согласованности чтения после записи

Маршрутизация с учетом реплик (также известная как липкие сеансы, липкая маршрутизация или привязка сеанса) направляет связанные запросы на одну и ту же реплику ClickHouse. Используйте ее, если временные таблицы или именованное состояние сеанса должны оставаться доступными между запросами, если связанные запросы должны повторно использовать локальный кэш одной и той же реплики или если требуется согласованность чтения после записи между записью и последующими операциями чтения.

Она работает по принципу best-effort и не гарантирует изоляцию. Прокси сопоставляет каждое значение маршрутизации с одной репликой. Сопоставление остается стабильным, пока число реплик не изменяется; при масштабировании сервиса значение может быть сопоставлено с другой репликой.

Маршрутизация с учетом реплик доступна через оба интерфейса:

• Через HTTP/HTTPS с использованием заголовка X-ClickHouse-Replica-Tag.
• Через собственный протокол с использованием переопределения TLS Server Name Indication (SNI).

Оба варианта включаются отдельно и используют одно и то же согласованное хеширование на стороне прокси.

​

Предварительные требования

• Вашему сервису требуется 2 или более реплики. В сервисе с одной репликой привязывать попросту не к чему.
• Сервис уровня Enterprise.
• Поддерживается в стандартных сервисах ClickHouse Cloud и BYOC

​

Настройка маршрутизации с учетом реплик

Клиенты уровня Enterprise включают маршрутизацию с учетом реплик на странице настроек сервиса в ClickHouse Cloud console. Откройте свой сервис, перейдите в раздел Settings и включите переключатель для нужного интерфейса:

• Один переключатель включает маршрутизацию на основе HTTP по заголовку X-ClickHouse-Replica-Tag.
• Отдельный переключатель включает routing по native-протоколу через override SNI.

Можно включить один из них или оба. Перезапуск не требуется, изменения вступают в силу менее чем за минуту.

Переключатели постепенно появляются в планах уровня Enterprise. Если на вашем сервисе их ещё нет, создайте тикет в поддержку, указав ID сервиса, чтобы возможность включили раньше.

​

Маршрутизация на основе HTTP

Чтобы закрепить рабочую нагрузку за репликой, передавайте заголовок X-ClickHouse-Replica-Tag через HTTPS-интерфейс. Прокси применяет согласованное хеширование к значению заголовка, поэтому запросы с одинаковым значением направляются к одной и той же реплике, пока число реплик не меняется. Другое значение хешируется независимо и может попасть на ту же или другую реплику, но выбрать, какой именно реплике будет соответствовать значение, нельзя.

Используйте существующее имя хоста сервиса. Специальные закреплённые имена хостов или изменения DNS не требуются. Значением заголовка может быть любая строка на ваш выбор, например имя приложения, идентификатор пользователя или метка рабочей нагрузки. Для запросов без заголовка сохраняется обычная балансировка нагрузки.

Указывайте заголовок X-ClickHouse-Replica-Tag в каждом запросе:

echo 'SELECT hostName()' | curl \
  -H 'X-ClickHouse-Replica-Tag: my-workload-1' \
  -H 'X-ClickHouse-User: default' \
  -H 'X-ClickHouse-Key: <password>' \
  'https://<host>:8443/' -d @-

Для clickhouse-go (v2) укажите Protocol: clickhouse.HTTP и передайте заголовок через параметр подключения HttpHeaders.

X-ClickHouse-Replica-Tag обеспечивает закрепление за репликой без создания HTTP-сеанса ClickHouse. Параллельные запросы могут использовать один и тот же тег, не сталкиваясь с SESSION_IS_LOCKED.

​

Маршрутизация по собственному протоколу

При работе через собственный протокол передавайте значение маршрутизации как имя TLS-сервера в формате <routing-value>.sticky.<host>. Подключайтесь к обычному имени хоста вашего сервиса, как обычно. Клиент ClickHouse принимает значение маршрутизации через параметр --tls-sni-override:

clickhouse client \
  --host <host> \
  --secure \
  --tls-sni-override my-workload-1.sticky.<host> \
  --query 'SELECT hostName()'

--host — это обычное имя хоста вашего сервиса, --secure включает TLS, а --tls-sni-override передаёт значение маршрутизации. Использование TLS обязательно. Дополнительный сертификат или DNS-запись не требуются.

​

Согласованность чтения после записи

В сервисе с несколькими репликами запись, выполненная на одной реплике, может быть не видна на остальных, пока репликация не догонит. Отправляйте запись вместе со значением маршрутизации, а затем используйте то же значение при последующих чтениях. Прокси направит и запись, и чтение на одну и ту же реплику, поэтому вы прочитаете собственную запись даже тогда, когда другие реплики ещё отстают. Такой подход хорошо подходит для рабочих нагрузок, которые записывают данные и тут же читают их обратно, — например, для интерактивных приложений или ETL-задач, проверяющих вставки перед переходом к следующему шагу.

Он также помогает после изменения схемы, которое ещё не реплицировалось: повторное использование значения маршрутизации удерживает вставки на реплике, где новая схема уже применена.

По HTTP используйте то же значение заголовка:

# Write, tagged with a routing value
echo "INSERT INTO events VALUES (now(), 'signup')" | curl \
  -H 'X-ClickHouse-Replica-Tag: my-workload-1' \
  -H 'X-ClickHouse-User: default' \
  -H 'X-ClickHouse-Key: <password>' \
  'https://<host>:8443/' -d @-

# Read it back on the same replica, using the same value
echo 'SELECT count() FROM events' | curl \
  -H 'X-ClickHouse-Replica-Tag: my-workload-1' \
  -H 'X-ClickHouse-User: default' \
  -H 'X-ClickHouse-Key: <password>' \
  'https://<host>:8443/' -d @-

При работе по собственному протоколу используйте то же переопределение SNI:

# Write with a routing value
clickhouse client \
  --host <host> \
  --secure \
  --tls-sni-override my-workload-1.sticky.<host> \
  --query "INSERT INTO events VALUES (now(), 'signup')"

# Read it back on the same replica, using the same value
clickhouse client \
  --host <host> \
  --secure \
  --tls-sni-override my-workload-1.sticky.<host> \
  --query 'SELECT count() FROM events'

Для более широких гарантий на всех репликах в ClickHouse Cloud можно также задать select_sequential_consistency равным 1.

​

Проверьте, к какой реплике вы подключены

Снова выполните один из примеров SELECT hostName() с тем же значением маршрутизации. Пока число реплик не изменится, вы должны получить то же имя хоста. Другое значение маршрутизации может соответствовать другой реплике.

​

Ограничения маршрутизации с учетом реплик

​

Привязка меняется при изменении числа реплик

Масштабирование наружу или внутрь меняет кольцо хеширования маршрутизации. В результате запросы с одинаковым значением маршрутизации могут попасть на другую реплику. Если вы используете временные таблицы или настройки на уровне сеанса, будьте готовы создать их заново после переназначения. Запрос SELECT hostName() всегда покажет, на какой реплике вы находитесь.

​

Маршрутизация с учетом реплик не является изоляцией рабочих нагрузок

Липкая маршрутизация определяет только то, какая реплика обрабатывает запрос. Эта реплика по-прежнему может обслуживать и другой трафик. Для выделенных вычислительных ресурсов используйте compute-compute separation.

​

Частное сетевое подключение

Маршрутизация как на основе HTTP, так и на основе native-протокола работает с частным сетевым подключением на стандартном имени хоста вашего сервиса. Дополнительные записи DNS не требуются.

​

Маршрутизация по собственному протоколу требует TLS

Для маршрутизации по собственному протоколу необходим TLS, поэтому передавайте --secure. Для незашифрованного native-соединения сохраняется обычная балансировка нагрузки.

​

Устранение неполадок

Запросы по-прежнему направляются на разные реплики при одном и том же значении маршрутизации

• Убедитесь, что переключатель для используемого вами интерфейса включен на странице настроек сервиса. HTTP- и native-методы включаются по отдельности.
• При работе по HTTP убедитесь, что каждый запрос содержит заголовок X-ClickHouse-Replica-Tag и что во всех запросах используется точно одно и то же значение.
• При работе по собственному протоколу убедитесь, что задан параметр --secure, а --tls-sni-override имеет форму <routing-value>.sticky.<host>.
• Немного подождите после включения. Изменения могут вступить в силу менее чем за минуту.
• Проверьте, не изменилось ли недавно количество реплик: после масштабирования ожидается переназначение. Используйте SELECT hostName(), чтобы определить новое соответствие.

Ошибки сертификата при работе по собственному протоколу

• Убедитесь, что в --host указано обычное имя хоста вашего сервиса, а значение маршрутизации передается через --tls-sni-override, а не через --host.