ゼロ ETL は、データパイプラインの構築・運用を必要とせずに、ApsaraDB RDS for MySQL から ApsaraDB for ClickHouse へリアルタイムでデータをストリーミングします。この機能は Data Transmission Service (DTS) によって実現され、無料でご利用いただけます。
仕組み
ゼロ ETL は以下の 3 つのフェーズを自動的に処理します。
スキーマ同期 — DTS がソースのスキーマを読み取り、ClickHouse に該当するテーブルを作成します。各ターゲットテーブルには、
_sign、_is_deleted、および_versionの各フィールドが追加されます。フルデータ同期 — DTS がソースから既存の全レコードを ClickHouse にコピーします。
増分同期 — DTS がソース MySQL インスタンスのバイナリログを読み取り、INSERT、UPDATE、DELETE の変更を継続的に ClickHouse に適用します。
ソースで UPDATE または DELETE が実行されると、ClickHouse は新しいレコードを追加し、_sign、_is_deleted、および _version を用いて変更を追跡します。その結果、ターゲットデータベースのサイズがソースより大きくなる場合があります。最新のレコードのみをクエリするには、テーブル名の後に FINAL を指定するか、_sign または _is_deleted でフィルター処理してください。
サポート対象のパイプライン
| ソース | 送信先 | アクセス方法 | サポート対象のフェーズ |
|---|---|---|---|
| ApsaraDB RDS for MySQL | ApsaraDB for ClickHouse | Alibaba Cloud インスタンス | スキーマ同期、フル同期、増分同期 |
課金
ゼロ ETL 同期パイプラインは無料です。
前提条件
開始前に、以下の点をご確認ください。
ApsaraDB for ClickHouse クラスターと RDS for MySQL インスタンスが同一リージョンにあること
ソースの RDS for MySQL インスタンスにデータベースアカウントが存在すること。詳細については、「ApsaraDB RDS for MySQL インスタンス向けデータベースアカウントの作成」をご参照ください。
ターゲットの ClickHouse クラスターにデータベースアカウントが存在すること。詳細については、「ApsaraDB for ClickHouse クラスター向けデータベースアカウントの作成」をご参照ください。
制限事項
ソースデータベース(RDS for MySQL)
| 制約事項 | 詳細 |
|---|---|
| プライマリキー | 同期対象となるすべてのテーブルには、プライマリキーが必要です |
| テーブル名の変更 | RENAME TABLE 操作は同期されません |
| テーブル単位の同期上限 | 個別のテーブル(データベース全体ではなく)を同期する場合、1 タスクあたり最大 1,000 テーブルまでサポートします。1,000 テーブルを超える場合は、複数のタスクに分割するか、データベース単位での同期を行ってください |
| スキーマ同期またはフル同期中の DDL | スキーマ同期またはフルデータ同期が進行中の場合は、DDL 操作を実行しないでください。実行するとタスクが失敗します |
pt-online-schema-change | 同期対象オブジェクトとしてデータベース全体ではなく 1 つ以上のテーブルを選択した場合、同期中にこれらのテーブルに対して pt-online-schema-change または類似ツールを用いた DDL 操作を実行しないでください。実行するとデータの同期に失敗する可能性があります |
| 非標準 DDL | ソースで標準 MySQL 構文に準拠していない DDL 文を実行すると、タスクが失敗したり、データ損失が発生したりする可能性があります |
| バイナリログ記録 | binlog_row_image は full に設定する必要があります。ApsaraDB RDS for MySQL では、バイナリログ記録がデフォルトで有効になっています。セルフマネージド MySQL の場合は、binlog_format=row も併せて設定してください。プライマリ/プライマリ構成のセルフマネージド MySQL データベースでは、log_slave_updates |
| バイナリログ保持期間 | ApsaraDB RDS for MySQL の場合は、ローカルバイナリログを最低 3 日間(推奨:7 日間)、セルフマネージド MySQL の場合は最低 7 日間保持してください。DTS が必要なバイナリログを読み取れない場合、タスクは失敗します。保持期間不足による問題は、DTS のサービスレベルアグリーメント (SLA) の対象外となります |
| 非表示列(MySQL 8.0.23+) | 非表示列は同期されず、データが失われる可能性があります。タスク開始前に、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行して、これらの列を可視状態にしてください |
| Always-confidential(EncDB) | EncDB が有効な場合、フルデータ同期はサポートされません。透過的データ暗号化(TDE)は、スキーマ同期、フルデータ同期、および増分同期のすべてでサポートされています |
| トランザクションログのない読み取り専用インスタンス | ソースとして使用できません(例:RDS for MySQL 5.6 の読み取り専用インスタンス) |
| ハートビート文 | ゼロ ETL タスクは、バイナリログオフセットを進めるために、ソースで定期的に CREATE DATABASE IF NOT EXISTS \`test\` を実行します |
| バイナリログに記録されない変更 | 物理バックアップからの復元やカスケード操作によって適用された変更は同期されません。このような場合、影響を受けるオブジェクトを同期範囲から削除し、再度追加してください |
複数のインスタンスから単一の ApsaraDB for ClickHouse クラスターへデータを同期する場合、異なるタスクの同期対象が重複しないようにご注意ください。
一般的な制限事項
| 制約事項 | 詳細 |
|---|---|
| クラスターあたりの最大データベース数 | 最大 256 個のデータベースを単一の ApsaraDB for ClickHouse クラスターに同期できます。 |
| 命名規則 | データベース、テーブル、およびカラム名は、ApsaraDB for ClickHouse の命名規則に準拠する必要があります。詳細については、「オブジェクト命名規則の使用制限 |
| DATETIME の有効値 | ソースの DATETIME 値は、送信先クラスターでサポートされている時間範囲内である必要があります。詳細については、「時間範囲」のセクションをご参照ください。 |
データ型のマッピング
RDS for MySQL および ApsaraDB for ClickHouse のデータの型は、一対一で対応していません。スキーマ同期中に、DTS はソースフィールドの型を ClickHouse でサポートされている最も近い型にマップします。完全なマッピングテーブルについては、「スキーマ同期のためのデータの型マッピング」をご参照ください。
注意事項
クラスターあたりのゼロ ETL タスクの最大数
クラスターで作成可能なゼロ ETL タスクの最大数は、エディションによって異なります。
Enterprise Edition:
ceil(下限 CCU 制限 / 8)。下限 ClickHouse Compute Unit (CCU) 制限が 22 のクラスターの場合、計算式はceil(22 / 8) = 3となります。Community Edition:
ceil(合計 CPU コア数 / 8)。各ノードが 8 コアの 2 ノードクラスターの場合、計算式はceil(16 / 8) = 2となります。
クラスターが上限に達した場合、不要なタスクを削除するか、DTS コンソールから直接追加の同期タスクを作成してください。
送信先のテーブル構造
スキーマ同期時に、ゼロ ETL 機能は各送信先テーブルに _sign、_is_deleted、および _version の各フィールドを追加します。
Community-Compatible Edition クラスターの場合、タスクは各ソーステーブルに対してローカルテーブルと分散テーブルの両方を作成します。
分散テーブル: ソーステーブルと同じ名前です。クエリにはこちらのテーブルをご利用ください。
ローカルテーブル: 名前は
<distributed_table_name>_localです。ClickHouse がシャード単位のストレージに内部的に使用します。
スケジューリングとパフォーマンス
タスクは、トラフィックが少ない時間帯に実行してください。フルデータ同期中は、DTS がソースおよび送信先の読み取り/書き込みリソースを使用するため、サーバー負荷が高まる可能性があります。
事前準備
ゼロ ETL タスクを作成する前に、必要なサービスタイプリンクロールおよび Resource Access Management (RAM) ユーザーの権限を設定してください。
ステップ 1:サービスタイプリンクロールの作成
AliyunServiceRoleForClickHouseZeroETL のサービスタイプリンクロールを作成します。
タスク設定時にデータベースインスタンス ID を選択すると、コンソールから自動的にこのロールの作成を促すメッセージが表示されます。この場合、手動での作成は不要です。
ステップ 2:RAM ユーザーへの権限付与
RAM ユーザーがゼロ ETL タスクを作成できるようにするには、以下の権限を付与してください。「RAM ユーザーの権限管理」をご参照ください。
ソース RDS for MySQL:
AliyunRDSFullAccess送信先 ClickHouse クラスター:
AliyunClickHouseFullAccessDTS: 次のスクリプトを用いてカスタムポリシーを作成します。「カスタム権限ポリシーの作成」をご参照ください。
{
"Version": "1",
"Statement": [
{
"Action": "dts:*",
"Resource": "*",
"Effect": "Allow"
},
{
"Action": "ram:PassRole",
"Resource": "*",
"Effect": "Allow",
"Condition": {
"StringEquals": {
"acs:Service": "dts.aliyuncs.com"
}
}
}
]
}ゼロ ETL タスクの作成と開始
全体の流れは 5 ステップで構成されます:ゼロ ETL ページへ移動 → ソースおよび送信先データベースの構成 → 同期対象オブジェクトの選択 → テーブルフィールドの構成 → 事前チェックの実行 → タスクの開始です。
ステップ 1:ゼロ ETL ページへ移動
ApsaraDB for ClickHouse コンソール にログインします。
左上隅で、ご利用のクラスターのリージョンを選択します。
クラスターリスト ページで、Community Edition インスタンス一覧 タブをクリックし、対象のクラスター ID をクリックします。
左側のナビゲーションウィンドウで、ゼロ ETL(シームレス統合) をクリックします。
ステップ 2:ソースおよび送信先データベースの構成
ゼロ ETL タスクの作成 をクリックします。
タスク名 を入力します。
ソースおよび送信先データベースを構成します。
以下のパラメーターに基づいて、ソースおよび送信先データベースを構成してください。構成が完了したら、次へ をクリックします。
ソースデータベース
パラメーター
説明
データベースタイプ
RDS for MySQL(サポート対象の唯一のオプション)
アクセス方法
Alibaba Cloud インスタンス(サポート対象の唯一のオプション)
インスタンスリージョン
ソースの RDS for MySQL インスタンスのリージョン
RDS インスタンス ID
ソースの RDS for MySQL インスタンスの ID
データベースアカウント
RDS for MySQL インスタンスのデータベースアカウント
データベースパスワード
RDS for MySQL インスタンスのデータベースアカウントのパスワード
暗号化
[暗号化なし] または [SSL 暗号化] を選択します。 [SSL 暗号化] を選択した場合は、まず RDS for MySQL インスタンスで SSL 暗号化を有効化してください。 詳細については、「クラウド証明書を使用して SSL リンク暗号化をすばやく有効化する」をご参照ください。
送信先データベース
パラメーター
説明
データベースタイプ
ClickHouse
接続タイプ
Alibaba Cloud インスタンス(サポート対象の唯一のオプション)
インスタンスリージョン
送信先クラスターのリージョン
クラスター ID
送信先クラスターの ID
クラスタータイプ
Community Edition または Enterprise Edition
データベースアカウント
送信先クラスターのデータベースアカウント
データベースパスワード
送信先クラスターのデータベースアカウントのパスワード
接続テストと続行 をクリックします。
ステップ 3:同期対象オブジェクトの選択
ソースオブジェクト セクションで、同期するデータベースまたはテーブルを選択します。
をクリックして、選択済みオブジェクト セクションへ移動します。

次へ:データベースおよびテーブルフィールドの構成 をクリックします。
ステップ 4:テーブルフィールドの構成
データベース・テーブル・カラムの構成 ページで、各テーブルについて以下の設定を行います。
| フィールド | 説明 |
|---|---|
| タイプ | テーブルエンジンの種類 |
| プライマリキー列 | プライマリキーを構成する 1 つ以上のカラム。複合キーをサポート |
| ソートキー | ソートに使用する 1 つ以上のカラム。複合キーをサポート |
| 分散キー | シャード間のデータ分散に使用する単一のカラム |
| パーティションキー | (任意)パーティションに使用する空でないカラム。設定した場合は、カラムを空欄にすることはできません |
デフォルトでは、未定義の構成を持つテーブルのみが表示されます。すべてのテーブルを表示するには、定義ステータス を すべて に設定してください。パーティションキーは、プライマリキー列から選択する必要があります。これらのフィールドの詳細については、「CREATE TABLE」をご参照ください。
次へ:タスク設定の保存と事前チェック をクリックします。事前チェックの結果に関わらず、タスクは保存されます。
ステップ 5:事前チェックの実行とタスクの開始
成功率 が 100% に達した場合、開始 をクリックします。
事前チェックが失敗した場合、報告された問題をソースまたは送信先で修正し、ゼロ ETL ページから設定を変更して再び事前チェックを実行してください。
タスクが開始されると、ゼロ ETL ページにタスク ID/名前、ソース/送信先、およびステータスが表示されます。
ゼロ ETL タスクのモニタリング
タスクの健全性を確認するには、以下のいずれかの方法をご利用ください。本番環境でのワークロードでは、問題発生時に自動通知を受け取れるよう、アラートまたはイベントサブスクリプションを設定することを推奨します。
| 方法 | 最適な用途 | 制限事項 |
|---|---|---|
| ClickHouse コンソールでのアクティブな閲覧 | レプリケーションパフォーマンス、同期の詳細、およびタスクログの確認 | 自動通知機能はありません |
| CloudMonitor における同期遅延アラート | 遅延がしきい値を超えた際に自動アラートを受信 | 遅延のみを監視 |
| CloudMonitor におけるイベントサブスクリプション | タスクの障害および復旧に関する通知を受信 | 障害および復旧のみを監視 |
ApsaraDB for ClickHouse コンソールでのタスクモニタリング
ApsaraDB for ClickHouse コンソール にログインします。
左上隅で、ご利用のクラスターのリージョンを選択します。
クラスターリスト ページで、Community Edition インスタンス一覧 タブをクリックし、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、ゼロ ETL(シームレス統合) をクリックします。
対象のタスクを見つけ、操作 列の タスク詳細 をクリックします。
タスク詳細ページには、レプリケーションパフォーマンス、同期ステータス、およびログが表示されます。

CloudMonitor における同期遅延アラートの設定
CloudMonitor でアラートルールを作成します。「CloudMonitor コンソールでのアラートルールの作成」をご参照ください。以下のパラメーターを設定します。
パラメーター 値 製品 Clickhouse - ZeroETL Latency 監視メトリック 同期遅延 現在のレイテンシを表示するには、CloudMonitor コンソール にログインします。ClickHouse - ZeroETL レイテンシ リストで、対象クラスターの [操作] 列にある [モニタリングチャート] をクリックします。
CloudMonitor におけるゼロ ETL タスクイベントのサブスクリプション
システムイベントをサブスクライブすることで、タスクの障害または復旧時に自動通知を受信できます。「イベントサブスクリプションの管理」をご参照ください。
サブスクリプションポリシーを作成する際、以下のパラメーターを設定してください。
| イベント | パラメーター | 値 |
|---|---|---|
| タスク障害 | サブスクリプションタイプ | システムイベント |
| 製品 | ApsaraDB Clickhouse | |
| イベントタイプ | 異常 | |
| イベント名 | ZeroETL task abnormal | |
| タスク復旧 | サブスクリプションタイプ | システムイベント |
| 製品 | ApsaraDB Clickhouse | |
| イベントタイプ | 復旧 | |
| イベント名 | ZeroETLTaskRestore |
よくある質問
同期後、送信先データベースのサイズがソースより大きくなるのはなぜですか?
ClickHouse は、UPDATE や DELETE 時にレコードを上書きせず、代わりに新しいレコードを追加し、_sign、_is_deleted、および _version を用いて変更を追跡します。その結果、送信先のレコード数は時間とともにソースより増加します。
最新のデータのみをクエリするには、テーブル名の後に FINAL を指定するか、_sign または _is_deleted(正確なフィールドはクラスターのバージョンにより異なります)でフィルター処理してください。詳細については、「フィールド情報」をご参照ください。
`<table>_local` という名前のテーブルがターゲットデータベースに表示される理由は何ですか?
Community-Compatible Edition クラスターの場合、ゼロ ETL は各ソーステーブルに対してローカルテーブルと分散テーブルの両方を作成します。分散テーブル(ソーステーブルと同じ名前)がクエリ対象のテーブルです。_local テーブルは、ClickHouse がシャード単位のストレージに内部的に使用します。
バイナリログの保持期間が短すぎるとどうなりますか?
DTS はバイナリログを用いて増分変更を適用します。レプリケーションを継続するために必要なバイナリログがすでにパージされている場合、タスクは失敗し、再開できません。この場合、影響を受けるデータベースまたはテーブルを同期範囲から削除し、再度追加して、新たなフル同期をトリガーしてください。ApsaraDB RDS for MySQL の場合は、バイナリログを最低 3 日間(推奨:7 日間)、セルフマネージド MySQL の場合は最低 7 日間保持してください。
バイナリログオフセットエラーでゼロ ETL タスクが失敗するのはなぜですか?
ログファイルが DTS によって読み取られる前にパージされると、タスクはバイナリログ内の位置を失います。これは通常、保持期間が短すぎるために発生します。この場合、タスクは自動的に再開できません。影響を受けるテーブルまたはデータベースを同期範囲から削除し、再度追加して、新たなフル同期をトリガーしてください。再発防止のため、ApsaraDB RDS for MySQL の場合はバイナリログを最低 3 日間(推奨:7 日間)、セルフマネージド MySQL の場合は最低 7 日間保持してください。