バックアップ/エクスポートとリストア Transformation Advisor データ

オンライン編集

インストール構成で、 persistence.enabled の値を false に設定した場合、データはコンテナ内にのみ保存され、コンテナが再起動すると失われる。

Transformation Advisor で使用される永続ボリュームは、ベストプラクティスに従ってバックアップされるべきである。

データのバックアップ/エクスポート Transformation Advisor データ

オプション1：APIを使用したエクスポート Transformation Advisor API

については Transformation AdvisorRed Hat OpenShift の場合、データのバックアップには Transformation Advisor APIを使うのが、データのバックアップには最適である。 詳細については、 HTTP エンドポイントを介した Transformation Advisor データのエクスポートとインポートのドキュメントを参照。 特に、一括エクスポートAPIについて説明した、 ワークスペースのすべてのzipファイルをエクスポートするというセクションを参照のこと。

オプション 2: データ・ディレクトリーの保管

以下のデータディレクトリを保存する Transformation Advisor ローカル

ローカルインストールの場合 Transformation Advisor ローカルインストールの場合、データディレクトリを保存するのがデータのバックアップに最適です。 また Transformation Advisor APIを使用してローカル・インストールのデータをバックアップすることもできますが、データ・ディレクトリを保存する方が便利でしょう。 ローカルがインストールされている Transformation Advisor ローカルがインストールされている場所に行く。 data ディレクトリと graph_data ディレクトリを探し、バックアップしたい場所にコピーする。 また、 .neo4j_pass ファイルをコピーする必要がある。

cp -a <some location>/data <backup location>/data
cp -a <some location>/graph_data <backup location>/graph_data
cp -a <some location>/scripts/.neo4j_pass <backup location>/scripts/

のデータ・ディレクトリを保存する。 Transformation Advisor について Red Hat OpenShift

のデータディレクトリを直接バックアップまたはリストアすることはお勧めしません。 Transformation AdvisorRed Hat OpenShift のデータ・ディレクトリを直接バックアップまたはリストアすることは推奨されません。

データのリストア/インポート Transformation Advisor データ

を使用したインポート Transformation Advisor API

以前に Transformation Advisor APIを使用してデータをバックアップしたことがある場合は、APIを使用してそのデータを Transformation Advisor. このオプションの詳細については、 HTTP エンドポイントを介した Transformation Advisor データのエクスポートとインポートを参照のこと。

データ・ディレクトリーのリストア

以下のデータ・ディレクトリをリストアする。 Transformation Advisor ローカル

  1. の場所までcdを送る。 Transformation Advisor ローカル Transformation Advisor ダウンロードしたzip)
  2. データを新しい場所にリストアする：
    • cp -a <backup location>/data .
    • cp -a <backup location>/graph_data .
    • cp -a <backup location>/scripts/.neo4j_pass scripts/
  3. 新しい場所にインストール Transformation Advisor :
    • ./launch.sh
    • ご使用条件を受け入れます。
    • オプション1（インストール）を選択します。

のデータ・ディレクトリをリストアする。 Transformation Advisor について Red Hat OpenShift

のデータディレクトリを直接バックアップまたはリストアすることはお勧めしません。 Transformation AdvisorRed Hat OpenShift のデータ・ディレクトリを直接バックアップまたはリストアすることは推奨されません。

の以前のバージョンにロールバックする。 Transformation Advisor

の以前のバージョンにロールバックする場合は、そのバージョンと互換性のあるデータを使用することが重要です。 Transformation Advisor にロールバックする場合、そのバージョンと互換性のあるデータを使用することが重要である。 Transformation Advisor は、古いバージョンの新しいデータを自動的に変換しない。 例:

  1. インストール Transformation Advisor3.0.0
  2. データのバックアップ 3.0.0
  3. へのアップグレード 3.1.0
  4. データのバックアップ 3.1.0
  5. にロールバックする。 3.0.0

このシナリオでは、最初にバックアップしたデータを Transformation Advisor3.0.0. 3.1.0 からのバックアップは使用できません。

拡張バックアップおよびリストア・オプション

以下の拡張オプションは、他のバックアップ・オプションおよびリストア・オプションで失敗した場合にのみ使用してください。

PersistentVolumeClaim の保持

をアンインストールすることができる。 Transformation Advisor をアンインストールしても、 PersistentVolumeClaim 。 この手順は、以下のシナリオで役立ちます。

  • のバージョンをアンインストールして Transformation Advisor をアンインストールして新しいバージョンをインストールしたいが、簡単に古いバージョンに戻したい場合。 これは、 2.5.x から 3.0.x に移行する場合に推奨される。
  • 自動シームレス・アップグレードが不可能な場合 Transformation Advisor 自動シームレスアップグレードが不可能な場合（例えば、 2.3.x から 2.4.x にアップグレードする場合など）に、バージョンアップをまたいでデータを保持したい場合。 この方法では、 2.5.x から 3.0.x に移行する際にデータが保持されない。

この方法の限界は、 PersistentVolumeClaim を再利用できるのは、元々使われていたのと同じ名前空間だけだということだ。

注： この手順は、保存したい PersistentVolumeClaim がインストールの一部として自動的に作成された場合に使用する。 Transformation Advisor インストールの一部として自動的に作成された場合に使用する必要があります。 手動で作成した PersistentVolumeClaim を使用してインストールする場合、以下の手順は必要ないかもしれません。 PersistentVolumeClaim で以下のコマンドを実行する。
kubectl get pvc <my-pvc-name> -n <ta-namespace> -o yaml | grep ownerReferences

