obcdc よくある質問

本記事では、obcdcのよくある質問と注意点について説明します。

起動タイムスタンプが小さすぎるかどうかの判断方法

obcdcはログのプルバック開始時刻を設定でき、その時刻より後にコミットされたログを取得します。この時刻を「起動タイムスタンプ」と呼びます。

注意事項

1. obcdcはクラスタレベル（マルチテナント）での同期をサポートしています。クラスタ全体を同期する場合は、可能な限りすべてのマシンの時刻が同期されていることを保証する必要があります。そうでない場合、各テナントのGTS時間に大きな差異が生じ、結果としてobcdcがセキュリティポイントへのロールバックやプロセスの終了を引き起こす可能性があります。 obcdc 4.xの現在のバージョンでは、obcdcが単一のテナントのみを同期することを推奨します。
2. obcdcは現在、スタンバイテナントを持つクラスタの同期をサポートしていません。
3. fetching_log_mode=direct かつ meta_data_refresh_mode=data_dict の場合にのみ、ログを完全にオフラインで消費できます。その他のモードの組み合わせでは、OBServerノードにリクエストを送信する必要があるため、cluster_url または rootserver_list を含むOBServerノードへのアクセス設定が必要です。

起動タイムスタンプの制限

obcdcが単一テナントのデータをプルバックする際、プルバック開始時刻が古すぎると、obcdcが起動できない場合があります。具体的な制限は以下のとおりです：

1. 単一テナントの同期

   1. fetching_log_mode=integrated の場合

      1. アーカイブが無効な場合

         ユーザーが指定するobcdcの起動タイムスタンプは、少なくともテナント内のすべてのログストリームの最大 BEGIN_SCN より大きい必要があります。この時刻は、該当テナントで以下のSQLクエリを実行することで取得できます。

         SELECT CEIL(MAX(BEGIN_SCN)/1000) AS START_TS_US FROM oceanbase.GV$OB_LOG_STAT;
         

      2. アーカイブが有効な場合

         ユーザーが指定するobcdcのプルバック開始時刻は、少なくとも以下の2つの値のうち小さい方より大きい必要があります。

         1. テナント内のすべてのログストリームの最大 BEGIN_SCN

         2. テナントのアーカイブ開始時刻、すなわち START_SCN。テナントのアーカイブ開始時刻は、該当テナントで以下のSQLクエリを実行することで取得できます。

            SELECT CEIL(MAX(START_SCN)/1000) as START_TS_US  FROM oceanbase.DBA_OB_ARCHIVELOG;
            

   2. fetching_log_mode=direct の場合、単一テナントの同期のみをサポートしており、obcdcの起動タイムスタンプがアーカイブログの開始時刻より大きいことを保証する必要があります。

      データディクショナリモードを使用する場合、起動タイムスタンプがテナントデータディクショナリ内の最小 snapshot_scn より大きいことを保証する必要があります。テナントデータディクショナリ内の最小 snapshot_scn は、該当テナントで以下のSQLクエリを実行することで取得できます。

      SELECT CEIL(MIN(snapshot_scn)/1000) FROM oceanbase.DBA_OB_DATA_DICTIONARY_IN_LOG;
      

      説明

      システムテナントで tenant_id を指定することで、oceanbase.CDB_OB_DATA_DICTIONARY_IN_LOG ビューをクエリすることもできます。

2. マルチテナントの同期

   クラスタ（複数テナント）のデータをプルバックする際、ユーザーが指定するobcdcの起動タイムスタンプは、その時刻において各テナントが上記の単一テナント条件を満たしていることを保証する必要があります。

仮想生成列機能の制限事項

OceanBaseデータベースV4.x以降では、列にSTOREDと明示的にマークされていない生成列は仮想生成列として処理され、値はclogに記録されなくなりました。

