PolarDB for MySQL から ApsaraDB for ClickHouse への移行 - Data Transmission Service

Data Transmission Service (DTS) を使用すると、PolarDB for MySQL クラスターから ApsaraDB for ClickHouse クラスターへデータを移行し、運用データを集中分析できます。

この移行を完了するための最小ステップ：

前提条件 (ClickHouse クラスターのバージョン、必要に応じたバイナリロギング) を満たします。
ソースとターゲットの両方のデータベースに必要な権限を付与します。
DTS 移行タスクを作成して構成します。
事前チェックを実行し、インスタンスを購入して、移行を開始します。

前提条件

開始する前に、次の前提条件を満たしていることを確認してください：

ApsaraDB for ClickHouse クラスターがバージョン 20.8 以降を実行していること。「クラスターの作成」をご参照ください。
ClickHouse クラスターのストレージ容量が、ソース PolarDB for MySQL クラスターの使用済みストレージ容量を上回ること。
増分データ移行の場合：ソースクラスターでバイナリロギングが有効になっており、loose_polar_log_bin パラメーターが on に設定されていること。「バイナリロギングの有効化」および「パラメーターの変更」をご参照ください。

PolarDB for MySQL クラスターでバイナリロギングを有効にすると、バイナリログファイルのストレージ料金が発生します。DTS がログにアクセスできなくならないよう、バイナリログの保持期間を少なくとも 3 日 (7 日を推奨します) に設定してください。「保持期間の変更」をご参照ください。

課金

移行タイプ	リンクセットアップ料金	データ転送料金
スキーマ移行 + 全量データ移行	無料	無料
増分データ移行	有料	課金概要をご参照ください。

必要な権限

移行タスクを構成する前に、次の権限を付与してください。

データベース	必要な権限	付与方法
ソース PolarDB for MySQL クラスター	移行オブジェクトの読み取り権限	データベースアカウントの作成と管理およびデータベースアカウントのパスワード管理
デスティネーション ApsaraDB for ClickHouse クラスター (v22.8 以降)	読み取り/書き込み権限 (特権アカウントがこの要件を満たします)	Community-compatible Edition クラスターのアカウント管理
デスティネーション ApsaraDB for ClickHouse クラスター (v21.8)	読み取り、書き込み、権限設定、および DDL の有効化	上記と同じ

制限事項

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

ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が低いと、移行速度が低下します。
オブジェクト名マッピングを使用してテーブルレベルで移行する場合、1 つの移行タスクでサポートされるテーブル数は最大 1,000 です。この制限を超える場合は、テーブルを複数のタスクに分割するか、データベースレベルで移行してください。
スキーマ移行および完全データ移行中は、ソースデータベースで DDL 操作を実行しないでください。実行すると、移行タスクが失敗します。

完全データ移行中、DTS はソースデータベースにクエリを実行するため、DDL 操作を一時的にブロックするメタデータロックが作成される場合があります。

完全データ移行のみを実行する場合 (増分なし)、移行中にソースデータベースに新しいデータを書き込まないでください。書き込むと、データに不整合が生じます。

その他の制限

移行元の PolarDB for MySQL クラスターの読み取り専用ノードは移行できません。
Object Storage Service (OSS) の外部テーブルは移行されません。
次のオブジェクトタイプはサポートされていません：INDEX、VIEW、PROCEDURE、FUNCTION、TRIGGER、FOREIGN KEY (FK)。
完全データ移行中は、プライマリスタンバイ切り替えはサポートされていません。切り替えが発生した場合は、移行タスクを再構成してください。
RENAME TABLE 操作は移行できません。
移行できるデータベースの最大数は 256 です (ApsaraDB for ClickHouse の制限)。
データベース名、テーブル名、列名は、「ApsaraDB for ClickHouse の命名規則」に準拠する必要があります。
パーティションキーは、NULL 値許容フィールドに設定できません。パーティションキーは、BIGINT、INT、TIMESTAMP、DATETIME、DATE のデータ型のみサポートします。
ApsaraDB for ClickHouse の時間型データには、特定の範囲制限があります。詳細については、「時間データ型の範囲」をご参照ください。
スキーマ移行を有効にすると、DTS は自動的に _sign、_is_deleted、_version フィールドをターゲットテーブルに追加します。スキーマ移行をスキップする場合は、これらのフィールドを含むターゲットテーブルを手動で作成してください。詳細については、「ターゲットテーブルの要件」をご参照ください。
DTS による移行中は、他の移行元から移行先データベースにデータを書き込まないでください。書き込むと、データに不整合が生じます。
DTS インスタンスに障害が発生した場合、DTS チームは 8 時間以内に復旧を試みます。復旧操作には、インスタンスの再起動や DTS インスタンスパラメーターの調整が含まれる場合があります (データベースパラメーターは変更されません)。
移行前に、両方のデータベースのパフォーマンスを評価し、負荷を軽減するためにオフピーク時間帯に移行を実行してください。
特定のテーブルを移行する場合 (データベース全体ではない)、それらのテーブルに対してオンライン DDL 変更に pt-online-schema-change を使用しないでください。使用すると、移行が失敗します。代わりに Data Management (DMS) を使用してください。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。
VECTOR 型のデータの移行はサポートされていません。

