すべてのプロダクト
Search
ドキュメントセンター

Elasticsearch:CCR を使用したクラスター間のデータレプリケーション

最終更新日:Mar 29, 2026

クラスター間レプリケーション (CCR) は、リーダー クラスターから 1 つ以上のフォロワー クラスターにインデックスデータをほぼリアルタイムでレプリケーションします。これにより、リモートディザスタリカバリ、読み書き分離、地理的に分散したアクセスが可能になります。このトピックでは、Elasticsearch の一般的なディザスタリカバリソリューションを比較し、CCR の仕組みを説明して、適切なソリューションを選択するのに役立てます。

ソリューションの比較

Elasticsearch (ES) は、次のリモートディザスタリカバリソリューションをサポートしています。

  • OSS スナップショット:インデックスデータを Alibaba Cloud Object Storage Service (OSS) にバックアップして永続ストレージに保存します。最初のスナップショットは完全バックアップで、後続のスナップショットは増分です。クラスター間 OSS リポジトリを使用して、スナップショットデータを送信先 ES インスタンスに復元できます。詳細については、「クラスター間 OSS リポジトリの設定」をご参照ください。

  • Logstash:パイプラインを設定して、ソース ES クラスターからデータを読み取り、処理して、送信先クラスターに書き込みます。このソリューションは、メジャーバージョン間のデータ移行や、データフィルタリングと変換が必要なシナリオに適しています。詳細については、「クイックスタート」をご参照ください。

  • Reindex:組み込みの Reindex API を使用して、すべてのデータまたは特定の条件を満たすデータをあるインデックスから別のインデックスにコピーします。このソリューションはクラスター間の操作をサポートしており、小規模なデータセットの 1 回限りの移行に適しています。詳細については、「Reindex API を使用したデータ移行」をご参照ください。

  • クラスター間レプリケーション (CCR):書き込み可能なインデックスをリーダー クラスターから 1 つ以上のフォロワー クラスターに非同期かつ増分的にレプリケーションします。このソリューションはほぼリアルタイムの同期をサポートしており、低い目標復旧時点 (RPO) と目標復旧時間 (RTO) が求められるディザスタリカバリのシナリオに最適です。

ソリューションの比較

ソリューション

利用シーン

RPO

復旧時間目標

主な制限事項

OSS スナップショット

大規模データ (GB から PB) の定期的なバックアップと復元。

数時間から数日 (スナップショットの間隔に依存)。

数時間 (データ量とシャードの回復時間に依存)。

継続的な同期をサポートしていません。回復中にサービスの停止時間が必要になる場合があります。

Logstash

リアルタイム要件が低いデータ移行、データフィルタリングや変換が必要なシナリオ、メジャーバージョン間の移行。

数秒から数分 (同期の頻度に依存)。

数時間 (データ量とインスタンスのパフォーマンスに依存)。

バッチ同期のみで、リアルタイムではありません。削除操作の同期はサポートしていません。

Reindex

小規模なデータセットの 1 回限りのインデックス移行。

適用外 (1 回限りの操作)。

数分から数時間 (データ量に依存)。

継続的な同期をサポートしていません。大規模なデータ移行には非効率です。

CCR

リモートディザスタリカバリ、読み書き分離、地理的に分散したアクセス。

ほぼゼロ (秒)。

数秒から数分。

フォロワーインデックスは読み取り専用です。マッピングとシャード数が同一である必要があります。

低い RPO と低レイテンシが求められるリモートディザスタリカバリのシナリオでは、CCR が最良の選択です。

  • CCR は数秒でデータを同期するため、データ損失を最小限に抑えます。

  • リーダー クラスターに障害が発生した場合、スナップショットの復元を待たずに、トラフィックをフォロワー クラスターにリダイレクトしてサービスを復旧できます。

  • 初期のデプロイコストは高くなりますが、CCR はデータ損失によるビジネス上の損失を防ぐことで、長期的にはより費用対効果が高くなります。

仕組み

アーキテクチャ

CCR はアクティブ/パッシブアーキテクチャを使用します。リーダー クラスターがすべての書き込み操作を受け取り、フォロワー クラスターは読み取り専用で、リーダー クラスターからデータをレプリケーションします。

  • リーダー クラスター:すべての書き込み操作を処理するソースクラスター。

  • フォロワー クラスター:読み取り専用で、CCR を使用してリーダー クラスターからデータを同期する送信先クラスター。

データレプリケーションのプロセス

CCR のデータレプリケーションプロセスは、2 つのフェーズで構成されます。

初期化

フォロワー クラスターは、リーダー クラスターに初期化リクエストを送信します。その後、リーダー クラスターは、スナップショットリストアの仕組みと同様に、リーダーインデックスからフォロワーインデックスにすべての Lucene セグメントファイルを転送します。

増分同期

