本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。
ストレージボリュームのリカバリに関する警告を確認しています
共同作成者
変更を提案
PDF
ストレージノードの障害ストレージボリュームをリカバリする前に、次の警告を確認する必要があります。
ストレージノード内のストレージボリューム（ rangedb ）は、ボリューム ID と呼ばれる 16 進数で識別されます。たとえば、 0000 は最初のボリューム、 000F は 16 番目のボリュームです。各ストレージノードの最初のオブジェクトストア（ボリューム 0 ）は、オブジェクトメタデータと Cassandra データベースの処理に最大 4TB のスペースを使用します。このボリュームの残りのスペースはオブジェクトデータに使用されます。他のすべてのストレージボリュームは、オブジェクトデータ専用のボリュームです。
ボリューム 0 で障害が発生してリカバリが必要な場合は、ボリュームリカバリ手順 の一部として Cassandra データベースの再構築が必要になることがあります。次の状況でも、 Cassandra が再構築されることがあります。
-
ストレージノードが 15 日以上オフラインになったあと、オンラインに戻ります。
-
システムドライブと 1 つ以上のストレージボリュームで障害が発生し、リカバリされた。
Cassandra の再構築時、システムは他のストレージノードからの情報を使用します。オフラインのストレージノードが多すぎると、一部の Cassandra データを使用できない可能性があります。最近 Cassandra が再構築された場合は、 Cassandra データの一貫性がまだグリッド全体で確保されていないことがあります。オフラインのストレージノードが多すぎる場合や複数のストレージノードが 15 日以内に再構築されている場合は、データ損失が発生する可能性があります。
|
複数のストレージノードで障害が発生した場合（またはオフラインの場合）は、テクニカルサポートにお問い合わせください。次のリカバリ手順 は実行しないでください。データが失われる可能性があります。 |
|
|
ストレージノードの障害またはリカバリ後 15 日以内に 2 つ目のストレージノードの障害が発生した場合は、テクニカルサポートにお問い合わせください。15 日以内に複数のストレージノードで Cassandra を再構築すると、データが失われることがあります。 |
|
サイトの複数のストレージノードで障害が発生した場合は、サイトリカバリ手順 が必要になる可能性があります。テクニカルサポートにお問い合わせください。 |
|
レプリケートコピーを 1 つだけ保存するように ILM ルールを設定している場合に、そのコピーがあるストレージボリュームで障害が発生すると、オブジェクトをリカバリできません。 |
|
|
リカバリ中に Services ： Status - Cassandra （ SVST ）アラームが発生した場合は、監視とトラブルシューティングの手順を参照して、 Cassandra を再構築してアラームからリカバリしてください。Cassandra を再構築すると、アラームは解除されます。アラームが解除されない場合は、テクニカルサポートに連絡してください。 |
関連情報