すべてのプロダクト
Search
ドキュメントセンター

Data Transmission Service:PolarDB for MySQL クラスターから ApsaraDB for ClickHouse クラスターへのデータ移行

最終更新日:Nov 21, 2025

Data Transmission Service (DTS) は、PolarDB for MySQL クラスターから ApsaraDB for ClickHouse クラスターへのデータ移行をサポートしています。これにより、ビジネスデータをストリーミングして一元的に分析できます。

前提条件

バージョン 20.8 以降を実行する宛先 ApsaraDB for ClickHouse クラスターを作成する必要があります。詳細については、「クラスターの作成」をご参照ください。

説明

ApsaraDB for ClickHouse クラスターのストレージ容量は、ソース PolarDB for MySQL クラスターの使用済みストレージ容量よりも大きい必要があります。

使用上の注意

タイプ

説明

ソースデータベースの制限

  • ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。

  • テーブルレベルでデータを移行し、オブジェクト名マッピングなどの編集操作を実行する必要がある場合、単一のデータ移行タスクで移行できるテーブルは最大 1,000 個です。テーブル数がこの制限を超えると、タスクの送信後にリクエストエラーが報告されます。この場合、移行するテーブルを分割し、複数のタスクを構成してバッチで移行します。または、データベース全体を移行するタスクを構成します。

  • 増分移行を実行する場合:

    • バイナリログを有効にし、loose_polar_log_bin パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログの有効化」および「パラメーターの変更」をご参照ください。

      説明

      PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ容量が消費され、ストレージ料金が発生します。

    • PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持期間を推奨します。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。DTS の要件よりも短いバイナリログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

      説明

      PolarDB for MySQL クラスターのバイナリログの保持期間の設定方法の詳細については、「保持期間の変更」をご参照ください。

その他の制限

  • ソース PolarDB for MySQL インスタンスの読み取り専用ノードからデータを移行することはできません。

  • DTS は、ソース PolarDB for MySQL インスタンスからの OSS 外部テーブルの移行をサポートしていません。

  • INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、および FOREIGN KEY (FK) オブジェクトの移行はサポートされていません。

  • DTS は、完全データ移行中のデータベースインスタンスのプライマリ/スタンバイのスイッチオーバーシナリオをサポートしていません。このようなシナリオでは、移行タスクを速やかに再構成してください。

  • 複数のテーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、宛先データベースでデータ損失が発生したり、移行インスタンスが失敗したりする可能性があります。

  • DMS または gh-ost ツールを使用してソースでオンライン DDL 変更を実行すると、DTS は元の DDL 文のみを宛先に移行します。このシナリオでは、DTS は大量の一時テーブルデータを移行する必要はありませんが、宛先でテーブルがロックされる可能性があります。

    説明

    ソースで pt-online-schema-change などのツールを使用して実行されたオンライン DDL 変更の移行はサポートされていません。ソースにこのような変更が存在する場合、宛先でデータ損失が発生したり、移行インスタンスが失敗したりする可能性があります。

  • ソース PolarDB for MySQL クラスターの DDL 文が標準の MySQL 構文に従っていない場合、移行タスクが失敗したり、データが失われたりする可能性があります。

  • RENAME TABLE 操作は移行できません。

  • ApsaraDB for ClickHouse の時間タイプのデータには特定の範囲があります。PolarDB for MySQL の時間データがこの範囲外の場合、ApsaraDB for ClickHouse に移行された時間は正しくありません。範囲の詳細については、「時間情報」をご参照ください。

  • パーティションキー には Nullable フィールドを選択できません。そうしないと、移行タスクは失敗します。

    説明

    パーティションキーは、BIGINT、INT、TIMESTAMP、DATETIME、および DATE 型のフィールドのみをサポートします。

  • 移行するデータベースの数は、ApsaraDB for ClickHouse の制限である 256 を超えてはなりません。

  • 移行するデータベース、テーブル、および列の名前は、ApsaraDB for ClickHouse の命名規則に準拠する必要があります。規則の詳細については、「オブジェクトの命名規則」をご参照ください。

  • スキーマ移行中、DTS は宛先テーブルに _sign_is_deleted、および _version フィールドを追加します。移行タイプ を構成するときに スキーマ移行 を選択しない場合は、宛先でデータを受信するためのテーブルを手動で作成し、追加のフィールドをテーブルに追加する必要があります。テーブルの作成要件とフィールド情報の詳細については、「テーブルとフィールド」をご参照ください。

  • データを移行する前に、ソースデータベースと宛先データベースのパフォーマンスを評価してください。オフピーク時にデータを移行することをお勧めします。そうしないと、初期完全同期によってソースデータベースと宛先データベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。

  • データベース全体ではなく 1 つ以上のテーブルを移行する場合、pt-online-schema-change などのツールを使用してソースデータベースの移行オブジェクトに対してオンライン DDL 変更を実行しないでください。そうしないと、移行は失敗します。

    Data Management (DMS) を使用してオンライン DDL 変更を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。

  • DTS 移行中は、DTS 以外のソースから宛先データベースにデータを書き込まないでください。そうしないと、ソースデータベースと宛先データベースの間でデータに不整合が生じます。

  • インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスを回復しようとします。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。

    説明

    パラメーターが調整されると、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。