オンライン DDL の制限

ツールまたはモード	動作
DMS または gh-ost (移行元でのオンライン DDL 変更)	DTS は元の DDL ステートメントを移行先に移行しますが、一時テーブルのデータは移行されません。これにより、移行先でテーブルロックが発生する可能性があります。
pt-online-schema-change	サポートされていません。移行先でデータが失われるか、移行インスタンスが失敗する可能性があります。
一時テーブルモードのオンライン DDL (複数テーブルのマージを含む)	移行先でデータが失われるか、移行インスタンスが失敗する可能性があります。
移行元での非標準 MySQL DDL 構文	移行が失敗するか、データが失われる可能性があります。

増分移行でサポートされる SQL 操作

操作タイプ	サポートされている SQL ステートメント	サポートされていない SQL ステートメント
DML	INSERT、UPDATE、DELETE	—
DDL	CREATE TABLE、TRUNCATE TABLE、DROP TABLE、ADD COLUMN、MODIFY COLUMN、DROP COLUMN	RENAME TABLE、インデックス、パーティション、ビュー、プロシージャ、関数、トリガー、および外部キーに関連するすべての DDL

データ型のマッピング

PolarDB for MySQL と ApsaraDB for ClickHouse は異なるデータ型をサポートしているため、1 対 1 のマッピングが常に可能とは限りません。スキーマ移行中に、Data Transmission Service (DTS) はソースデータ型を ClickHouse でサポートされている最も近い型にマッピングします。完全なマッピングテーブルについては、「異種データベース間のデータ型のマッピング」をご参照ください。

移行タスクの作成

ステップ 1：データ移行ページへの移動

次のいずれかのコンソールを使用します。

DTS コンソール

DTS コンソールにログオンします。
左側のナビゲーションペインで、[データ移行] をクリックします。
左上隅で、移行インスタンスを配置するリージョンを選択します。

DMS コンソール

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

DMS コンソールにログオンします。
上部のナビゲーションバーで、ポインターを [Data + AI] > [DTS (DTS)] > [データ移行] に合わせます。
[データ移行タスク] の横にあるドロップダウンリストから、移行インスタンスを配置するリージョンを選択します。

ステップ 2：移行元データベースと移行先データベースの構成

[タスクの作成] をクリックし、以下のパラメーターを入力します。

カテゴリ	パラメーター	説明
—	タスク名	DTS タスクの名前。DTS が自動的に生成します。タスクを識別しやすくするために、わかりやすい名前を指定してください。名前は一意である必要はありません。
移行元データベース	既存の接続を選択	ドロップダウンリストから登録済みのデータベースインスタンスを選択すると、DTS が残りのパラメーターを自動的に入力します。インスタンスが登録されていない場合は、パラメーターを手動で入力してください。DMS コンソールでは、[DMS データベースインスタンスの選択] ドロップダウンを使用します。
	データベースタイプ	[PolarDB for MySQL] を選択します。
	アクセス方法	[Alibaba Cloud インスタンス] を選択します。
	インスタンスリージョン	移行元 PolarDB for MySQL クラスターが存在するリージョンを選択します。
	Alibaba Cloud アカウント間でのデータ複製	同一アカウントの移行には、[いいえ] を選択します。
	PolarDB クラスター ID	移行元 PolarDB for MySQL クラスターの ID を選択します。
	データベースアカウント	データベースアカウントを入力します。詳細については、「必要な権限」をご参照ください。
	データベースパスワード	データベースアカウントのパスワードを入力します。
	暗号化	必要に応じて暗号化方式を選択します。Secure Sockets Layer (SSL) 暗号化については、「SSL 暗号化の設定」をご参照ください。
