ストレージボリュームの回復に関する警告
変更を提案
PDF
ストレージ ノードの障害が発生したストレージ ボリュームを回復する前に、次の警告を確認してください。
ストレージ ノード内のストレージ ボリューム (または rangedb) は、ボリューム ID と呼ばれる 16 進数で識別されます。たとえば、0000 は最初のボリューム、000F は 16 番目のボリュームです。各ストレージ ノードの最初のオブジェクト ストア (ボリューム 0) は、オブジェクト メタデータと Cassandra データベース操作に最大 4 TB のスペースを使用します。そのボリュームの残りのスペースはオブジェクト データに使用されます。その他のすべてのストレージ ボリュームは、オブジェクト データ専用に使用されます。
ボリューム 0 に障害が発生し、回復する必要がある場合、ボリューム回復手順の一環として Cassandra データベースが再構築される可能性があります。 Cassandra は次のような状況でも再構築される可能性があります。
-
ストレージ ノードは、15 日以上オフラインになった後にオンラインに戻ります。
-
システム ドライブおよび 1 つ以上のストレージ ボリュームに障害が発生し、回復されました。
Cassandra が再構築されると、システムは他のストレージ ノードからの情報を使用します。オフラインのストレージノードが多すぎると、一部の Cassandra データが利用できなくなる可能性があります。Cassandra が最近再構築された場合、Cassandra データはグリッド全体でまだ一貫していない可能性があります。オフラインのストレージ ノードが多すぎるときに Cassandra が再構築された場合、または 2 つ以上のストレージ ノードが 15 日以内に再構築された場合、データ損失が発生する可能性があります。
|
複数のストレージ ノードに障害が発生した場合 (またはオフラインの場合) は、テクニカル サポートにお問い合わせください。次の回復手順を実行しないでください。データが失われる可能性があります。 |
|
|
ストレージ ノードの障害または回復後 15 日以内に 2 回目のストレージ ノード障害が発生した場合は、テクニカル サポートに連絡してください。 15 日以内に 2 つ以上のストレージ ノードで Cassandra を再構築すると、データが失われる可能性があります。 |
|
サイトの複数のストレージ ノードに障害が発生した場合は、サイトの回復手順が必要になることがあります。見る"テクニカルサポートがサイトを復旧する方法" 。 |
|
|
ILM ルールが複製されたコピーを 1 つだけ保存するように設定されていて、そのコピーが障害が発生したストレージ ボリューム上に存在する場合、オブジェクトを回復することはできません。 |