クローン作成ターゲットインスタンスのデータ保持

リリースバージョン: Yokohama

更新日 2025年01月30日

所要時間：15分

データプリザーバーを使用して、ターゲットインスタンスのデータが上書きされないようにすることができます。カスタムアプリケーションがある場合は、未公開のアプリケーションコンテンツも手動で保持する必要があります。

データプリザーバー

クローン作成対象のインスタンスでデータを保持する必要がある場合があります。たとえば、ターゲットが MID サーバーの場合、MID サーバー [ecc_agent] テーブルを上書きしてはなりません。保持されたデータは、クローン作成が開始される前はターゲットインスタンスに保存され、クローン作成後にターゲットインスタンスに復元されます。

警告:

ソースインスタンスでデータプリザーバーを定義する必要があります。ターゲットインスタンスで定義しても、データは保持されません。

データプリザーバーは通常、次のようなシステム設定とテーマを保持します。

インスタンス固有の認証設定
ブックマーク [sys_ui_bookmark]
最近の選択 [sys_ui_recent_selection]
ユーザー設定 [sys_user_preference]

注:

クローンは、データベースビューからのデータの保持をサポートしていません。

データプリザーバーを使用して、ユーザーグループなどの大量のデータを転送しないでください。ユーザー、グループ、ロールなどのテーブルデータを保持する必要がある場合は、クローン作成後にレコードをファイルにエクスポートすることを検討してください。

マルチ SSO のデータプリザーバー

複数プロバイダーのシングルサインオン統合をアクティブにすると、クローン作成に必要なデータプリザーバーが自動的に作成されます。


名前	テーブル	条件
証明書	X.509 証明書 [sys_certificate]	なし
コアインスタンスのプロパティ	システムプロパティ [sys_properties]	[または] [名前] [は次のいずれか] [glide.authenticate.external, glide.authenticate.external.logout_redirect] [または] [名前] [次で始まる] [com.snc.integration.saml_esig] [または] [名前] [は次のいずれか] [glide.smtp.port、glide.smtp.auth、glide.smtp.encryption] [または] [名前] [は次の値で始まる] [glide.authenticate.multisso] [または] [名前] [次の値に等しい] [glide.authenticate.sso.redirect.idp] 注: プロパティ glide.smtp.port、 glide.smtp.auth、および glide.smtp.encryption は廃止されました。
ダイジェストプロパティ	ダイジェストプロパティ [digest_properties]	なし
ID プロバイダー	ID プロバイダー [sso_properties]	なし
SAML2 Update1 プロパティ	SAML2 Update1 プロパティ [saml2_update1_properties]	なし

注:

これらのデータプリザーバーは変更できますが、変更しないことをお勧めします。複数のソースのシングルサインオン (SSO) が正しく機能するには、ダイジェストプロパティ [digest_properties]、ID プロバイダー [sso_properties]、および SAML2 Update1 プロパティ [saml2_update1_properties] テーブルが必要です。ターゲットインスタンスで複数のソースのシングルサインオンが無効になっている場合は、3 つのデータプリザーバーをすべて安全に削除できます。これらのテーブルのうち 1 つまたは 2 つが保持された状態でクローンを作成しようとすると、エラーメッセージが表示されてクローンが終了するため、それらを同時に削除します。

SAML のデータプリザーバー

SAML SSO 関連の設定を保持すると、ターゲットインスタンスが IdP への認証要求を行うときに間違った発行者と対象者のパラメーターを使用するのを防ぐことができます。SAML 設定を保持するには、次のテーブルのデータプリザーバーを作成します。

システムプロパティ [sys_properties]：SAML プロパティを保持します。
X.509 証明書 [sys_certificate]：SAML 証明書を保持します。
ユーザー [sys_user]：SAML ユーザーを保持します。

SAML に関連するプロパティとユーザーも保持する必要があります。

未公開アプリケーションの保持

