Skip to main content

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

学習の目的

この単元を完了すると、次のことができるようになります。
  • レプリケーションで生じる可能性のある 3 種類の問題を挙げる。
  • レプリケーションの失敗をトラブルシューティングするときに実行可能な手順を 3 つ挙げる。
  • レプリケーションを元に戻すとどうなるかを説明する。
  • レプリケーションのトラブルシューティングに役立つと思われるログの種類を挙げる。
  • ハングしたレプリケーションをトラブルシューティングするときに実行可能なアプローチを 3 つ挙げる。

失敗時の操作

Linda Rosenberg は、レプリケーションについて学習して以来、Cloud Kicks のデータとコードのレプリケーション処理を多数実行しています。

自身のトラブルシューティングスキルを試されるいくつかの問題も発生しました。さまざまな理由によってレプリケーションを元に戻さなければならないこともありました。何度か失敗し、レプリケーションがハングしたこともありました。また、キャッシュのクリアでサポートが必要になったこともあります。ここでは、Linda がこうした問題をどのように解決したのかを見ていきます。

失敗時に実行する最初のステップは、レプリケーションのステータスを確認することです。

  1. Business Manager を開きます。
  2. [管理] > [レプリケーション] > [データ (またはコード) のレプリケーション] を選択します。
  3. レプリケーション処理とそのステータスのリストを表示します。

この後 Linda が何をするのか順番に見ていきましょう。

レプリケーション後の問題

データのレプリケーションで問題が生じると、Linda は Staging (ステージング) とターゲットインスタンスのレプリケーションログにエラーメッセージがないか確認します。「failed」や「ORA-」と記載されたエントリが解決の糸口になります。

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

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

データやコードが適切に転送されない場合や完了できない場合、バグが多いときは (コードの場合)、元に戻す操作を実行できます。レプリケーションを実行したりレプリケーションにアクセスするには PIG インスタンスを開いている必要があります。

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

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

  1. Business Manager を開きます。
  2. [管理] > [レプリケーション] > [データのレプリケーション] を選択します。
    処理の横にある [元に戻す] をクリックします。
  3. 処理の横にある [元に戻す] をクリックします。元に戻すことができるのはインスタンス上で最後に実行された処理のみです。
  4. ターゲットインスタンスを選択します。
  5. 説明を入力します。
  6. アクティブ化のタイプに [手動] を選択します。
  7. 通知メールのトリガーに [When Process Ends (処理終了時)] を選択します。
    複数の送信先アドレスをカンマで区切って入力します。メール通知には、処理の開始時刻と終了時刻、ターゲットシステム、レプリケーションタイプ、含まれるレプリケーションタスクが記載されます。失敗が発生した場合にはエラーコードも記載されます。定期的に実施する場合は、プロセスごとに通知が送信されます。
  8. [次へ] をクリックします。
  9. レプリケーションタイプに [元に戻す] を選択します。
  10. [次へ] をクリックして、処理の詳細を確認します。
  11. [作成] をクリックします。
  12. リストから処理を見つけて [開始] をクリックします。

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

Linda は、最後に行ったコードの転送 & アクティブ化レプリケーション処理や、コードのアクティブ化レプリケーション処理をロールバックできます。コードのレプリケーションを元に戻すと、ターゲットインスタンスはその前に有効であったコードバージョンに戻されます。元に戻すことができるのはターゲットインスタンスで最後に行った [コードのアクティブ化] 処理または [コードの転送 & アクティブ化] 処理のみです。手順は次のとおりです。
  1. Business Manager を開きます。
  2. [管理] > [レプリケーション] > [コードのレプリケーション] を選択します。
  3. 処理の横にある [元に戻す] をクリックします。
  4. ターゲットインスタンスを選択します。
  5. 説明を入力します。
  6. アクティブ化のタイプに [手動] を選択します。
  7. 通知メールのトリガーに [When Process Ends (処理終了時)] を選択します。
    複数の送信先アドレスをカンマで区切って入力します。メール通知には、処理の開始時刻と終了時刻、ターゲットシステム、レプリケーションタイプ、含まれるレプリケーションタスクが記載されます。失敗が発生した場合にはエラーコードも記載されます。定期的に実施する場合は、プロセスごとに通知が送信されます。
  8. [次へ] をクリックします。
  9. レプリケーションタイプに [元に戻す] を選択します。
  10. [次へ] をクリックして、処理の詳細を確認します。
  11. [作成] をクリックします。
  12. リストから処理を見つけて [開始] をクリックします。

レプリケーションログ

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

Linda は Staging (ステージング) インスタンスのステータスに注意を払っています。プロセスに失敗した場合は、Staging (ステージング) ログを確認します。1 つのログに数日分のイベントが記載されている場合があるため、Linda はレプリケーション処理の開始時の日付のログを探します。ログファイルには、データのレプリケーションタスクとよく似たタイムスタンプが記されています。インスタンスのタイプに関係なく、どのログファイル名にも staging が含まれます。以下に、Linda がログを確認する手順を示します。

  1. Business Manager を開きます。
  2. [Administration (管理)] > [Site Development (サイトの開発)] > [Development Setup (開発セットアップ)] の順に選択します。Business Manager のログファイルのリンク
  3. [ログファイル] リンクをクリックします。
  4. 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 は、B2C Commerce のインスタンスの状態を監視し、適切なアクションを実行できる B2C Commerce のツールです。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'.

ハングしたレプリケーションの修正

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

Staging (ステージング) の確認

Staging (ステージング) インスタンスの最新のレプリケーションログを確認します。手順は次のとおりです。

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

ターゲットの確認

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

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

両方の確認

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

  1. どちらかのログに resource busy and acquire with NOWAIT のように指定されている行がある場合は、カスタマーサポートのチケットを開き、試行したトラブルシューティングの手順を記入します。
  2. ターゲットインスタンスのレプリケーション処理が 完了 と表示されながら、Staging (ステージング) インスタンスのステータスが依然として 待機中 または 進行中 の場合は、レプリケーションの終了時に Staging (ステージング) インスタンスがダウンしていた可能性があります。Staging (ステージング) インスタンスを再起動して、ステータスをもう一度確認します。
  3. レプリケーションがハングしていると判断した場合は、Control Center を使用して Staging (ステージング) インスタンスを再起動します。ハングしているレプリケーションが停止していることを確認するために、Staging (ステージング) インスタンスのステータスが「失敗」であることを確認します。停止したら、レプリケーションを再実行します。
  4. レプリケーションがまたハングした場合は、ターゲットインスタンスとソースインスタンスを再起動して、レプリケーションを再実行します。ターゲットインスタンスを再起動すると、実行中のすべてのジョブが中断され、ストアフロントの全リクエストのエラーが返され、キャッシュがすべてクリアされます。Production (本番) インスタンスの再起動は最後の手段としてのみ行います。
  5. レプリケーションが依然としてハングしている場合は、カスタマーサポートのチケットを開き、試行したトラブルシューティングの手順を入力します。

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

ページキャッシュの問題が生じた場合、Linda は次のヒントを検討します。

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

まとめ

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

このモジュールでは、B2C Commerce のレプリケーション処理の実行方法とトラブルシューティングの方法について説明しました。では、この最後のテストを受けて、バッジを獲得してください!

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップ ログイン
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる
今はしない