こんにちは、Matt

まず、これは私の側でも長い間課題となっていたことです。

複数のSolrCloudクラスターを含むホットホットアーキテクチャには、多くの課題があります。ここで重要な質問は、バージョン管理を自分で行うかどうかです。また、更新がデータを上書きすることがあるかどうかです。この点に関する初期提案は以下のリンクにありますが、バージョン管理されていないドキュメントの編集を伴うホットホット設定には対応していません。
https://cwiki.apache.org/confluence/display/SOLR/SIP-13%3A+Cross+Data+Center+Replication

ホットホットのセットアップは非常に複雑で、いくつかの方法で対処してきました（または対処しているのを見てきました）。

1. ここでの最善の方法は、外部でバージョン管理されたドキュメントをSolrクラスターに送信することです。
2. または、単一のエントリーポイントを頼りにする、つまり更新は常にキューイングサービスに送られ、その後、このキューから消費するアプリケーションに任せる方法です。

Anshum

Solrに特有の話ではありませんが、アクティブ-パッシブのHA（高可用性）を行う方が、アクティブ-アクティブ（ホット-ホット）よりもはるかに簡単です（もしそれがあなたの言うホット-ホットの意味であれば）。

Dima

Anshum、Dima、ありがとうございます！はい、このアプローチを実装するのはかなり難しく、コストに見合わないかもしれません。

Anshum

バージョン管理（https://solr.apache.org/guide/8_2/updating-parts-of-documents.html#document-centric-versioning-constraints）については考えていませんでしたが、検討します。はい、いくつかの更新はアトミックアップデートです。

初期の考えとしては、更新の「キュー」を1つ使い、同じインデックスサービスの複数のインスタンス（特定のSolrCloudインスタンスに関連するもの）がキューから消費し、関連するSolrCloudインスタンスにインデックスする方法です。

あなたの提案を見てみます！

再度、ありがとうございます。

Matt

「検索フィード」を作成しています。これは、1行に1つのJSONオブジェクトが含まれるS3ファイルです。Solrに送られるドキュメントはまずフィードファイルに入ります。定期的に、これらのファイルが取得され、Solrにロードされます。

S3はリージョンを跨いで利用できるため、複数のホットサーチクラスターに対して簡単に使用できます。これをメジャーバージョンアップグレードに頻繁に利用しています。新しいバージョン8のクラスターを作成し、フィードファイルからSolr 6およびSolr 8のクラスターにそれぞれ独立してフィードします。トラフィックが移行された後、Solr 6クラスターへのフィードを停止し、マシンを再利用します。

災害復旧のために、クラスターを再構築（Terraform）し、その後ローダーを実行します。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)