SOLR / Zookeeper / Kafka のセットアップがあります。それぞれが別々の VM 上にあります。
2つのSOLR 4.9 VM(Ubuntu)を使用して、これをすべて正常に実行しました
ここで、2 つの SOLR 5.4 VM をビルドして、すべてを再び機能させたいと考えています。
要は「交換によるアップグレード」
私は自分の問題の解決策を「ハッキング」しましたが、それは私を非常に緊張させます.
まず、Zookeeper が実行されています。SOLR 4.9 VM をオフにして、Zookeeper から構成を削除します (必ずしもこの順序である必要はありません... ;-) )
ここで、SOLR Wiki の「Production Install」手順に従って SOLR 5.4 をインストールした「solr5」VM (およびクラウド モードの SOLR) を起動します。「solr6」にも 5.4 をインストールしましたが、まだ実行されていません。
「solr5」マシンで次のコマンドを発行します。
/opt/solr/bin/solr create -c fooCollection -d /home/john/conf -shards 1 -replicationFactor 1
次の出力が得られます。
Connecting to ZooKeeper at 192.168.56.5,192.168.56.6,192.168.56.7/solr ...
Re-using existing configuration directory statdx
Creating new collection 'fooCollection' using command:
http://localhost:8983/solr/admin/collections?action=CREATE&name=fooCollection&numShards=1&replicationFactor=1&maxShardsPerNode=1&collection.configName=fooCollection
{
"responseHeader":{
"status":0,
"QTime":3822},
"success":{"":{
"responseHeader":{
"status":0,
"QTime":3640},
"core":"fooCollection_shard1_replica1"}}}
すべてがうまくいっています。マイクロサービスをオンにすると、すべての SOLR ドキュメントが Kafka から「solr5」に送られます。
ここで、「solr6」をコレクションに追加します。ハック以外にこれを行う方法が見つかりません(後で説明します)。
以前にコレクションを作成するために使用したコマンドは、コレクションが既に存在するという観察結果でエラーになります。
私が望むことを行うzkcli.shまたはsolrコマンドはないようです。APIコマンドもこれを行うようには見えません。
(SOLR? Zookeeper?) に言う簡単な方法はありませんか? SOLR ノードに別のマシンを追加したいのですが、最初の (solr5) のように構成して、データの複製を開始してください。
create コマンドを発行したときに、両方のマシンを実行する必要があったのでしょうか。
SOLRをアップグレードする必要があるたびに、Prodで同じ種類のアプローチを行うための「解決策」を考え出す必要があるため、これを行うための「承認された」方法に感謝します。
今私のハックのために。これに関する明確なドキュメントを見つけるのに 2 日かかることを覚えておいてください。炎はやめてください、これは物事を行う方法ではないことを完全に理解しています。少なくとも、これが物事を行う方法ではないことを願っています...
- コレクションの作成コマンドが 'solr5' (/opt/solr/server/solr/fooCollection_shard1_replica1) に配置した場所から fooCollection ディレクトリを、'solr6' VM の同じ場所にコピーします。
- コレクション ディレクトリ名に対して論理的に見える変更を行います (fooCollection_shard1_replica2 になります)。
- core.properties ファイルで論理的に見える変更を行います。
参考までに、create コマンドで作成された core.properties ファイルを次に示します。
#Written by CorePropertiesLocator
#Wed Jan 20 18:59:08 UTC 2016
numShards=1
name=fooCollection_shard1_replica1
shard=shard1
collection=fooCollection
coreNodeName=core_node1
ハッキングが完了したときの「solr6」でのファイルの外観は次のとおりです。
#Written by CorePropertiesLocator
#Wed Jan 20 18:59:08 UTC 2016
numShards=1
name=fooCollection_shard1_replica2
shard=shard1
collection=fooCollection
coreNodeName=core_node2
これを行って「solr6」を再起動すると、すべてが金色に見えました。「クラウド」Web ページは、管理者 Web ページで正しく表示されました。「solr5」にドキュメントを追加すると、管理者 Web ページから直接ヒットすると、「solr6」で使用可能になりました。
このようなハックなしでこれを達成する方法を誰かが教えてくれたらありがたいです...またはこれが正しい方法である場合...
=============================
@Maniと提案された手順への回答
ありがとうマニ - 私はあなたの手順に従ってこれを非常に慎重に試しました.
最後に、コレクション ステータス クエリから次の出力を取得します。
john@solr6:/opt/solr$ ./bin/solr healthcheck -z 192.168.56.5,192.168.56.6,192.168.56.7/solr5_4 -c fooCollection
{
"collection":"fooCollection",
"status":"healthy",
"numDocs":0,
"numShards":1,
"shards":[{
"shard":"shard1",
"status":"healthy",
"replicas":[{
"name":"core_node1",
"url":"http://192.168.56.15:8983/solr/fooCollection_shard1_replica1/",
"numDocs":0,
"status":"active",
"uptime":"0 days, 0 hours, 6 minutes, 24 seconds",
"memory":"31 MB (%6.3) of 490.7 MB",
"leader":true}]}]}
これは、私がずっと実験で見つけてきた結果のようなものです。コアはSOLR VMの1つ(コレクションを作成するためにコマンドラインを発行したもの)で作成されますが、他のVMでは何も作成されません-以下の手順に基づいて、私はあなたを信じていますまた、発生するはずだと思いましたか?
また、5.4 では、このコマンドは healthstatus ではなく「healthcheck」であることを読んでいる人には注意してください。コマンド ラインはすぐに表示されるので、大したことではありません。
===============
更新 1 :: 2 番目のコアの手動追加
他の VM に移動し、手動で次を追加するとします。
sudo mkdir /opt/solr/server/solr/fooCollection_shard1_replica2
sudo mkdir /opt/solr/server/solr/fooCollection_shard1_replica2/data
nano /opt/solr/server/solr/fooCollection_shard1_replica2/core.properties
(in here I add only collection=fooCollection and then save/close)
次に、同じ VM で SOLR サーバーを再起動します。 sudo /opt/solr/bin/solr restart -c -z zoo1,zoo2,zoo3/solr
管理コンソールに 2 つ目のノードが魔法のように表示されます。これは「フォロワー」(IE はリーダーではありません) であり、両方ともクラウド UI の「shard1」から分岐します。
これが「道」かどうかはわかりませんが、これまでに見つけた唯一の方法です。その時点まで再現し、管理 UI を試してみて、何が得られるかを確認します。それがうまくいけば、時が来れば私のIT担当者にとっては少し楽になるでしょう。
===============
更新 2 :: create コマンドのわずかな変更
@Mani - 私はあなたの手順に従って成功したと信じています.多くのことと同様に、理解すれば簡単です.
すべてをリセットし(ディレクトリを削除し、zookeeper(rmr /solr)をクリアし、すべてを最初からやり直しました。
「作成」コマンドを次のように少し変更しました。
./bin/solr create -c fooCollection -d /home/john/conf -shards 1 -replicationFactor 2
1 ではなく「replicationFactor 2」に注意してください。
突然、実際に両方の VM にコアがありました。
いくつかのメモ:
Zookeeper IP アドレスを使用してクラウド モードで SOLR 5.4 サーバーを起動しただけでは、ステータス コールから満足のいく結果が得られないことがわかりました。Zookeeper の「ノード」はまだ作成されていません。
その時点で create コマンドも失敗しました。
これを回避する方法は、zkcli.sh を使用して次のように構成をロードすることでした。
sudo /opt/solr/server/scripts/cloud-scripts/zkcli.sh -cmd upconfig -confdir /home/john/conf/ -confname fooCollection -z 192.168.56.5/solr
このコマンドを実行した直後に Zookeeper を確認すると、/solr/configs/fooCollection の「パス」がありました。
今、作成コマンドが機能し、構成をオーバーライドしたい場合は、試していませんが、その時点でオーバーライドできたと思います。
私はどの時点で肯定的ではありませんが、ステータスなどですべてを見つけるために、SOLRサーバーを再起動する必要があったようです(おそらく作成コマンドの後)...何度も。create コマンドの実行後に疑問がある場合は、サーバーの再起動を試してください。(これは、正しく解決される IP アドレスまたは名前である可能性があります)
sudo /opt/solr/bin/solr restart -c -z zoo1,zoo2,zoo3/solr
sudo /opt/solr/bin/solr restart -c -z 192.168.56.5,192.168.56.6,192.168.56.7/solr
@Mani の推奨手順にこれらのわずかな変更を加えた後、リーダーと「フォロワー」をそれぞれ異なる VM の /opt/solr/server/solr ディレクトリ (この場合は fooCollection) に取得し、データを送信することができました1 つに接続し、IP アドレスをヒットする管理コンソールを介してもう 1 つを検索します。
=============
バリエーション
これを読んでいる人なら誰でも試してみたいと思うかもしれないことの 1 つは、単に Zookeeper で別の「ノード」を作成することです (たとえば、solr5_4)。
私はこれを試してみましたが、それは魅力のように機能します。Zookeeper アンサンブルに関連付けられている /solr chroot が表示される場所はどこでも、/solr5_4 に置き換えることができます。これにより、新しい SOLR 5.4「環境」を構築している間、古い SOLR VM が Prod で機能し続けることができ、同じ Zookeeper VM を両方に使用できます。異なる chroot は相互作用やオーバーラップを保証しないためです。
繰り返しますが、Zookeeper の「ノード」は構成のアップロードを行うまで作成されませんが、このように SOLR プロセスを開始する必要があります。そうしないと、後で間違ったコンテキストになってしまいます。chrootとして「solr5_4」に注意してください。
sudo /opt/solr/bin/solr restart -c -z zoo1,zoo2,zoo3/solr5_4
テストが完了すると、solr5_4 の「環境」が Prod にとって重要になり、solr の SOLR 4.x VM と Zookeeper の「ノード」を削除できます。ロード バランサーを新しい SOLR VM に向けて、ユーザーが気付かないうちにスイッチオーバーを実行するのは、かなり簡単なことです。
この戦略は、SOLR 6、6.5、7 などで機能します。
このコマンドは、コレクション/コアの追加にも機能しました。ただし、solr サーバーを最初に実行する必要がありました。
http://192.168.56.16:8983/solr/admin/collections?action=CREATE&name=fooCollection&numShards=1&replicationFactor=2&collection.configName=fooCollection
==================
交換によるアップグレードとして使用
明らかでない場合は、この手法 (特に /solr5_4 などの Zookeeper で「新しい」chroot を使用する場合) を使用すると、古いバージョンの SOLR を必要なだけ実行したままにしておくことができます。必要に応じて、すべてのデータの再インデックス作成に数日かかることを許可します。
試したことはありませんが、インデックスのバックアップも新しいマシンにドロップできると思います。
これは、アップグレードのストレスを軽減し、簡単にするためのアプローチであることを読者に理解してもらいたかっただけです。(その場でアップグレードする必要はありません。新しい VM を構築し、最新バージョンの SOLR をインストールするだけです。)
これにより、ハンマーを落としてロードバランサーを新しいSOLR IPアドレスにリダイレクトする準備が整うまで、製品に影響を与えることなく切り替えを行うことができます(もちろん、すでにテスト済みです...)
ここでの 1 つの前提は、一連の SOLR VM または物理サーバーを起動して、既に運用環境にあるものと一致させるためのリソースがあることです。明らかに、所有しているボックスまたは VM のみにリソースが制限されている場合は、インプレース アップグレードが唯一の選択肢になる可能性があります。