レプリケーションのトラブルシューティング

学習の目的

この単元を完了すると、次のことができるようになります。

レプリケーションで生じる可能性のある 3 種類の問題を挙げる。
レプリケーションの失敗をトラブルシューティングするときに実行可能な手順を 3 つ挙げる。
レプリケーションのロールバックのしくみを説明する。
レプリケーションのトラブルシューティングに役立つと思われるログの種類を挙げる。
ハングしたレプリケーションをトラブルシューティングするときに実行可能なアプローチを 3 つ挙げる。

レプリケーションの失敗に対処する

レプリケーションは失敗することがあります。失敗した場合は、原因を特定し、対処するための計画を立てることが重要です。通常は、レプリケーションを元に戻して最初からやり直すことができます。

レプリケーションが失敗した場合、トラブルシューティングを開始するにあたってまず確認すべきは、レプリケーションのステータスです。

レプリケーションのステータスを確認する手順は次のとおりです。

Business Manager で [App Launcher (アプリケーションランチャー)] をクリックし、[Administration (管理)] | [Replication (レプリケーション)] | [Data (or Code) Replication (データ (またはコード) レプリケーション)] を選択します。
レプリケーション処理とそのステータスのリストを表示します。
失敗またはスタックしているレプリケーションが見つかった場合、次のステップはレプリケーションログを確認することです。

レプリケーションログを確認する

ステージングインスタンスとターゲットインスタンスのレプリケーションログでエラーメッセージを確認できます。「failed」や「ORA-」と記載されたエントリが解決の糸口になります。

レプリケーションログにこうした手がかりがない場合は、エラーログを確認します。
レプリケーションに複数のタスクを伴う場合は、各タスクを含めたテストや除外したテストを実行して、問題の原因となっているタスクを特定します。
複数のオブジェクトからなるレプリケーションに失敗した場合は、個別のオブジェクトをレプリケートして原因を絞り込みます。
スケジュール済みのレプリケーションが実行されなかった場合は、手動で実行してみます。

レプリケーションを元に戻す

データやコードが正しく転送されなかった場合や不完全な場合は、元に戻す操作を実行します。PIG インスタンスにログインして、レプリケーションを実行またはアクセスします。レプリケーションタイプを [Undo (元に戻す)] に設定して、別のレプリケーション処理を実行します。このロールバックにより、ターゲットインスタンスが以前の状態に復元されます。ただし、ロールバックできるのは、データまたはコードの最後のレプリケーションに限られます。

データとコードのいずれか一方をレプリケートしても、もう一方のロールバックには影響しません。たとえば、データのレプリケーションを実行してからコードのレプリケーションを実行した場合、両方のレプリケーションを元に戻すことができます。

正式リリース (GA) 前に実行されたデータのレプリケーション処理に、元に戻す操作は使用できません。たとえば、バージョン 24.7 でレプリケーション処理を実行した場合、システムがバージョン 24.8 になった後はそのレプリケーションをロールバックできません。

データのレプリケーションを元に戻す

最後に行ったデータの転送 & 公開レプリケーション処理、またはデータの公開レプリケーション処理をロールバックできます。データレプリケーション処理を元に戻すときには、説明を入力し、メール通知を設定し、ターゲットインスタンスページのキャッシュが更新されないようにすることができます。これらの手順を省きたい場合は、レプリケーション処理の横の [Undo (元に戻す)] をクリックするだけです。次の手順を実行します。

Business Manager で [App Launcher (アプリケーションランチャー)] をクリックし、[Administration (管理)] | [Replication (レプリケーション)] | [Data Replication (データレプリケーション)] を選択します。

処理の横にある [元に戻す] をクリックします。

処理の横にある [元に戻す] をクリックします。元に戻すことができるのはインスタンス上で最後に実行された処理のみです。
ターゲットインスタンスを選択します。
説明を入力します。
アクティブ化のタイプに [手動] を選択します。
Select a notification email trigger: When Process Ends.
- 複数の送信先メールアドレスをカンマで区切って入力できます。メール通知には、処理の開始時刻と終了時刻、ターゲットシステム、レプリケーションタイプ、含まれるレプリケーションタスクが記載されます。レプリケーションが失敗すると、通知にエラーコードが表示されます。定期的に実施する場合は、処理ごとに通知が送信されます。
[Next (次へ)] をクリックします。
レプリケーションタイプに [元に戻す] を選択します。
[次へ] をクリックして、処理の詳細を確認します。
[作成] をクリックします。
リストから処理を見つけて [開始] をクリックします。

コードのレプリケーションを元に戻す