移行先データベース	既存の接続を選択	移行元と同様に、登録済みのインスタンスを選択するか、パラメーターを手動で入力します。
	データベースタイプ	[ClickHouse] を選択します。
	アクセス方法	[Alibaba Cloud インスタンス] を選択します。
	インスタンスリージョン	移行先 ApsaraDB for ClickHouse クラスターが存在するリージョンを選択します。
	Alibaba Cloud アカウント間でのデータ複製	同一アカウント内の移行の場合は、[いいえ] を選択します。
	クラスタータイプ	ApsaraDB for ClickHouse クラスタータイプを選択します。
	クラスター ID	移行先 ApsaraDB for ClickHouse クラスターの ID を選択します。
	データベースアカウント	データベースアカウントを入力します。詳細については、「必要な権限」をご参照ください。
	データベースパスワード	データベースアカウントのパスワードを入力します。

[接続をテストして続行] をクリックします。

DTS サーバーの CIDR ブロックが、両方のデータベースのセキュリティ設定 (ホワイトリスト) に追加されていることを確認してください。詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加」をご参照ください。

ステップ 3：移行するオブジェクトの構成

[オブジェクトの構成] ページで、次のパラメーターを設定します。

パラメーター	説明
[移行タイプ]	目的に応じて移行タイプを選択します。 • [スキーマ移行 + 完全データ移行]：1 回限りのデータコピー。継続的なレプリケーションは行われません。 • [スキーマ移行 + 完全データ移行 + 増分データ移行]：移行元が稼働したまま移行先を同期状態に保つ継続的なレプリケーション。説明 [スキーマ移行] をスキップする場合は、開始前に移行先テーブルを手動で作成してください。[増分データ移行] をスキップする場合は、移行中に移行元データベースへの書き込みを避けてください。
[競合するテーブルの処理モード]	[事前チェックしてエラーを報告] (デフォルト)：移行先テーブルが移行元テーブルと名前が重複している場合、事前チェックが失敗します。必要に応じて「オブジェクト名マッピング」を使用してテーブル名を変更してください。 [エラーを無視して続行]：チェックをスキップします。完全データ移行中、移行先の競合するレコードは保持されます。増分移行中は上書きされます。スキーマが異なる場合、一致する列のみが移行されます。注意してご使用ください。
[移行先インスタンスのオブジェクト名の大文字と小文字]	移行先のデータベース名、テーブル名、列名の大文字と小文字を制御します。デフォルトは [DTS デフォルトポリシー] です。詳細については、「移行先インスタンスのオブジェクト名の大文字と小文字の指定」をご参照ください。
[移行元オブジェクト]	[送信元オブジェクト] セクションからデータベースまたはテーブルを選択し、矢印アイコンをクリックして [選択済みオブジェクト] に追加します。
[選択済みオブジェクト]	オブジェクトを右クリックして名前を変更します。複数のオブジェクトの名前を一度に変更するには、[一括編集] をクリックします。テーブルを右クリックして、データのフィルター条件を設定します。詳細については、「オブジェクト名のマッピング」および「フィルター条件の設定」をご参照ください。テーブルの SQL 操作を選択するには、選択中のオブジェクトボックスで対応するオブジェクトを右クリックし、表示されるダイアログボックスから目的の操作を選択します。サポートされている操作の一覧については、「増分移行可能な SQL 操作」をご参照ください。

ステップ 4：詳細設定の構成

[次へ: 詳細設定] をクリックし、以下を設定します。