課金

移行タイプ

リンク設定料金

データ転送料金

スキーマ移行と完全データ移行

無料です。

この例は無料です。

増分データ移行

有料です。詳細については、「課金の概要」をご参照ください。

増分移行可能な SQL 操作

操作タイプ

SQL 操作文

DML

INSERT, UPDATE, DELETE

DDL

  • CREATE TABLE, TRUNCATE TABLE, DROP TABLE

  • ADD COLUMN, MODIFY COLUMN, DROP COLUMN

データ型のマッピング

PolarDB for MySQL と ApsaraDB for ClickHouse は異なるデータ型をサポートしているため、1 対 1 のマッピングは不可能です。初期スキーマ同期中、DTS は宛先データベースでサポートされている型に基づいてデータ型をマッピングします。詳細については、「異種データベース間のデータ型マッピング」をご参照ください。

データベースアカウントに必要な権限

データベース

必要な権限

権限の作成と付与の方法

ソース PolarDB for MySQL クラスター

移行オブジェクトに対する読み取り権限。

データベースアカウントの作成と管理およびデータベースアカウントのパスワードの管理

宛先 ApsaraDB for ClickHouse クラスター

  • バージョン 22.8 以降では、宛先データベースに対する読み取りおよび書き込み権限が必要です。特権アカウントはこれらの要件を満たします。

  • バージョン 21.8: [読み取り、書き込み、権限の設定] および [DDL の有効化]

Community-compatible Edition クラスターのアカウント管理