フォロワーインデックスの各シャードは、定期的にリーダー クラスターにプルリクエストを送信し、最後の同期ポイント以降の最新の操作をフェッチします。デフォルトでは、これは 1 秒ごとに発生します。プロセスは次のとおりです。

  1. プル開始点の特定:フォロワー クラスターは、ローカルで正常に適用された最新の操作を示すローカルの remote_checkpoint を維持します。このチェックポイントは、リーダー クラスターのトランザクションログ (translog) の global_checkpoint に対応します。

  2. リーダーの translog から操作を読み取る:リーダー クラスターは、フォロワー クラスターから提供された from_seq_no を使用して、自身の translog 内の開始位置を見つけます。その後、後続のすべての操作 (インデックス、更新、削除) を読み取り、リストとして返します。

  3. フォロワー クラスターで操作をリプレイする:フォロワー クラスターは、これらの操作をローカルで順番にリプレイし、自身の remote_checkpoint を更新します。バージョンの競合などが原因でリプレイが失敗した場合、同期は一時停止され、エラーがログに記録されます。

  4. 継続的なポーリング:フォロワー クラスターは、固定の間隔で新しい操作を継続的にポーリングし、通常はサブ秒レベルのレイテンシを実現します。

translog の役割

トランザクションログ (translog) は、CCR における増分同期のデータソースです。Elasticsearch では、次の目的を果たします。

  • データ損失の防止:デフォルトでは、Elasticsearch は 1 秒ごとにリフレッシュを実行し、インメモリバッファから検索可能な新しい Lucene セグメントを作成します。ただし、このセグメントはまだディスクにフラッシュされていません。translog はすべての書き込み操作を記録します。ノードがクラッシュした場合、ログをリプレイすることでデータを回復できます。

  • レプリカの一貫性の確保:Elasticsearch は、まず操作を translog に書き込み、次にそれをレプリカシャードに転送します。プライマリシャードとレプリカシャードの両方が書き込みを確認した後にのみ、成功の応答を返します。

  • CCR での増分同期のサポート:CCR は、Elasticsearch の内部 API を使用して translog を読み取り、指定されたシーケンス番号以降のすべての変更をフェッチします。これにより、ほぼリアルタイムのデータレプリケーションが可能になります。

translog はシャードごとに個別に保存されます。各シャードには、indices/{index_uuid}/{shard_id}/translog/ に独自の translog ディレクトリがあります。Translog ファイル (.tlog) はバイナリ形式で保存され、世代管理の仕組みを使用して管理されます。Elasticsearch は、フラッシュが発生するたび、またはファイルがサイズ制限 (デフォルトでは 512 MB) に達するたびに、新しい世代ファイルを作成します。

Alibaba Cloud ES のための CCR ネットワーク

Alibaba Cloud Elasticsearch インスタンスは、お客様の VPC ではなく、専用の管理 VPC にデプロイされます。2 つのクラスターが同じリージョンにある場合や、それらの VPC が CEN を使用してリージョン間で接続されている場合でも、プライベートネットワークを介して直接通信することはできません。NLB と PrivateLink を使用して管理 VPC を接続する必要があります。

2 つのクラスターが同じリージョンにあるかどうかに基づいて、適切なドキュメントを選択してください。

シナリオ

説明

ドキュメント

同じリージョン

リーダー クラスターとフォロワー クラスターが同じリージョンにあります。NLB と PrivateLink を使用して、それらの管理 VPC を接続します。

同じリージョン内の ES クラスター間でデータをレプリケーションする

リージョン間

リーダー クラスターとフォロワー クラスターが異なるリージョンにあります。まず CEN を使用してお客様の VPC を接続し、次に NLB と PrivateLink を使用してそれらの管理 VPC を接続する必要があります。

リージョンをまたいで ES クラスター間でデータをレプリケーションする

制限事項

  • 両方のクラスターの管理デプロイモードは、クラウドネイティブ新管理 (v3) である必要があります。クラスターが v1 または v2 アーキテクチャの場合、まずそのアーキテクチャをアップグレードする必要があります。詳細については、「インスタンスアーキテクチャのアップグレード」をご参照ください。

    Elasticsearch クラスターのアーキテクチャバージョンを確認するには、Elasticsearch コンソールにログインします。インスタンスの 基本情報 ページで、デプロイコントロールモード を表示します。モードは クラウドネイティブの新しいコントロール (v3) または 基本コントロール (v2) のいずれかです。

  • 両方のクラスターは Elasticsearch 7.10.0 以降を実行している必要があります。フォロワー クラスターのバージョンは、リーダー クラスターのバージョンと同じか、それ以降である必要があります。

  • フォロワーインデックスは読み取り専用であり、書き込み操作をサポートしていません。ターゲットインデックスを書き込み可能にするには、次の操作を実行します。

    1. フォロータスクを一時停止する: POST /<index>/_ccr/pause_follow

    2. インデックスを閉じる: POST /<index>/_close

    3. インデックスのフォローを解除する: POST /<index>/_ccr/unfollow

    4. インデックスを再度開いて読み書き可能にする: POST /<index>/_open

  • リーダーインデックスとフォロワーインデックスは、マッピングとシャード数が同一である必要があります。フォロワーインデックスのシャード数を変更することはできません。