OceanBaseデータベースのバージョンが[4.2.5.0, 4.3.0.0) U [4.3.4.0, +∞) の範囲内にあり、使用するobcdcのバージョンが[4.2.5.0, 4.3.0) U [4.3.5.5, 4.4.0) U [4.4.2.0, +∞) の範囲内で、かつenable_output_virtual_generated_column=1が設定されている場合、一部のシナリオで書き込まれた仮想生成列を同期できます。ただし、すべての生成列式をサポートする保証はありません。

この機能を使用する場合は、事前に使用する仮想生成列についてテスト検証を行う必要があります。同期が必要だがサポートされていない仮想生成列に遭遇した場合は、その列をSTORED生成列に設定できます。現在、以下の場合はサポートできないことが確認されています：

• 生成列ルールにタイムゾーンが関わる場合。

• 生成列ルールにシステム関数（例：FROM_TZ、NULLIF）が関わる場合。

• 生成列でJSON関数を使用し、JSON PATIAL UPDATE機能を使用している場合。

テーブルレベル復元機能の制限事項

• OceanBaseデータベースはV4.2.1からテーブルレベル復元機能を提供していますが、基盤としてダイレクトロードの実装も利用しているため、データ同期はサポートされていません。

• OceanBaseデータベースとobcdcのバージョンがどちらも[4.2.5, 4.3.0) U [4.4.2, 4.5.0) U [4.6.0, +∞) の範囲内にある場合、obcdcはテーブルレベル復元の実行完了後のテーブルの増分データ変更を出力できますが、テーブル作成のDDLは出力しません。

ダイレクトロードの制限事項

• フルダイレクトロード：インポートデータがトランザクションパスを経由しない場合、obcdcはサポートしていません。

• 増分ダイレクトロード：obcdcはV4.2.5.0バージョンからサポートしています。

• 増分ベースラインインポート：obcdcは出力をサポートしていません。

  説明

  OceanBaseデータベースV4.5.0バージョン以降、増分インポートはデフォルトで増分ベースラインインポートモードを使用します。

信頼可能な列のマーキングロジックの説明

OceanBaseデータベースV4.xバージョンでは、clogにはDML操作を行った行のすべての列情報が必ずしも記録されるわけではありませんが、obcdcはDML操作を行った行のすべての列を出力します。OceanBaseクラスタのclogに記録されている列値について、obcdcはその列を信頼可能な列（列値の出典はRedoログ）としてマークします。OceanBaseクラスタのclogに記録されていない列については、obcdcは信頼できない列（列値の出典はobcdcが自己生成、通常はNULL）としてマークします。

obcdcの下流コンシューマーは、列値が信頼可能かどうかに応じて自身の消費ロジックを調整し、信頼できない列のデータを下流に転送してデータの正確性に問題を引き起こすことを防ぐ必要があります。

メッセージライブラリのValueOrigin.hにあるenum型VALUE_ORIGINは列値の出典を表しており、VALUE_ORIGIN::REDOは列値がRedoログから来ており、その列が信頼可能であることを示しています。VALUE_ORIGIN::PADDINGは列値がobcdc自身が生成したものであり、実際の列値を表さないことを示しています。obcdcの下流コンシューマーは、解析された各列のbinlogbuf内のm_originフィールドからその列の信頼マーカーを取得できます。

obcdcがMOWテーブルをサポートするバージョン

OceanBaseデータベースV4.3.5 BP5より前のバージョンに書き込まれたMOWテーブルデータについて、V4.3.5 BP5及びそれ以前のバージョンのobcdcを使用すると予期しない異常が発生する可能性がありますが、V4.3.5 BP6以降のバージョンのobcdcを使用すると、関連するOUTROW LOBデータは出力されません（信頼できない列としてマークされます）。

OceanBaseデータベースV4.3.5 BP5以降のバージョンに書き込まれたMOWテーブルデータについては、obcdcは正常に処理できます。

obcdcがMINIMAL MODEをサポートするバージョン

obcdcはOceanBaseデータベースV4.3.x以降のバージョンに書き込まれたminimalモードデータを同期できます。変更を伴わない列については、obcdcはその列値をNULLとして出力し、信頼できない列としてマークします。