手順

  1. 次のいずれかの方法でデータ移行ページに移動し、データ移行インスタンスが存在するリージョンを選択します。

    DTS コンソール

    1. DTS コンソールにログインします。

    2. 左側のナビゲーションウィンドウで、データの移行 をクリックします。

    3. ページの左上隅で、データ移行インスタンスが存在するリージョンを選択します。

    DMS コンソール

    説明

    実際の操作は、DMS コンソールのモードとレイアウトによって異なる場合があります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルのカスタマイズ」をご参照ください。

    1. DMS コンソールにログインします。

    2. 上部のナビゲーションバーで、ポインターを [データ + AI] > [DTS (DTS)] > [データ移行] の上に移動します。

    3. [データ移行タスク] の右側にあるドロップダウンリストから、データ同期インスタンスが存在するリージョンを選択します。

  2. タスクの作成 をクリックして、タスク構成ページに移動します。

  3. ソースデータベースと宛先データベースを構成します。次の表にパラメーターを示します。

    カテゴリ

    構成

    説明

    なし

    タスク名

    DTS タスクの名前。DTS は自動的にタスク名を生成します。タスクを簡単に識別できるわかりやすい名前を指定することをお勧めします。一意のタスク名を指定する必要はありません。

    移行元データベース

    既存の接続情報の選択

    • DTS に登録されているデータベースインスタンスを使用する場合は、ドロップダウンリストからインスタンスを選択します。DTS は、インスタンスの次のデータベースパラメーターを自動的に入力します。詳細については、「データベース接続の管理」をご参照ください。

      説明

      DMS コンソールでは、[DMS データベースインスタンスの選択] ドロップダウンリストからデータベースインスタンスを選択できます。

    • DTS へのインスタンスの登録に失敗した場合、または DTS に登録されているインスタンスを使用する必要がない場合は、次のデータベース情報を構成する必要があります。

    データベースタイプ

    PolarDB for MySQL を選択します。

    アクセス方法

    Alibaba Cloud インスタンス を選択します。

    インスタンスのリージョン

    ソース PolarDB for MySQL クラスターが存在するリージョンを選択します。

    Alibaba Cloud アカウント間でデータを複製

    この例では、同じ Alibaba Cloud アカウント内での移行を示します。× を選択します。

    PolarDB クラスター ID

    ソース PolarDB for MySQL クラスターの ID を選択します。

    データベースアカウント

    ソース PolarDB for MySQL クラスターのデータベースアカウントを入力します。必要な権限の詳細については、「データベースアカウントに必要な権限」をご参照ください。

    データベースのパスワード

    データベースへのアクセスに使用されるパスワード。

    暗号化

    必要に応じてメソッドを選択します。Secure Sockets Layer (SSL) 暗号化機能の詳細については、「SSL 暗号化の設定」をご参照ください。

    移行先データベース

    既存の接続情報の選択

    • DTS に登録されているデータベースインスタンスを使用する場合は、ドロップダウンリストからインスタンスを選択します。DTS は、インスタンスの次のデータベースパラメーターを自動的に入力します。詳細については、「データベース接続の管理」をご参照ください。

      説明

      DMS コンソールでは、[DMS データベースインスタンスの選択] ドロップダウンリストからデータベースインスタンスを選択できます。

    • DTS へのインスタンスの登録に失敗した場合、または DTS に登録されているインスタンスを使用する必要がない場合は、次のデータベース情報を構成する必要があります。

    データベースタイプ

    ClickHouse を選択します。

    アクセス方法

    Alibaba Cloud インスタンス を選択します。

    インスタンスのリージョン

    宛先 ApsaraDB for ClickHouse クラスターが存在するリージョンを選択します。

    Alibaba Cloud アカウント間でデータを複製

    この例では、同じ Alibaba Cloud アカウント内での移行を示します。× を選択します。

    クラスタータイプ

    必要に応じて ApsaraDB for ClickHouse クラスターのタイプを選択します。

    クラスター ID

    宛先 ApsaraDB for ClickHouse クラスターの ID を選択します。

    データベースアカウント

    宛先 ApsaraDB for ClickHouse クラスターのデータベースアカウントを入力します。必要な権限の詳細については、「データベースアカウントに必要な権限」をご参照ください。

    データベースのパスワード

    データベースへのアクセスに使用されるパスワード。

  4. ページの下部で、[接続性のテストと続行] をクリックします。

    説明

    DTS サーバーの CIDR ブロックが、DTS サーバーからのアクセスを許可するために、ソースデータベースと宛先データベースのセキュリティ設定に自動または手動で追加できることを確認してください。詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。

  5. 移行するオブジェクトを構成します。

    1. オブジェクト設定 ページで、移行するオブジェクトを構成します。

      構成

      説明

      移行タイプ

      • 完全データ移行のみを実行するには、[スキーマ移行][完全データ移行] を選択します。

      • データ移行中のサービス継続性を確保するには、[スキーマ移行][完全データ移行]、および [増分データ移行] を選択します。

      説明
      • [スキーマ移行] を選択しない場合は、宛先データベースにデータを受信するためのデータベースとテーブルが作成され、[選択したオブジェクト] でオブジェクト名マッピング機能が有効になっていることを確認してください。

      • [増分データ移行] を選択しない場合は、データ移行中にソースデータベースにデータを書き込まないことをお勧めします。これにより、ソースデータベースと宛先データベース間のデータ整合性が確保されます。

      競合するテーブルの処理モード

      • エラーの事前チェックと報告: 宛先データベースにソースデータベースのテーブルと同じ名前のテーブルが含まれているかどうかをチェックします。ソースデータベースと宛先データベースに同じテーブル名のテーブルが含まれていない場合、事前チェックは合格します。それ以外の場合、事前チェック中にエラーが返され、データ移行タスクを開始できません。

        説明

        ソースデータベースと宛先データベースに同じ名前のテーブルが含まれており、宛先データベースのテーブルを削除または名前変更できない場合は、オブジェクト名マッピング機能を使用して、宛先データベースに移行されるテーブルの名前を変更できます。詳細については、「オブジェクト名のマッピング」をご参照ください。

      • エラーを無視して続行: ソースデータベースと宛先データベースの同じテーブル名の事前チェックをスキップします。

        警告

        エラーを無視して続行 を選択すると、データの不整合が発生し、ビジネスが次の潜在的なリスクにさらされる可能性があります。

        • ソースデータベースと宛先データベースのスキーマが同じで、データレコードのプライマリキーが宛先データベースの既存のデータレコードと同じ場合、次のシナリオが発生する可能性があります。

          • 完全データ移行中、DTS はデータレコードを宛先データベースに移行しません。宛先データベースの既存のデータレコードは保持されます。

          • 増分データ移行中、DTS はデータレコードを宛先データベースに移行します。宛先データベースの既存のデータレコードは上書きされます。

        • ソースデータベースと宛先データベースのスキーマが異なる場合、特定の列のみが移行されるか、データ移行タスクが失敗します。注意して進めてください。

      移行先インスタンスでのオブジェクト名の大文字化

      宛先インスタンスのデータベース名、テーブル名、および列名の大文字/小文字。デフォルトでは、[DTS のデフォルトポリシー] が選択されています。他のオプションを選択して、オブジェクト名の大文字/小文字がソースデータベースまたは宛先データベースのそれと一致するようにすることができます。詳細については、「宛先インスタンスのオブジェクト名の大文字/小文字を指定する」をご参照ください。

      ソースオブジェクト

      ソースオブジェクト セクションから 1 つ以上のオブジェクトを選択します。向右小箭头 アイコンをクリックして、オブジェクトを 選択中のオブジェクト セクションに追加します。

      説明

      データベースまたはテーブルレベルで移行するオブジェクトを選択できます。

      選択中のオブジェクト

      • 宛先インスタンスに移行するオブジェクトの名前を変更するには、[選択したオブジェクト] セクションでオブジェクトを右クリックします。詳細については、「単一オブジェクトの名前のマッピング」をご参照ください。

      • 一度に複数のオブジェクトの名前を変更するには、[選択したオブジェクト] セクションの右上隅にある [一括編集] をクリックします。詳細については、「一度に複数のオブジェクト名をマッピングする」をご参照ください。

      説明
      • データのフィルター条件を設定するには、選択中のオブジェクト ボックスで移行するテーブルを右クリックし、開いたダイアログボックスで条件を設定します。詳細については、「フィルター条件の設定」をご参照ください。

      • オブジェクト名マッピング機能を使用する場合、名前が変更されたオブジェクトに依存する他のオブジェクトは移行に失敗する可能性があります。

    2. 詳細設定へ をクリックして詳細設定を構成します。

      構成

      説明

      タスクのスケジュールに使用する専用クラスターの選択

      デフォルトでは、専用クラスターを指定しない場合、DTS はデータ移行タスクを共有クラスターにスケジュールします。データ移行タスクの安定性を向上させたい場合は、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。

      ターゲットデータベースのタイムゾーン

      ApsaraDB for ClickHouse クラスターに書き込まれる DateTime データのタイムゾーンを選択できます。

      失敗した接続の再試行時間

      失敗した接続のリトライ時間範囲。データ移行タスクの開始後にソースまたは宛先データベースへの接続に失敗した場合、DTS はリトライ時間範囲内で直ちに接続をリトライします。有効値: 10~1,440。単位: 分。デフォルト値: 720。パラメーターを 30 より大きい値に設定することをお勧めします。指定されたリトライ時間範囲内に DTS がソースおよび宛先データベースに再接続されると、DTS はデータ移行タスクを再開します。それ以外の場合、データ移行タスクは失敗します。

      説明
      • 同じソースまたは宛先データベースを共有する複数のデータ移行タスクに異なるリトライ時間範囲を指定した場合、後で指定された値が優先されます。

      • DTS が接続をリトライすると、DTS インスタンスに対して課金されます。ビジネス要件に基づいてリトライ時間範囲を指定することをお勧めします。また、ソースデータベースと宛先インスタンスがリリースされた後、できるだけ早く DTS インスタンスをリリースすることもできます。

      移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。

      その他の問題のリトライ時間範囲。たとえば、データ移行タスクの開始後に DDL または DML 操作の実行に失敗した場合、DTS はリトライ時間範囲内で直ちに操作をリトライします。有効値: 1~1440。単位: 分。デフォルト値: 10。パラメーターを 10 より大きい値に設定することをお勧めします。指定されたリトライ時間範囲内に失敗した操作が正常に実行されると、DTS はデータ移行タスクを再開します。それ以外の場合、データ移行タスクは失敗します。

      重要

      移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。 パラメーターの値は、失敗した接続の再試行時間 パラメーターの値より小さくする必要があります。

      完全移行率を制限するかどうか

      完全データ移行のスロットリングを有効にするかどうかを指定します。完全データ移行中、DTS はソースデータベースと宛先データベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。ビジネス要件に基づいて、完全データ移行のスロットリングを有効にできます。スロットリングを構成するには、1 秒あたりのソースデータベースのクエリ率 QPS1 秒あたりの完全移行の行数 RPS、および 1 秒あたりの完全移行データ量 (MB) BPS パラメーターを構成する必要があります。これにより、宛先データベースサーバーの負荷が軽減されます。

      説明

      このパラメーターは、移行タイプ パラメーターに 完全データ移行 を選択した場合にのみ構成できます。

      増分移行率を制限するかどうか

      増分データ移行のスロットリングを有効にするかどうかを指定します。スロットリングを構成するには、1 秒あたりの増分移行の行数 RPS および 1 秒あたりの増分移行データ量 (MB) BPS パラメーターを構成する必要があります。これにより、宛先データベースサーバーの負荷が軽減されます。

      説明

      このパラメーターは、移行タイプ パラメーターに 増分データ移行 を選択した場合にのみ構成できます。

      順方向および逆方向タスクのハートビートテーブル SQL を削除

      DTS インスタンスの実行中にハートビートテーブルに対する SQL 操作をソースデータベースに書き込むかどうかを指定します。有効な値:

      • [はい]: ハートビートテーブルに対する SQL 操作を書き込みません。この場合、DTS インスタンスの遅延が表示されることがあります。

      • [いいえ]: ハートビートテーブルに対する SQL 操作を書き込みます。この場合、ソースデータベースの物理バックアップやクローン作成などの機能が影響を受ける可能性があります。

      環境タグ

      必要に応じてインスタンスを識別するための環境タグを選択できます。この例では選択は不要です。

      ETL の設定

      抽出・変換・書き出し (ETL) 機能を有効にするかどうかを指定します。詳細については、「ETL とは」をご参照ください。有効な値:

      監視アラート

      データ移行タスクのアラートを構成するかどうかを指定します。タスクが失敗した場合、または移行遅延が指定されたしきい値を超えた場合、アラート連絡先は通知を受け取ります。有効な値:

      • [いいえ]: アラートを構成しません。

      • [はい]: アラートを構成します。この場合、アラートのしきい値とアラート通知設定も構成する必要があります。詳細については、「モニタリングとアラートの構成」トピックの「DTS タスク作成時のモニタリングとアラートの構成」セクションをご参照ください。

    3. 次:データベースおよびテーブルのフィールド設定 をクリックして、ClickHouse の宛先テーブルの タイププライマリキー列の追加ソートキー配布キー、および パーティションキー を構成します。

      • DTS はデフォルトの構成を提供します。この構成を変更するには、定義ステータスすべて に設定できます。

      • プライマリキー列の追加ソートキー は複合キーにすることができます。プライマリキー列の追加 または ソートキー の対応するドロップダウンリストから複数のフィールドを選択できます。パーティションキー として機能させるには、プライマリキー列の追加 から 1 つ以上の列を選択する必要があります。配布キー には 1 つのフィールドしか選択できません。プライマリキー、ソートキー、およびパーティションキーの詳細については、「CREATE TABLE」をご参照ください。

        説明
        • パーティションキー は未構成のままにできますが、移行タスクが失敗する原因となるため、Nullable フィールドを選択することはできません。

        • パーティションキーは、BIGINT、INT、TIMESTAMP、DATETIME、および DATE データ型のみをサポートします。それらの計算ロジックの詳細については、「パーティションキーの計算ロジック」をご参照ください。

  6. タスク設定を保存し、事前チェックを実行します。

    • DTS タスクを構成するために、関連する API 操作を呼び出すときに指定するパラメーターを表示するには、ポインターを 次:タスク設定の保存と事前チェック の上に移動し、OpenAPI パラメーターのプレビュー をクリックします。

    • パラメーターを表示する必要がない場合、または表示した場合は、ページの下部にある 次:タスク設定の保存と事前チェック をクリックします。

    説明
    • データ移行タスクを開始する前に、DTS は事前チェックを実行します。データ移行タスクは、タスクが事前チェックに合格した後にのみ開始できます。

    • タスクが事前チェックに合格しなかった場合は、各失敗項目の横にある [詳細の表示] をクリックします。チェック結果に基づいて原因を分析した後、問題をトラブルシューティングします。その後、再度事前チェックを実行します。

    • 事前チェック中に項目のアラートがトリガーされた場合:

      • アラート項目を無視できない場合は、失敗した項目の横にある [詳細の表示] をクリックして問題をトラブルシューティングします。その後、再度事前チェックを実行します。

      • アラート項目を無視できる場合は、[アラート詳細の確認] をクリックします。[詳細の表示] ダイアログボックスで、[無視] をクリックします。表示されるメッセージで、[OK] をクリックします。その後、[再度事前チェック] をクリックして再度事前チェックを実行します。アラート項目を無視すると、データの不整合が発生し、ビジネスが潜在的なリスクにさらされる可能性があります。

  7. インスタンスを購入します。

    1. [成功率][100%] になるまで待ちます。その後、[次へ: インスタンスの購入] をクリックします。

    2. [インスタンスの購入] ページで、データ移行インスタンスの [インスタンスクラス] パラメーターを構成します。次の表にパラメーターを示します。

      セクション

      パラメーター

      説明

      新しいインスタンスクラス

      [リソースグループ]

      データ移行インスタンスが属するリソースグループ。デフォルト値: [デフォルトリソースグループ]。詳細については、「Resource Management とは」をご参照ください。

      インスタンスクラス

      DTS は、移行速度が異なるインスタンスクラスを提供します。ビジネスシナリオに基づいてインスタンスクラスを選択できます。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

    3. チェックボックスをオンにして、[Data Transmission Service (従量課金) サービス規約] を読んで同意します。

    4. [購入して開始] をクリックします。表示されるメッセージで、[OK] をクリックします。

      [データ移行] ページでタスクの進行状況を表示できます。

      説明
      • データ移行タスクを使用して増分データを移行できない場合、タスクは自動的に停止します。[ステータス] セクションに [完了] が表示されます。

      • データ移行タスクを使用して増分データを移行できる場合、タスクは自動的に停止しません。増分データ移行タスクは停止も完了もしません。[ステータス] セクションに [実行中] が表示されます。