このコマンドで ownerReferences が表示されない場合は、この手順は必要ありません。 Transformation Advisor を削除すれば、 PersistentVolumeClaim は残る。 データは必ず事前にバックアップしておくこと。

PersistentVolumeClaim を維持するには、以下の手順に従うこと：

  1. を削除する。 Transformation Advisorsubscription と clusterserviceversion。 これでオペレーターもいなくなる。 <ta-namespace> を、インストールが存在する実際の名前空間に置き換える。

    export subscription=$(kubectl get subscription --no-headers -n <ta-namespace> | awk '{print $1}')
kubectl delete subscription ${subscription} -n <ta-namespace> >/dev/null 2>&1

export csv=$(kubectl get csv --no-headers -n <ta-namespace> | awk '{print $1}')
kubectl delete csv ${csv} -n <ta-namespace>

    オペレーターポッドが消えるまで待つ。 ta-operator-XXX がなくなるまで、 oc get pods 。

  2. インスタンスから PersistentVolumeClaim 。 Transformation Advisor インスタンスから切り離す。

    export pvc_name=$(oc get deployment -n <ta-namespace> | grep couchdb | awk '{print$1}')
kubectl patch pvc ${pvc_name} -n <ta-namespace> --type=json -p='[{"op": "remove", "path": "/metadata/ownerReferences"}]'

  3. インスタンスを削除する。 Transformation Advisor インスタンスを削除します。

    # Run this command in the background using '&'
kubectl delete transadvs.charts.ta.cloud.ibm.com/ta -n <ta-namespace> &
kubectl patch transadvs.charts.ta.cloud.ibm.com/ta -p '{"metadata":{"finalizers":[]}}' --type=merge -n <ta-namespace>

    ネームスペース内のポッドがすべてなくなるまで待つ。

  4. CustomResourceDefinition を取り外す。

    # Run this command in the background using '&'
kubectl delete crd/transadvs.charts.ta.cloud.ibm.com &
kubectl patch crd/transadvs.charts.ta.cloud.ibm.com -n <ta-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

  5. ネームスペース内の他の Transformation Advisor 名前空間内の他のリソースをクリーンアップする。

    kubectl delete secret transformation-advisor-secret -n <ta-namespace>

export operator_group=$(oc get operatorgroup -n <ta-namespace> --no-headers | awk '{print $1}')
kubectl delete operatorgroup ${operator_group} -n <ta-namespace>

kubectl delete clusterrolebinding <ta-namespace>-cluster-admin -n <ta-namespace>;

  6. 保存された PersistentVolumeClaim を再利用する場合、構成の詳細については、 ストレージの構成と インストールを参照してください。

    • OpenShift UI経由でインストールする場合は、永続性プロパティが保存されたクレームと一致していることを確認してください（たとえば、同じ accessMode ）。

      ...
  persistence:
    enabled: true
    accessMode: "ReadWriteOnce"
    size: 8Gi
    useDynamicProvisioning: true
    existingClaim: "<my-ta-pvc>"
    storageClassName: ""
    supplementalGroups: []
...

    • CASE インストーラーを使用してインストールする場合は、 --persistenceClaim <my-ta-pvc> を使用して既存のクレームを指定する。

  7. オプション： 新しいバージョンの Transformation Advisor をインストールした後、 PersistentVolumeClaim を新しいインスタンスにアタッチすることができます。 これにより、インスタンスを削除するとそのクレームも削除されるデフォルトの動作が復元される。

    export uid=$(oc get transadvs.ta.ibm.com/ta -o yaml -n <ta-namespace> | grep uid | awk 'NR==1{print$2}')

kubectl patch pvc <my-ta-pvc> --type=json -p='[{"op": "add", "path": "/metadata/ownerReferences", "value": [{"apiVersion": "ta.ibm.com/v1", "blockOwnerDeletion": true, "controller": true, "kind": "TransAdv", "name": "ta", "uid": "'${uid}'"}]}]'

目標復旧時点

最も重要なのは Transformation Advisor 最も重要なデータは、データ収集中に Transformation Advisor である。 これらのアーカイブは、組織のポリシーに従ってバックアップされ、保持されるべきである。

オリジナルのデータ収集アーカイブから復元できないデータは、以下のものだけである：

  • 手動で作成されたアプリケーション・グループ
  • コレクション名の変更

データがアプリケーションにロードされると、 APIを使ってデータを取得したりバックアップしたりできる。 bulkExport API は、すべてのデータのアーカイブを返します。 Transformation Advisor データ (グループ、ワークスペース、およびコレクションに加えられた変更を含む) のアーカイブを返します。 このアーカイブは、 bulkImport APIを使用して新しいインストールにインポートすることができます。

bulkExport API を使用して定期的にバックアップすることをお勧めします。 また、定期的にデータベースをバックアップすることもできます（ バックアップオプションを参照）。

リカバリーポイントの目標を決める際には、以下の要素を考慮する：

  • への新しいデータのアップロード頻度 Transformation Advisor
  • アップロードされたデータに対する変更の頻度と量（グループの作成、編集、削除、ワークスペース名やコレクション名の編集）
  • バックアップされたオリジナル・データ Transformation Advisor データ収集アーカイブ