データプリザーバーを使用して未公開のアプリケーションを保持することはできません。代わりに、アプリケーション開発者は未公開のアプリケーションを保持する方法を選択する必要があります。

クローン作成プロセスでは、開発中のアプリケーションのバージョンの差異は保存されません。その代わりに、システムクローンでは、ソースインスタンスにインストールされているアプリケーションバージョンのみが、ターゲットインスタンスにコピーされます。ターゲットインスタンスに同じアプリケーションの開発バージョンがある場合、そのアプリケーションはクローン作成後に編集可能になりますが、ソースインスタンスにインストールされているバージョンになります。アプリケーションがソースインスタンスから失われていた場合は、クローン作成プロセスによりターゲットインスタンスからアプリケーションが削除されます。

データプリザーバーの作成

データプリザーバーは、指定されたデータをターゲットインスタンスで維持します。

始める前に

必要なロール：clone_admin または admin

このタスクについて

ターゲットインスタンスの特定のデータを保持することが望ましい場合があります。たとえば、MID サーバーを使用している場合は、MID サーバー [ecc_agent] テーブルの上書きを回避できます。保持されたデータは、クローンの前にターゲットインスタンスで動的に生成されたリストに保存され、クローンの完了後にターゲットインスタンスで復元されます。ソースインスタンスでデータプリザーバーを定義します。

データプリザーバーは、主にインスタンス固有の認証設定などのシステム設定とテーマを保持することを目的としています。データプリザーバーを使用して、ユーザーグループなどの大量のデータを転送しないでください。ユーザー、グループ、ロールなどのテーブルデータを保持する必要がある場合は、レコードをファイルにエクスポートし、クローンの完了後にインポートすることを検討してください。

次のテーブルのデータを保持するかどうかを検討してください。

ブックマーク [sys_ui_bookmark]
最近の選択 [sys_ui_recent_selection]
ユーザー設定 [sys_user_preference]

ソースインスタンスがターゲットインスタンスよりも多くのレコードを持つテーブルにデータプリザーバーを設定した場合、ターゲットインスタンスに保持されるデータにはソースインスタンスの追加レコードも含まれます。

たとえば、データプリザーバーが既に配置されているとします。

ソースインスタンスでは、sys_temp テーブルに 100 のレコードが含まれています。
ターゲットインスタンスでは、sys_temp テーブルに 20 のレコードが含まれています。

クローンの後、ターゲットインスタンスの sys_temp テーブルには 100 のレコードが含まれます。

ターゲットの sys_temp テーブル内の 20 のレコードは正常に保持されます (データプリザーバーの仕様に準拠)。これらのレコードは、ソースの sys_temp テーブルの 100 のレコードの一部でした。
ソースの sys_temp テーブルは、残りの 80 のレコードをターゲットの sys_temp テーブルに渡します。

この問題を解決し、ターゲットテーブルのレコードのみを保持するには、ソーステーブルでデータプリザーバーを設定することに加えて、ターゲットテーブルの除外テーブルレコードを作成します。

重要:

ソースインスタンスでプリザーバーを設定します。

手順

ソースインスタンスで、次の場所に移動します: システムクローン > データを保存.
[New] をクリックします。
テーブルラベルを [名前] として入力します。たとえば、[sys_user_preference] テーブルの場合は「ユーザー設定」です。
データプリザーバーにはテーブル名が必要です。指定しないと送信できません。
保持する [テーブル] を選択します。
データプリザーバーではテーブルを選択する必要があります。指定しないと送信できません。
保持されるデータが UI プロパティの場合は、[テーマ] チェックボックスをオンにします。
保持するデータを定義するには、条件ビルダーを使用します。
条件を使用して、クローン中に保持する特定のレコードを定義できます。たとえば、特定のシステムプロパティのみを保持する場合は、保持するプロパティ名ごとに条件を追加できます。
注:
正規表現に一致する条件 [match regex] はサポートされなくなりました。