付録

時間情報

データの型

最小値

最大値

Date

1970-01-01 00:00:00

2149-06-06 00:00:00

Date32

1925-01-01 00:00:00

2283-11-11 00:00:00

DateTime

1970-01-01 08:00:00

2106-02-07 14:28:15

DateTime64

1925-01-01 08:00:00

2283-11-12 07:59:59

テーブルとフィールド

テーブル情報

オブジェクト名マッピング機能を使用しない場合、作成するテーブルは次の要件を満たす必要があります。

重要

宛先テーブルに ENGINE が含まれている場合、それは ENGINE = ReplicatedReplacingMergeTree(_version, _is_deleted) である必要があります。そうでない場合、データの不整合が発生する可能性があります。

  • ClickHouse Community Edition インスタンス: 1 つのローカルテーブルと 1 つの分散テーブルを作成する必要があります。分散テーブルの名前はソーステーブル名と同じでなければなりません。ローカルテーブルの名前は <distributed_table_name>_local でなければなりません。

  • ClickHouse Enterprise Edition インスタンス: ソーステーブルと同じ名前のテーブルを作成する必要があります。

フィールド情報

説明

ClickHouse インスタンスでは、select * from table_name final where _sign>0; 文を実行してデータをクエリできます。where 条件は削除されたデータをフィルタリングし、テーブル名の後の final キーワードは同じソートキーを持つデータをフィルタリングします。

バージョン

名前

データの型

デフォルト値

説明

Community Edition 23.8 より前

_sign

Int8

1

DML 操作のタイプ。

  • INSERT: レコードは 1 です。

  • UPDATE: レコードは 1 です。

  • DELETE: レコードは -1 です。

_version

UInt64

1

データが ClickHouse に書き込まれたときのタイムスタンプ。

Enterprise Edition および Community Edition 23.8 以降

_sign

Int8

1

DML 操作のタイプ。

  • INSERT: レコードは 1 です。

  • UPDATE: レコードは 1 です。

  • DELETE: レコードは -1 です。

_is_deleted

UInt8

0

レコードが削除されたかどうかを示します:

  • Insert: レコードは 0 です。

  • Delete: レコードは 1 です。

  • Update: レコードは 0 です。

_version

UInt64

1

データが ClickHouse に書き込まれたときのタイムスタンプ。

パーティションキーの計算ロジック

ソースフィールドタイプ

パーティションキーの計算ロジック

BIGINT

intDiv(" + tablePartKey + ", 18014398509481984)

INT

intDiv(" + tablePartKey + ", 4194304)

TIMESTAMP

toYYYYMM(" + tablePartKey + ")

DATETIME

DATE