最後に行ったコードの転送 & アクティブ化レプリケーション処理、またはコードのアクティブ化レプリケーション処理をロールバックできます。コードのレプリケーションを元に戻すと、ターゲットインスタンスはその前に有効であったコードバージョンに戻されます。元に戻すことができるのはターゲットインスタンスで最後に行ったコードのアクティブ化処理またはコードの転送 & アクティブ化処理のみです。次の手順を実行します。

Business Manager で [App Launcher (アプリケーションランチャー)] をクリックし、[Administration (管理)] | [Replication (レプリケーション)] | [Code Replication (コードレプリケーション)] を選択します。
処理の横にある [元に戻す] をクリックします。
ターゲットインスタンスを選択します。
説明を入力します。
アクティブ化のタイプに [手動] を選択します。
Select a notification email trigger: When Process Ends
- 複数の送信先メールアドレスをカンマで区切って入力します。メール通知には、処理の開始時刻と終了時刻、ターゲットシステム、レプリケーションタイプ、含まれるレプリケーションタスクが記載されます。レプリケーションが失敗すると、通知にエラーコードが表示されます。定期的に実施する場合は、処理ごとに通知が送信されます。
[Next (次へ)] をクリックします。
レプリケーションタイプに [元に戻す] を選択します。
[次へ] をクリックして、処理の詳細を確認します。
[作成] をクリックします。
リストから処理を見つけて [開始] をクリックします。

レプリケーションログを見つけて参照する

Salesforce B2C Commerce では、レプリケーション処理のログファイルを、ソースとターゲットの両方のシステムに記録します。これらのログは、通常のエラーログとは区別されます。レプリケーションログは、https://instance_address/on/demandware.servlet/webdav/Sites/Logs/ に、staging-blade_name-appserver-yyyymmdd.log のような名前で保存されます。

ステージングインスタンスのステータスを監視できます。処理が失敗した場合は、ステージングログを確認します。1 つのログには数日分のイベントが記載されているため、レプリケーション処理の開始時の日付のログを探します。ログファイルには、データのレプリケーションタスクとよく似たタイムスタンプが記されています。インスタンスのタイプに関係なく、どのログファイル名にも staging が含まれます。ログを確認する手順は次のとおりです。

Business Manager で [App Launcher (アプリケーションランチャー)] をクリックし、[Administration (管理)] | [Site Development (サイト開発)] | [Development Setup (開発セットアップ)] を選択します。

Business Manager のログファイルのリンク

[ログファイル] リンクをクリックします。
Staging (ステージング) のログを見つけます。

ログエントリの例: [2007-01-15 21:17:12.848 GMT] ISH-CORE-2250: New replication task "1168895828901" in domain "Sites-Site" successfully created.

ログファイルを確認するときは、一定の項目に着目します。

処理の順序が記載されているログファイルをスクロールして、エラーを見つけます。
Staging (ステージング) インスタンスの最後のステップは、ターゲットサーバーへのハンドオフです。Staging (ステージング) ログには次のような行があります。[2019-01-15 21:27:09.783 GMT] Staging pipeline in live system successfully called.
こうした成功メッセージが見当たらない場合は、次のようなエラーを探します。ISH-CORE-2491: Setting state of process with uuid='dC8KAANna1111EOTN9h9md4' from 'StartingStagingProcess' to 'ErrorAcquiringEditingLocks
この Staging (ステージング) エラーが生じた場合は、Control Center にログインし、インスタンスを停止してから再起動します。次に、同じレプリケーションを再度実行します。Control Center は、Agentforce Commerce for B2C インスタンスの状態を監視し、適切なアクションを実行できる Agentforce Commerce for B2C のツールです。Staging (ステージング) インスタンスログにエラーがなければ、ターゲットインスタンス上の Staging (ステージング) ログを確認します。https://[target_instance_name]/on/demandware.servlet/webdav/Sites/Logs
ターゲットインスタンスの Staging (ステージング) ログは次のようなメッセージで始まります。2019-01-15 20:29:30.321 GMT] Copy staging process with uuid=bcFvkiaalTMxM444667bVYFqBX[2007-01-15 20:29:32.347 GMT] Starting StagingResources-Acquire@Sites-Site
どのデータをレプリケートしたかに応じて、ログにデータベースのコピーの開始に関するエントリがあります。エラーがないか確認します。
レプリケーション後に、エラーがないかログ全体を確認します。処理が正常に終了した場合は、ログの末尾に次のメッセージが表示されます。[2019-01-15 21:31:17.434 GMT] ReplicationPublication process finished with state 'StagingProcessCompleted'.

スタックしているレプリケーションを解決する