警告:
バックアップからのクローンが何らかの理由で失敗した場合、クローンプロセスは従来のクローンエンジンにフェイルオーバーします。従来のクローンエンジンは、拡張テーブル、関係、テーブル間の階層、およびドット連結クエリからのデータを保持できません。このような場合は、システムクローンを再スケジュールするか、手動でデータを転送する必要があります。
[送信] をクリックします。
後でデータプリザーバーを削除する場合は、次のデータプリザーバーレコードを変更または削除しないようにしてください。
- コアインスタンスのプロパティ
- セマフォ
- メールアカウント
注:
DB ビューは保持できません。
プリザーバーを空にすることはできません。プリザーバーが空の場合、ユーザーはクローンを送信できません。

SAML プロパティの保持

クローンターゲットインスタンスで既存の SAML 統合を維持する場合は、[コアインスタンスのプロパティ] データプリザーバーを編集して SAML プロパティを含める必要があります。

始める前に

必要なロール：admin

手順

次のように移動する。 All (すべて) > システムクローン > データを保存.
[コアインスタンスのプロパティ] を選択します。
次の [条件] を追加します。
- [または] [名前] [は次のいずれか] [glide.authenticate.external、glide.authenticate.external.logout_redirect、glide.authenticate.failed_requirement_redirect]
- [または] [名前] [は次の値で始まる] [glide.authenticate.sso.saml2]
- [または] [名前] [次で始まる] [com.snc.integration.saml_esig]
注:
インスタンステーマを保持するかどうかに関係なく、これらのプロパティが保持されるように、[テーマ] チェックボックスがオフになっていることを確認します。
[更新] をクリックします。

システムクローン中の開発におけるアプリケーションとカスタマイズの保持

アプリケーションバージョンをターゲット (開発) インスタンスにクローンする前に、現在開発中の各アプリケーションとカスタマイズ内容のコピーを手動で保持します。

始める前に

アプリケーションレコードに対する書き込みアクセス権があることを確認します。

ソースコントロールリポジトリへのアクセス権があることを確認します。

必要なロール：admin

このタスクについて

クローンプロセスでは、開発中のアプリケーションとアプリのカスタマイズのバージョンの差異は保存されません。代わりに、システムでは、ソースインスタンスにインストールされているアプリケーションとアプリのカスタマイズのバージョンのコピーのみを、ターゲットインスタンスにクローンします。ターゲットインスタンスに同じアプリケーションの開発バージョンがある場合、そのアプリケーションはクローン作成後に編集可能になりますが、そのバージョンはソースインスタンスにインストールされているものと同じになります。アプリケーションがソースインスタンスから失われていた場合は、クローン作成プロセスによりターゲットインスタンスからアプリケーションが削除されます。

手順

次のいずれかのアクションを行い、クローンターゲットインスタンスでアプリケーションを保持します。

表 : 1. インスタンス間のバージョンの差異
アプリケーションバージョンの状態	実行するアクション
クローンターゲットインスタンスのアプリケーションバージョンが、ソースインスタンスバージョンと異なります。	クローンターゲットインスタンスから各アプリケーションをエクスポートします。次の選択肢があります。各アプリケーションをソースコントロールリポジトリにリンクします。注: アプリケーションが既にソースコントロールリポジトリにリンクされている場合は、最新のバージョンをコミットします。各アプリケーションを更新セットに公開します。
アプリケーションは、クローンターゲットインスタンスでのみ利用できます。
クローンターゲットインスタンスのアプリケーションバージョンは、ソースインスタンスと同じです。	なし。システムクローン作成プロセスにより、クローン作成中にこのアプリケーションバージョンがターゲットインスタンスにコピーされます。

ターゲットインスタンスに対するソースインスタンスのシステムクローンを要求します。
たとえば、開発インスタンスに対して本番インスタンスのクローンを作成します。
クローン作成プロセスが終了したら、クローンターゲットインスタンスにログインします。

