この記事はインフォマティカ Advent Calendar 2024 Day 13 の記事として書かれています。
はじめに
前回 Cloud Integration Hub のトピックのレコードのメンテナンスについて という記事の最後で「またいずれ記事を分けてご紹介したいと思います」と書いてからあっという間に一年が過ぎました。
前回はサブスクリプションイベントが全て成功しているケースについて説明しました。今回は、サブスクリプションイベントがエラーになった場合の動作をご紹介します。
Cloud Integration Hub (以下 CIH) のメンテナンスのジョブの概要については、前回の記事をご参照ください。
下準備
前回使用した topic_retention_test2 を使用します。
「コンシュームされるデータの保持期間」は「1」、「コンシュームされないデータの保持期間」は「3」に設定しています。
パブリケーションの実行間隔も前回と同じく日本時間 0:00 と 12:00 に実行するようスケジュールします。サブスクリプションのスケジューリングは「パブリッシュ済みデータの準備ができている場合」を選択し、パブリケーション実行後すぐにサブスクリプションが実行されるようにします。
そして、今回はエラーが発生した場合の動作について確認するため、意図的にサブスクリプションを一回失敗させました。サブスクリプションが失敗した日時は2024/12/6 23:44:370 JST です。
削除対象の確認
ここで、2024/12/10 のクリーンアップジョブのメンテナンスレポートを確認してみます。
(2024/12/10 8:00 JST のメンテナンスレポートより)
前回、すべてのサブスクリプションが正常にコンシュームされた場合には 「メンテナンスジョブが実行された前日以前でコンシュームされた最新のパブリケーションイベントを起点に「コンシュームされるデータの保持期間」分データが保持される」ことをご紹介しました。
今回すべてのサブスクリプションが実行されています。「メンテナンスジョブが実行された前日以前でコンシュームされた最新のパブリケーションイベントを起点に「コンシュームされるデータの保持期間」分データが保持される」のであれば、2024/12/10 8:00 JST 時点では、12/9 から「コンシュームされるデータの保持期間」である 1 日を引いた 12/8 までが保持対象となり 12/7 以前のデータが削除されるように思えますが、削除対象日は 12/6 になっています。
イベントがエラーの場合の削除対象の計算
サブスクリプションがエラーとなった場合のパブリケーションのコンシュームステータスは「エラー」であり、データがコンシュームされたとみなされません。
前回「サブスクリプションイベントが存在しない場合(topic_retention_test)」の項で、「コンシュームされないデータの保持期間」を計算する時には、メンテナンスジョブが実行される日にちが基点になると記載しました。
上述の通り、失敗しているイベントはコンシュームされていないとみなされるため、この状態では「コンシュームされないデータの保持期間」の設定が有効となります(*)。
そのため、メンテナンスジョブを実行する 12/10 から「コンシュームされないデータの保持期間」で指定している 3 日の保持期間の後の日にちである 12/6 が削除対象日になります。
(*) 正確には、存在しているコンシュームされていないイベントの中で最も古い日付に「コンシュームされるデータの保持期間」を引いた日にち(a)と、メンテナンスジョブ実行日から「コンシュームされるデータの保持期間」を引いた日にちのうち、新しい方の日にち(b)が削除対象日となります。今回は (a) は 12/4、(b) は 12/6 となるため、より新しい日にちである 12/6 が削除対象日となります。
尚、エラーとなったイベントがある場合、コンシュームされていないイベントの中で最も古いイベントが削除対象の日にちの計算で考慮され、それ以降で実行されたイベントはステータスに関わず削除されません。
例えば、上記画面では、ID:3332798 のパブリケーションの子イベント ID:3334263 のサブスクリプションは成功しておりコンシュームステータスは「最終」です。しかし、その前の ID:3334254 がエラーのため、12/7 (すべてのサブスクリプションイベントがコンシュームされている場合に削除対象日となる日にち)に実行されているにも関わらず削除対象とならずにそのまま保持されます。
終わりに
この記事では、シンプルな例を元にサブスクリプションでエラーが発生した場合のメンテナンスジョブの削除対象の計算方法をご案内しました。「サブスクリプションは成功しているのに「コンシュームされるデータの保持期間」を超えてレコードがトピックテーブルに残っている」という場合には、過去のサブスクリプションのステータスを確認すると、エラーになっているイベントがあるかもしれません。
尚、上記例のように「コンシュームされるデータの保持期間」と「コンシュームされないデータの保持期間」の設定が近い場合には、サブスクリプションイベントがエラーとなった場合のトピックテーブル内のレコード数への影響は小さくなりますが、「コンシュームされないデータの保持期間」が大幅に長い場合にはエラーのイベントが影響して多くのレコードがトピック内に残る可能性が考えられます。
前回の記事の最後にも記載した通り、トピックは永続的にデータを保持する用途のデータベースではありません。トピックのデータベースの肥大化やメンテナンスジョブによるレコードの削除処理の高負荷を防ぐため、データの保持期間は適切な日数に設定してご使用ください。