パラメーター	説明
[タスクスケジューリング用の専用クラスター]	デフォルトでは、DTS はタスクを共有クラスターにスケジュールします。安定性を向上させるには、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。
[移行先データベースのタイムゾーン]	移行先 ClickHouse クラスターに書き込まれる日付と時刻データ (DateTime など) のタイムゾーン。
[接続失敗時のリトライ時間]	DTS が接続失敗時にタスクが失敗するまでリトライする時間。範囲：10～1,440 分。デフォルト：720 分。30 分より大きい値に設定してください。説明複数のタスクが同じ移行元または移行先データベースを共有する場合、最後に設定された値が有効になります。リトライ中もインスタンスには課金されます。
[その他の問題のリトライ時間]	DTS が失敗した DDL または DML 操作をタスクが失敗するまでリトライする時間。範囲：1～1,440 分。デフォルト：10 分。10 分より大きい値に設定してください。[接続失敗時のリトライ時間] より小さい値にする必要があります。
[完全データ移行のスロットリングを有効化]	全量データ移行中に、ソースと宛先の読み書き負荷を制限します。[ソースデータベースへの 1 秒あたりのクエリ数 (QPS)]、[全量データ移行の 1 秒あたりの行数 (RPS)]、および [全量移行のデータ移行速度 (MB/秒)] を設定します。[全量データ移行] が選択されている場合にのみ利用可能です。
[増分データ移行のスロットリングを有効化]	増分データ移行中の負荷を制限します。[増分データ移行] が選択されている場合にのみ、[増分データ移行の RPS] と [増分移行のデータ移行速度 (MB/s)] を設定できます。
[正方向タスクと逆方向タスクのハートビートテーブルに対する SQL 操作を削除するかどうか]	インスタンスの実行中に DTS がハートビートテーブルの SQL 操作を移行元に書き込むかどうかを制御します。[はい]：ハートビート書き込みは抑制されますが、レイテンシインジケーターが表示される場合があります。[いいえ]：ハートビート書き込みが有効になり、移行元データベースの物理バックアップとクローニングに影響を与える可能性があります。
[環境タグ]	環境 (例：本番環境またはテスト環境) を識別するためのオプションのタグ。
[ETL の構成]	ETL (extract, transform, and load) 機能を有効にするかどうかを設定します。[はい]：コードエディターにデータ処理ステートメントを入力します。詳細については、「データ移行またはデータ同期タスクでの ETL の構成」をご参照ください。[いいえ]：ETL 構成をスキップします。
[監視とアラート]	タスクの失敗またはレイテンシがしきい値を超えた場合にアラートを構成するかどうかを設定します。[はい]：アラートのしきい値と通知先を設定します。詳細については、「監視とアラートの構成」をご参照ください。[いいえ]：アラートなし。

ステップ 5：ClickHouse のテーブルフィールドの構成

[次へ: データベースとテーブルフィールドの設定] をクリックし、移行された各テーブルの [タイプ]、[主キー列]、[ソートキー]、[分散キー]、[パーティションキー] を設定します。

DTS が提供するデフォルト設定を確認または変更するには、[定義ステータス] を すべて に設定します。

主なルール：

[プライマリキー列] と [ソートキー] は複合キーをサポートします。ドロップダウンリストから複数のフィールドを選択してください。
[プライマリキー列] から 1 つ以上の列を選択して [パーティションキー] として使用します。
[分散キー] は単一フィールドのみサポートします。
[パーティションキー] は不要な場合は空白のままにできますが、NULL 値許容フィールドは選択しないでください。選択すると移行タスクが失敗します。
パーティションキーは、BIGINT、INT、TIMESTAMP、DATETIME、DATE のみサポートします。詳細については、「パーティションキーの計算ロジック」をご参照ください。

プライマリキー、ソートキー、パーティションキーの詳細については、「CREATE TABLE」をご参照ください。

ステップ 6：事前チェックの実行と移行の開始

[次へ: タスク設定を保存して事前チェック] をクリックします。このタスクの API パラメーターをプレビューするには、次に進む前に [次へ: タスク設定を保存して事前チェック] にポイントを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。
DTS は移行を開始する前に事前チェックを実行します。事前チェックが失敗した場合：
- 失敗した各項目の横にある[詳細を表示]をクリックして問題を修正した後、[再度事前チェック]をクリックします。
- 項目に警告 (失敗ではない) が表示され、そのリスクを許容できる場合は、[アラート詳細の確認] > [無視] > [OK] の順にクリックし、次に [再度事前チェック] をクリックします。
重要
事前チェックアラートを無視すると、データの不整合が発生する可能性があります。

