日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

既知の問題

寄稿者 netapp-mwallis netapp-bcammett

ストレージクラスを設定してアプリケーションを導入すると、アプリケーションのクローンが失敗する

ストレージクラスを明示的に設定してアプリケーションをデプロイした後 ( たとえば、「 helm install…​-set global.storageClass=NetApp-cvs-perf-extreme 」 ) 、アプリケーションのクローンを作成しようとすると、ターゲットクラスタに最初に指定されたストレージクラスが必要になります。ストレージクラスを明示的に設定したアプリケーションを、同じストレージクラスを含まないクラスタにクローニングすると、失敗します。このシナリオではリカバリ手順はありません。

特定のバージョンの PostgreSQL を使用すると、アプリケーションクローンが失敗します

Bitnami PostgreSQL 11.5.0 チャートを使用すると、同じクラスタ内のアプリケーションクローンは一貫して失敗します。正常にクローニングするには、以前のバージョンのグラフを使用してください。

既存の Snapshot ではなく新しい Snapshot から作成されたバックアップ

バックアップを作成して * 既存のスナップショットからバックアップ * を選択すると、 Astra Control はそのスナップショットを使用してバックアップを作成します。Astra Control は、既存のスナップショットを使用しません。

カスタムアプリケーション実行フックスクリプトがタイムアウトし、原因のスナップショット後のスクリプトが実行されない

実行フックの実行に 25 分以上かかる場合 ' フックは失敗し ' 戻りコードが N/A のイベント・ログ・エントリが作成されます影響を受けた Snapshot はタイムアウトして失敗とマークされ、タイムアウトを通知するイベントログエントリが生成されます。

実行フックは、実行中のアプリケーションの機能を低下させたり、完全に無効にしたりすることが多いため、カスタム実行フックの実行時間を最小限に抑えるようにしてください。

クローンのパフォーマンスが大規模な永続ボリュームによる影響を受ける

非常に大容量で消費されている永続ボリュームのクローンが、オブジェクトストアへのクラスタアクセスによって断続的に低速になる可能性があります。クローンが停止し、データが 30 分以上コピーされていない場合、 Astra Control はクローン処理を終了します。

同じネームスペースで同時にアプリケーションのリストア処理を実行しようとすると失敗することがあります

ネームスペース内の個別に管理されたアプリケーションを同時にリストアしようとすると、長時間後にリストア処理が失敗することがあります。回避策として、各アプリケーションを一度に 1 つずつリストアします。

外部スナップショットバージョン 4.2.0 を使用している場合、スナップショットは最終的に失敗します

Kubernetes 1.20 または 1.21 で Kubernetes snapshot-controller (別名 external-snapshotter )バージョン 4.2.0 を使用すると、 Snapshot が失敗することがあります。これを防ぐには、別のを使用してください "サポートされているバージョン" バージョン 4.2.1 などの外部 Snapshot データ。 Kubernetes バージョン 1.20 または 1.21 で使用。

アプリケーションバックアップの実行を停止できません

実行中のバックアップを停止する方法はありません。バックアップを削除する必要がある場合は、完了するまで待ってから、の手順を実行してください "バックアップを削除します"。失敗したバックアップを削除するには、を使用します "Astra API"