本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。
ストレージボリュームのリカバリに関する警告を確認します
共同作成者
変更を提案
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 を再構築すると、アラームは解除されます。アラームがクリアされない場合は、テクニカルサポートにお問い合わせください。 |