ステップ 7：インスタンスの購入と移行の開始

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

[インスタンスの購入] ページで、以下のパラメーターを設定します。

セクション	パラメーター	説明
新しいインスタンスクラス	リソースグループ	移行インスタンスのリソースグループ。デフォルト：[デフォルトリソースグループ]。詳細については、「リソース管理とは」をご参照ください。
新しいインスタンスクラス	インスタンスクラス	インスタンスクラスによって移行速度が決まります。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

データ転送サービス (従量課金) サービス規約を読んで同意し、[購入して開始] > [OK]をクリックします。

[データ移行] ページで移行の進捗を確認します。

タスクに増分データ移行が含まれていない場合、完了すると自動的に停止します。[ステータス] 列に [完了] と表示されます。

タスクに増分データ移行が含まれている場合、継続的に実行され、自動的に停止することはありません。[ステータス] 列には 実行中 と表示されます。

移行済みデータのクエリ

移行後、移行先の ClickHouse クラスターからデータを取得するには、次のクエリを実行します。

SELECT * FROM <table_name> FINAL WHERE _sign > 0;

FINAL 修飾子は、同じソートキーを持つ行を重複排除することで、各行の最新バージョンが表示されるようにします。
WHERE _sign > 0 句は、削除された行を除外します。

FINAL を使用しない場合、クエリは重複したレコードまたは削除されたレコードを返すことがあります。

付録

送信先テーブルの要件

スキーマ移行をスキップして送信先テーブルを手動で作成する場合、テーブルは次の要件を満たす必要があります。

重要

宛先テーブルに ENGINE パラメーターが含まれている場合、ENGINE = ReplicatedReplacingMergeTree(_version, _is_deleted) に設定します。その他のエンジン設定は、データの不整合の原因となる場合があります。

Cluster Edition	テーブル作成要件
Community-compatible Edition	ローカルテーブルと分散テーブルの両方を作成します。分散テーブル名はソーステーブル名と一致する必要があります。ローカルテーブル名は `<distributed_table_name>_local` フォーマットに従う必要があります。
Enterprise Edition	ソーステーブルと同じ名前のテーブルを作成する必要があります。

DTS が追加するフィールド

Data Transmission Service (DTS) はスキーマ移行中に、次のフィールドを各送信先テーブルに自動的に追加します。

同期されたデータをクエリするには、次のクエリを使用します：

SELECT * FROM <table_name> FINAL WHERE _sign > 0;

クラスターバージョン	フィールド	データ型	デフォルト値	説明
ClickHouse V23.8 以前の Community-compatible Edition	`_sign`	Int8	1	DML 操作タイプ: INSERT または UPDATE = `1`、DELETE = `-1`。
ClickHouse V23.8 以前の Community-compatible Edition	`_version`	UInt64	1	レコードが ClickHouse クラスターに書き込まれたときのタイムスタンプ。
Enterprise Edition または ClickHouse V23.8 以降の Community-compatible Edition	`_sign`	Int8	1	DML 操作タイプ: INSERT または UPDATE = `1`、DELETE = `-1`。
	`_is_deleted`	UInt8	0	レコードが削除されたかどうか：挿入または更新 = `0`、削除 = `1`。
	`_version`	UInt64	1	レコードが ClickHouse クラスターに書き込まれたときのタイムスタンプ。

時間データ型の範囲

ソース PolarDB for MySQL クラスターの時間データが次の範囲外にある場合、ApsaraDB for ClickHouse に書き込まれる値は不正なものになります。

データ型	最小値	最大値
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

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

DTS は、ソースフィールドからパーティションキーの値を導出する際に、次のロジックを適用します。

ソースフィールドタイプ	計算ロジック
BIGINT	`intDiv(<partition_key_field>, 18014398509481984)`
INT	`intDiv(<パーティションキーフィールド>, 4194304)`
TIMESTAMP	`toYYYYMM(<パーティションキーフィールド>)`
DATETIME	`toYYYYMM(<パーティションキーフィールド>)`
DATE	`toYYYYMM(<パーティションキーフィールド>)`