新しいバックアップベースのクローンエンジンIssue 新しいクローン作成エンジンが SN インスタンスにリリースされ、ライブデータの代わりに最新のバックアップが使用されるようになりました。これは「バックアップベースのクローンエンジン」と呼ばれ、従来のアプローチは「アプリ内クローンエンジン」と呼ばれます。 次の点に注意してください。 クローンには、ソースインスタンスから取得した最新のバックアップが使用されます。バックアップベースのクローンエンジンに障害が発生したため、以前のアプリ内クローンエンジンにフォールバックした場合を除き、ライブデータクローンは存在しません。ライブクローンはスタンバイデータベースからのみ作成されます。バックアップベースのクローンエンジンのロールバックを顧客のアプリ内クローン履歴で実行することはできません。クローン完了から 24 時間以内に ServiceNow スタッフがデータセンターのクローンレコードでのみ実行できるようになりました。クロス DC クローンはバックアップベースのクローンエンジンで機能しますが、アプリ内クローンエンジンへのフォールバックが発生すると失敗します。ステージングプロセスは、最後に作成されたバックアップに対して実行される解凍プロセスに似ています。 新しいエンジンはどのように機能するか 新しいバックアップベースのクローンエンジンでは、Gen 2 と Gen 3 がサポートされています。 バックアップベースのクローンエンジンの目標はクローン処理を高速化することですが、新機能の導入によってエンドユーザーに疑問が生じる可能性もあります。新しいプロセスは CHG レコードで確認できます。 ここでは、変更のサンプルを使用してプロセスを詳しく説明します。このサンプルでは、変更の開始予定日が 2017-11-20 23:00:00 (GMT) と計画されています。 クローン要求の CHG を最初に作成すると、次のメッセージが表示されます。 2017-11-20 09:47:52 データセンター自動化 (NOW) 元の要求：システムクローン <source.instance> から <target.instance> へ、2017-11-20 23:00:00 (GMT)。注意：これは自動化されたプロセスです。 進捗状況と自動化マイルストーンの更新情報は、ソースインスタンスのクローン履歴レコード内にあります。ご不明な点はカスタマーサポートにお問い合わせください。 クローンの準備は開始時刻の 4 時間前に開始しました。 2017-11-20 19:25:02 データセンター自動化 (NOW) クローンの進行状況：1%クローンの準備を開始しています クローンが可能であることを確認する実行前チェックが実施されると、次のメッセージが表示されます。 2017-11-20 19:33:25 データセンター自動化 (NOW) クローンの進行状況：2.3% クローンが実行前チェックに合格しました バックアップの取得が完了しました。ターゲットインスタンスはまだ影響を受けていません。バックアップの取得時間は、バックアップのサイズによって異なることにご注意ください。バックアップ日付にもラベルが付きます。 2017-11-20 19:38:20 データセンター自動化 (NOW)このクローンは、2017-11-20 02:15:34 GMT に作成されたバックアップデータを使用します ターゲットインスタンス用に新しいデータベースがプロビジョニングされ、競争が成功すると、次のメッセージが表示されます。 2017-11-20 19:52:25 データセンター自動化 (NOW)ターゲットインスタンス用の新しいデータベースのプロビジョニングに成功しました。 バックアップがターゲットデータベースに抽出されます。ターゲットインスタンスは影響を受けません。 2017-11-20 19:57:58 データセンター自動化 (NOW) クローンの進行状況：12.9% ターゲットデータベースへのデータのコピーを開始しました。 以前の復元に基づいて見積もりが提供され、次のメッセージが表示されます。注意：- これはあくまでも見積もりです。前回の復元以降にインスタンスのサイズが変更されている可能性があります。 2017-11-20 19:58:12 データセンター自動化 (NOW) 以前の復元の実行時間に基づき、プライマリ mysql インスタンス <顧客の MYSQL インスタンスの詳細情報> の復元にはおよそ 1 時間 15 分かかると予想されます バックアップがターゲットデータベースに抽出されました。 2017-11-20 21:10:50 データセンター自動化 (NOW) クローンの進行状況：33.9% ターゲットデータベースへのデータのコピーを完了しました。ターゲットデータベースにデータプリザーバーを適用しています。 新しいクローンターゲットインスタンスに切り替えます。この時点以降、ターゲットインスタンスが影響を受けます。次のメッセージが表示されます。 2017-11-20 23:07:51 データセンター自動化 (NOW) 新しいクローンターゲットインスタンスに切り替えます。スイッチオーバー中、ターゲットインスタンスは数分間オフラインになります クローン時間が到来しますが、クローン完了まで通知はありません。 2017-11-20 23:31:28 データセンター自動化 (NOW)クローンの進行状況：100% クローンは正常に完了しました。 情報レポートの変更 クローンレコードの情報のレポート方法が変更されました。[データベーステーブルクローン] タブと [保持されたデータ] タブが削除されました。現時点で、[クローンログ] タブは残っています。 アプリ内クローン作成へのフォールバック 特定の状況では、バックアップベースのクローンエンジンが使用されず、プロセスがアプリ内クローン作成に戻ることがあります。例えば、次のようになります。 復元に失敗したバックアップが使用できなかったキャパシティが見つからなかった 実行前チェック中にキャパシティの問題が発生した場合 (データベースタイプ xxlarge/xlarge/large から pico タイプへのクローンなど)、クロス DC クローンのときはアプリ内クローンエンジンへのフォールバックが許可されません。なおこれは、同じデータセンター内のペアにも適用されます。インスタンスに記録されているエラー：「このクローンキャパシティのマッピングはサポートしていません：[source]xxlarge;[target]pico」「クローンが準備完了ステータスではありませんでした。クローンを実行せずに終了しています (ステータス：エラー)」「クローンに失敗しました。」 ソースインスタンスのアップグレードと同じ日のクローン作成 ソースインスタンスのアップグレードと同じ日にクローン要求が行われた場合、バックアップベースのクローンエンジンでは、アプリ内クローンエンジンへのフォールバックを検討する必要があります。バックアップベースのクローンエンジンでは、最新のバックアップからクローンが実行されます。ソースインスタンスで glide.war への更新あったことが検出され、バックアップの glide.war がライブデータの glide.war と異なることが認識されます。バックアップとライブデータ両方の glide.war が異なるため、クローンエンジンでは 30 分のワークフローが実行されます。 30 分のワークフローではいくつかのチェックが実行され、アプリ内クローンエンジンとバックアップベースのクローンエンジンのどちらを使用するかが決定されます。チェックが完了すると、データセンターの更新時にレコードが生成されます。 データプリザーバー設定が複雑な場合にクローンが失敗することがある ドット連結や階層テーブルの保持といった複雑なデータプリザーバー設定がある場合、クローンは自動的に失敗し、開始前にキャンセルされます。これに類似した設定は珍しくないため、この点を理解しておくことは重要です。タスクまたは cmdb_ci を拡張するテーブルにデータプリザーバーが設定されている場合、クローンは失敗します。 コアインスタンスのプロパティが保持されていない場合にクローンが失敗する クローンの事前チェックでは、clone_data_preserver テーブルで、名前が Core Instance Properties かつテーブルが sys_properties であるレコードがクエリされます。レコードが見つからない場合、クローンは失敗し、「clone_data_preserver テーブルに Core Instance Properties が見つかりません」というエラーメッセージが表示されます。 Core Instance Properties には、インスタンス名、インスタンス ID など、そのインスタンスに固有であり、ターゲットインスタンスで保持する必要があるインスタンスの詳細が含まれています。 実行するアクション： clone_data_preserver テーブルリストに移動し、「Core Instance Properties」という名前のレコードを検索します。 この名前のレコードがある場合は、テーブル名が sys_properties になっていることを確認します。そうでない場合は修正してください。この名前のレコードがない場合は、[テーブル] が sys_properties のレコードを検索します。複数のレコードが存在する場合があります。「Core Instance」で始まる名前のレコードを検索してください。レコードが見つかった場合は、名前を「Core Instance Properties」に変更します。「Core Instance」で始まるレコードがない場合は、レコードが削除されている可能性があります。その場合は、以下のスナップショットを見て、clone_data_preserver テーブルに新しいエントリーを作成します。 clone_data_preserver テーブルの参照用 Core Instance Properties エントリー。 クローンの実行前チェックの失敗 クローン要求が送信されると検証が実行されます。以下のいずれかのチェックに失敗すると、要求は却下されます。 1.開発者インスタンスチェックの失敗： ソースまたはターゲットインスタンスが開発者インスタンスの場合、クローン要求は却下されます。そのような選択は現在サポートされていません。 2.キャパシティマッピングチェックの失敗： ソースインスタンスのキャパシティサイズとターゲットインスタンスのキャパシティサイズのマッピングが以下のいずれかに該当する場合、クローン要求は却下されます。このようなマッピングを使用するクローンでは、ターゲットインスタンスが使用できなくなる可能性が非常に高いためです。 ターゲットキャパシティが small 未満の場合、すべてのクローンが失敗します。 ソースキャパシティサイズ ターゲットキャパシティサイズ(small、medium、xlarge、xxlarge、xxlarge、mega、ultra、giga、tera、peta)(pico、nano、micro、exp-small)