> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# レプリカ対応ルーティング
> 一時テーブル、セッション、cacheの再利用、書き込み後の読み取り整合性のため、関連するリクエストを同じClickHouse Cloudレプリカにルーティングします
export const EnterprisePlanFeatureBadge = ({feature = 'この機能', support = false, linking_verb_are = false}) => {
return
マルチレプリカの service では、あるレプリカへの書き込みが、レプリケーションが追いつくまで他のレプリカから見えないことがあります。書き込み時に routing value を指定し、後続の読み取りでも同じ値を再利用してください。proxy が両方を同じレプリカにルーティングするため、他のレプリカがまだ追いついていない状態でも、自身の書き込みを読み取れます。このパターンは、書き込んだ直後に同じデータを読み返すワークロード、たとえばインタラクティブなアプリケーションや、次の処理に進む前に insert を検証する ETL ジョブに適しています。
また、スキーマ変更がまだレプリケーションされていない場合にも有効です。routing value を再利用すれば、新しいスキーマをすでに持つレプリカに insert し続けられるためです。
HTTP 経由では、ヘッダー値を再利用します:
```bash theme={null}
# 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: ' \
'https://: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: ' \
'https://:8443/' -d @-
```
ネイティブプロトコル経由の場合は、同じ SNI オーバーライドを再利用します。
```bash theme={null}
# Write with a routing value
clickhouse client \
--host \
--secure \
--tls-sni-override my-workload-1.sticky. \
--query "INSERT INTO events VALUES (now(), 'signup')"
# Read it back on the same replica, using the same value
clickhouse client \
--host \
--secure \
--tls-sni-override my-workload-1.sticky. \
--query 'SELECT count() FROM events'
```
すべてのレプリカにわたるより広範な保証が必要な場合は、ClickHouse Cloud で [`select_sequential_consistency`](/ja/reference/settings/session-settings#select_sequential_consistency) を `1` に設定することもできます。
接続先のレプリカを確認する
同じ routing value を使用して、`SELECT hostName()` の例のいずれかを再度実行します。レプリカ数が変わらない限り、同じホスト名が返されるはずです。異なる routing value は、別のレプリカにマッピングされる場合があります。
レプリカ対応ルーティングの制約事項
レプリカ数の変更によりスティッキー性が変化します
スケールアウト/スケールインにより、ルーティングのハッシュリングが変化します。その結果、同じ routing value を共有するリクエストが別のレプリカに振り分けられる場合があります。一時テーブルやセッションレベルの設定に依存している場合は、再マップ後にそれらを再作成できるようにしておいてください。`SELECT hostName()` を実行すれば、現在どのレプリカに接続しているかを常に確認できます。
HTTP ベースのルーティングとネイティブプロトコルのルーティングはいずれも、通常のサービスホスト名で[プライベートネットワーキング](/ja/products/cloud/guides/security/connectivity/private-networking)を使用する場合は動作します。追加の DNS エントリは必要ありません。