本記事では、obcdcのよくある質問と注意事項について説明します。
起動タイムスタンプが小さすぎるかどうかを判断する方法
obcdcはログのプルバック開始時刻を設定できます。obcdcは、コミット時刻がこの時刻よりも後のログを取得します。この時刻を「起動タイムスタンプ」と呼びます。
注意事項
- obcdcはクラスタレベル(マルチテナント)の同期をサポートしています。クラスタ全体を同期する場合は、可能な限りすべてのマシンの時刻が同期されていることを保証する必要があります。そうでない場合、各テナントのGTS時刻に大きなずれが生じ、結果としてobcdcがセキュリティポイントへのロールバックやプロセスの終了を引き起こす可能性があります。 obcdc 4.xの現在のバージョンでは、obcdcが単一のテナントのみを同期する構成を推奨します。
- obcdcは現在、スタンバイテナントを持つクラスタの同期をサポートしていません。
fetching_log_mode=directかつmeta_data_refresh_mode=data_dictの場合にのみ、ログを完全にオフラインで消費できます。その他のモードの組み合わせでは、OBServerノードにリクエストを送信する必要があります。つまり、cluster_urlまたはrootserver_listを含むOBServerノードへのアクセス設定が必要です。
起動タイムスタンプの制限
obcdcが単一テナントのデータをプルバックする際、プルバック開始時刻が古すぎると、obcdcが起動できない可能性があります。具体的な制限は以下の通りです:
単一テナントの同期
fetching_log_mode=integratedの場合アーカイブが無効の場合
ユーザーが指定するobcdcの起動タイムスタンプは、少なくともテナント内のすべてのログストリームの最大
BEGIN_SCNよりも大きい必要があります。この時刻は、該当テナントで以下のSQLクエリを実行することで取得できます。SELECT CEIL(MAX(BEGIN_SCN)/1000) AS START_TS_US FROM oceanbase.GV$OB_LOG_STAT;アーカイブが有効の場合
ユーザーが指定するobcdcのプルバック開始時刻は、少なくとも以下の2つの値のうち小さい方よりも大きい必要があります。
テナント内のすべてのログストリームの最大
BEGIN_SCNテナントのアーカイブ開始時刻、すなわち
START_SCN。テナントのアーカイブ開始時刻は、該当テナントで以下のSQLクエリを実行することで取得できます。SELECT CEIL(MAX(START_SCN)/1000) as START_TS_US FROM oceanbase.DBA_OB_ARCHIVELOG;
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 ビューをクエリすることもできます。
マルチテナントの同期
クラスタ(複数テナント)データをプルバックする際、ユーザーが指定するobcdcの起動タイムスタンプは、その時点で各テナントが上記の単一テナント条件を満たしていることを保証する必要があります。
仮想生成列機能の制限事項
OceanBaseデータベースV4.x以降では、列にSTOREDと明示的にマークされていない生成列は仮想生成列として扱われ、値はclogに記録されなくなりました。
説明
obcdcはV4.2.5.0以前では仮想生成列の出力をサポートしていません。
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として出力し、不信頼列としてマークします。