データベーストランザクションの中には、特にカタログデータを処理する場合、完了に時間がかかるものがあります。データのレプリケーションの実行状態が予想以上に長引いている場合は、スタックしていないかどうかを確認します。スタックとは、レプリケーションがすでに実行されていない、あるいは進行が完全にまたはほぼ停止していることを意味します。レプリケーションがスタックしているかどうか、またその原因を確認して、正常に実行できるようにします。

ステージングインスタンスを調べる

ステージングインスタンスで最新のレプリケーションログを確認するには、次の手順に従います。

「Staging pipeline in live system successfully called」 (ライブシステムで Staging (ステージング) パイプラインが正常に呼び出されました。) という行があることを確認します。この行がない場合は、問題が発生しています。
状態が ErrorAcquiringEditingLocks に設定されているエントリがないか確認します。ある場合は、以前のレプリケーション処理でのリソースのロックが解除されていないために、レプリケーションがハングしている可能性があります。

ターゲットインスタンスを調べる

ターゲットインスタンスの最新のレプリケーションログを確認し、末尾までスクロールします。

ビューを数回更新して、新しいエントリが追加されるかどうか確認します。しばらくしても新しいエントリが表示されない場合は、レプリケーションがスタックしている可能性があります。
状態が ErrorAcquiringLivelocs に設定されていることを示すエントリを確認します。このエントリは、前回のレプリケーション処理から解除されていないリソースのロックがレプリケーションをブロックしていることを示しています。
最後のログエントリがデータベースのアクション (INSERT、ALTER INDEX など) である場合は、以前のログで、このアクションにどのくらいの時間がかかり、次のエントリが何であったかを確認します。
最後のログエントリの先頭が Rsync の場合は、複数の静的コンテンツファイルが変更されていることが動作の遅い原因である可能性があります。コンテンツが同じままでも、別のフォルダーに移動されたファイルが含まれています。Rsync が解消されない場合は、カスタマーサポートに連絡してステータスを確認してください。
ログに ErrorLiveStagingProcessKilled という状態が表示されている場合は、レプリケーションを遅延させる可能性がある、同時リリースまたはインスタンスの再起動が発生していないか確認します。

両方のインスタンスを比較する

時として、両方のインスタンスで作業することがあります。

どちらかのログに resource busy and acquire with NOWAIT のように指定されている行がある場合は、カスタマーサポートのチケットを開き、試行したトラブルシューティングの手順を記入します。
ターゲットインスタンスのレプリケーション処理が完了と表示されながら、ステージングインスタンスのステータスが依然として待機中または進行中の場合は、レプリケーションの終了時にステージングインスタンスがダウンしていた可能性があります。Staging (ステージング) インスタンスを再起動して、ステータスをもう一度確認します。

レプリケーションがスタックしていると判断した場合は、Control Center を使用してステージングインスタンスを再起動します。ステージングインスタンスのステータスが「Failed (失敗)」であることを確認して、ハングしたレプリケーションが停止していることを確かめます。停止したら、レプリケーションを再実行します。

レプリケーションがまたハングした場合は、ターゲットインスタンスとソースインスタンスを再起動して、レプリケーションを再実行します。ターゲットインスタンスを再起動すると、実行中のすべてのジョブが中断され、ストアフロントの全リクエストにエラーが返され、キャッシュがすべてクリアされます。Production (本番) インスタンスの再起動は最後の手段としてのみ行います。

レプリケーションが依然としてハングしている場合は、カスタマーサポートのチケットを開き、試行したトラブルシューティングの手順を入力します。

キャッシュのクリアのトラブルシューティング

ページキャッシュの問題が生じた場合は、次のヒントを参考にしてください。

システムのローカルな問題ではないことを確認するために、ブラウザーを閉じてローカルキャッシュをクリアします。その後で、Business Manager でキャッシュを手動でクリアします。
埋め込み CDN (本番と開発インスタンス) 上のキャッシュをクリアするには、[Entire Page Cache for Site (サイトのページ全体キャッシュ)] の [Invalidate (無効化)] をクリックします。静的キャッシュのクリアはスキップできます。
想定した変化が見られない場合は、特定の問題を示す可能性のあるパターンを探します。たとえば、画像が更新されないという状況はありませんか? 更新されていない場合は、画像プロバイダーに問題がある可能性があります。コンテンツアセットによって問題が生じている場合は、このアセットが導入されていることを確認します。

まとめ

この単元では、B2C Commerce のレプリケーション処理の実行とトラブルシューティングの方法を学習しました。レプリケーションを元に戻す方法、レプリケーションログを確認する方法、スタックしているレプリケーションを処理する方法、キャッシュのクリアをトラブルシューティングする方法を学びました。

このバッジでは、Agentforce Commerce for B2C のレプリケーション処理の実行とトラブルシューティングの方法について説明しました。

予想時間

トピック

ヘルプをお探しですか?