Openflow Connector for MySQL について¶

テーブルの複製方法¶

テーブルは以下のステージで複製されます。

1. スキーマのイントロスペクション: コネクタは、列名やタイプを含むソーステーブルの列を検出し、Snowflakeとコネクタの 制限事項 に対してそれらを検証します。検証に失敗するとこのステージは失敗し、サイクルが完了します。このステージが正常に終了すると、コネクタは空の宛先テーブルを作成します。

2. スナップショットロード: コネクタは、ソーステーブルで利用可能なすべてのデータを宛先テーブルにコピーします。このステージが失敗した場合、それ以上のデータは複製されません。正常に完了すると、ソーステーブルのデータが宛先テーブルで利用可能になります。

3. 増分ロード: コネクタはソーステーブルの変更を追跡し、その変更を宛先テーブルに適用します。このプロセスはテーブルが複製から削除されるまで続きます。このステージで失敗すると、問題が解決するまでソーステーブルの複製が永久的に停止します。

   注釈

   このコネクタは、スナップショットのロードフェーズをバイパスして、新しく追加されたテーブルの増分変更の複製をすぐに開始するように構成できます。このオプションは、以前に複製されたデータが存在し、テーブルを再スナップショットせずに複製を続行するアカウントにコネクタを再インストールする場合に、よく役立ちます。

   スナップショットロードのバイパスと増分ロードプロセスの使用の詳細については、 増分複製 をご参照ください。

テーブル複製ステータス¶

接続エラーなどの一時的な障害は、テーブルの複製を妨げません。ただし、サポートされていないデータ型などの永続的な障害はテーブルの複製を妨げます。

複製の問題をトラブルシューティングする、または複製フローからテーブルが正常に削除されたことを確認するには、テーブル状態ストアをチェックします。

1. Openflowランタイムキャンバスで、プロセッサーグループを右クリックし、Controller Services を選択します。コントローラーサービスをリストしたテーブルが表示されます。

2. Table State Store というラベルの行を見つけて、行の右側にある More ボタンをクリックし、View State を選択します。

テーブルとその現在の状態が書かれたリストが表示されます。検索ボックスに入力して、テーブル名でリストをフィルタリングします。可能な状態は次のとおりです。

• NEW:テーブルは複製がスケジュールされていますが、複製は開始されていません。

• SNAPSHOT_REPLICATION:コネクタは既存のデータをコピーしています。このステータスは、すべての記録が宛先テーブルに保存されるまで表示されます。

• INCREMENTAL_REPLICATION:コネクタは変更をアクティブに複製しています。このステータスは、スナップショット複製の終了後に表示され、テーブルが複製から削除されるか、複製が失敗するまで無期限に表示され続けます。

• FAILED:エラーのため、複製が完全に停止しています。

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

永続的な障害によりテーブルの複製が妨げられた場合は、複製からテーブルが削除されます。失敗の原因となった問題に対処した後、複製にテーブルを追加し直すことができます。詳細については、:ref:`テーブル複製の再開 <label-of_mysql_restart_table_replication>`をご参照ください。

宛先テーブルのメタデータ列¶

各宛先テーブルには、複製情報を追跡する次のメタデータ列が含まれます。

ソフト削除された行¶

ソーステーブルから行が削除されても、コネクタはそれを宛先テーブルから物理的に削除しません。代わりに、``_SNOWFLAKE_DELETED``メタデータ列を``true``に設定することにより、行は削除済みとしてマークされます。

このアプローチにより、以下が可能になります。

• 監査またはコンプライアンスの目的で履歴データを保持する。

• 必要に応じて削除されたレコードをクエリする。

• 要件に基づいて、データを完全に削除するタイミングと方法を決定する。

アクティブな（削除されていない）行のみをクエリするには、``_SNOWFLAKE_DELETED``列でフィルターします。

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

削除された行をクエリするには、以下のようにします。

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

ドロップされた列¶

ソーステーブルから列がドロップされても、コネクタは宛先テーブルから対応する列をドロップしません。代わりに、履歴値を保持するために``__SNOWFLAKE_DELETED``サフィックスを追加して列の名前が変更されます。

たとえば、``EMAIL``という名前の列がソーステーブルからドロップされた場合、宛先テーブルでは``EMAIL__SNOWFLAKE_DELETED``に名前が変更されます。列がドロップされる前に存在していた行は元の値を保持しますが、ドロップ後に追加された行はこの列に``NULL``を持ちます。

名前が変更された列から履歴値を引き続きクエリできます。

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

列の名前の変更¶

CDC（変更データキャプチャ）メカニズムの制限により、コネクタは、列の名前変更と、列のドロップおよびその後の新しい列の追加を区別できません。その結果、ソーステーブルで列の名前を変更すると、コネクタはこれを元の列のドロップと、新しい名前の新しい列の追加という2つの別個の操作として扱います。

たとえば、ソーステーブルで列の名前を``A``から``B``に変更した場合、宛先テーブルには次が含まれます。

• A__SNOWFLAKE_DELETED:名前変更前の値が含まれます。名前変更後に追加された行は、この列が``NULL``です。

• B:名前変更後の値が含まれます。名前変更前に存在していた行は、この列が``NULL``です。

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

ジャーナルテーブル¶

増分複製において、ソースデータベースからの変更は、宛先テーブルにマージされる前に、最初にジャーナルテーブルに書き込まれます。コネクタは、ジャーナルテーブルからデータを自動的に削除しません。このデータは、監査、デバッグ、再処理の目的で役立つ場合があります。

ジャーナルテーブルは、対応する宛先テーブルと同じスキーマで作成され、次の命名規則に従います。

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

条件:

• ``<TABLE_NAME>``は宛先テーブルの名前である。

• ``<timestamp>``はUnixエポック形式（1970年1月1日からの秒数）の作成タイムスタンプであり、一意性を確保する。

• ``<number>``は1から始まり、ソーステーブルのスキーマ変更または列フィルターの変更により宛先テーブルスキーマが変更されるたびに増加します。

たとえば、宛先テーブルが``SALES.ORDERS``の場合、ジャーナルテーブルの名前は``SALES.ORDERS_JOURNAL_1705320000_1``になる可能性があります。