注:

ソースコントロールがリンクされている場合、クローン後に、プラットフォームはアプリケーションとカスタマイズされたアプリケーションを自動的に取得します。これが glide.source_control.post_clone_import_enabled で無効になっている場合は、次の手順を使用して手動で取得する必要があります。

各アプリケーションをソースコントロールリポジトリに保存した場合は、次のいずれかのアクションを使用してソースコントロールリポジトリからアプリケーションを取得します。

注:

アプリケーションのカスタマイズのクローンの後に起こることについては、「アプリケーションのカスタマイズのクローン後の結果」を参照してください。

表 : 2. ソースコントロールリポジトリからのアプリケーションの取得
アプリケーションのインストール状態	クローンターゲットで実行するアクション
アプリケーションとカスタマイズ内容は以前にソースインスタンスにインストールされていました。	ソースコントロールリポジトリからリモート変更を適用します。
アプリケーションはソースインスタンスにインストールされていませんでした。	リポジトリ構成 (sys_repo_config) を削除し、ソースコントロールリポジトリからカスタマイズをインポートします。

表 : 3. クローン後のリモート変更
フィールド	説明
glide.source_control.post_clone_import_enabled	リモート変更の適用の自動化を無効にするには、False に設定します。デフォルト値は True です。
glide.source_control.post_clone_import_delay_time_sec	キューの処理を遅延させる遅延時間を指定するには、値を指定します。デフォルト値は 0 です。
glide.source_control.post_clone_import_pause_refresh_time_sec	リポジトリのリフレッシュジョブを実行しない間隔を指定するには、値を指定します。デフォルトは 3 時間 (10800) です。

各アプリケーションを更新セットに保存した場合は、次のいずれかのアクションを行って更新セットからアプリケーションを取得します。

表 : 4. 更新セットからのアプリケーションの取得
アプリケーションのインストール状態	クローンターゲットで実行するアクション
アプリケーションは以前にソースインスタンスにインストールされていました。	ソースインスタンスからクローンされたアプリケーションバージョンを削除します。現在のアプリケーションバージョンを含む更新セットをロードします。
アプリケーションはソースインスタンスにインストールされていませんでした。	現在のアプリケーションバージョンを含む更新セットをロードします。

タスクの結果

以前に開発していたアプリケーションを利用して、クローンターゲットインスタンスでさらに開発を進めることができます。

Marketing Events アプリケーションの保存

あなたの会社が、以前に Marketing Events という名前のカスタムアプリケーションのバージョン 1.0 を作成していたとします。Marketing Events アプリケーションのバージョン 1.0 をアプリケーションリポジトリに既に公開していて、本番インスタンスにインストールしています。

時間の経過とともに、ユーザーからアプリケーションの拡張の要求が提出され、この要求に対処するために、非本番インスタンスで Marketing Events アプリケーションのバージョン 2.0 を開発することに決めました。開発が完了に近づくと、包括的なテストのために、非本番インスタンスを最新の本番環境のコピーに更新する必要が生じました。

以前にソースコントロール統合を使用して Marketing Events アプリケーションのバージョン 1.0 を開発していたため、既に Marketing Events アプリケーションをソースコントロールリポジトリにリンクしています。Marketing Events アプリケーションのバージョン 2.0 をソースコントロールリポジトリにコミットします。

開発インスタンスに対する本番インスタンスのクローン作成をスケジュール設定します。完了したら、開発インスタンスにログインし、Marketing Events アプリケーションのバージョン 1.0 があることを確認します。このバージョンが、ソースインスタンスにインストールされたバージョンのためです。

アプリケーションが既にソースインスタンスにインストールされているため、ソースコントロールリポジトリからリモート変更を適用して、最新のアプリケーションバージョンを受信します。開発インスタンスに、今後の開発とテストに利用できる Marketing Events アプリケーションのバージョン 2.0 が追加されました。