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

Data Transmission Service:Db2 for LUW データベースから Alibaba Cloud Message Queue for Kafka インスタンスへのデータ移行

最終更新日:Mar 29, 2026

Data Transmission Service (DTS) を使用して、IBM Db2 for Linux, UNIX, and Windows (LUW) データベースから ApsaraMQ for Kafka インスタンスへデータを移行します。DTS は、Db2 for LUW に組み込まれた Change Data Capture (CDC) 技術を活用し、スキーマ移行、完全なデータ移行、および増分データ移行をサポートします。

課金

移行タイプインスタンス構成料金インターネットトラフィック料金
スキーマ移行および完全なデータ移行無料無料
増分データ移行有料です。詳細については、「課金概要」をご参照ください。

サポートされる SQL 操作

増分データ移行では、以下の DML 操作がサポートされます:INSERT、UPDATE、DELETE。

DTS はソースデータベースの外部キーを移行しません。ソースで定義されたカスケード操作および削除操作は、送信先には複製されません。

前提条件

開始する前に、以下の条件が満たされていることを確認してください。

ソース Db2 for LUW データベース:

  • ソースデータベースをホストするサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。

  • 移行対象のテーブルには、すべてのフィールドが一意である PRIMARY KEY または一意制約 (UNIQUE constraint) が設定されている必要があります。これらの制約がないテーブルでは、送信先に重複レコードが生成される可能性があります。

  • 増分データを移行する場合、ソースデータベースでアーカイブ・ロギングを有効にする必要があります。DTS は、Db2 トランザクションログを読み取って増分変更をキャプチャするため、アーカイブ・ロギングがアクティブである必要があります。logarchmeth1 または logarchmeth2 構成パラメーターを設定して、アーカイブ・ロギングを有効にします。詳細については、「logarchmeth1」および「logarchmeth2」をご参照ください。

    重要

    logarchmeth パラメーターを変更した後は、変更を有効にするためにソースデータベースのバックアップを実行してください。バックアップを行わないと、事前チェックが失敗する可能性があります。

  • 増分移行の場合、送信先データベースで操作ログが有効化されている必要があります。ログが無効化されていると、事前チェックが失敗し、タスクを開始できません。

  • 増分データ移行のみの場合:ソースデータベースのデータログは 24 時間以上保持する必要があります。

  • 完全なデータ移行と増分データ移行を併用する場合:データログは最低 7 日間保持する必要があります。

    ログ保持期間が不十分な場合、DTS がログを読み取れず、タスクの失敗やデータ損失が発生する可能性があります。完全なデータ移行が完了した後は、保持期間を 24 時間以上に短縮できます。ただし、保持要件を満たさない場合、DTS のサービスレベルアグリーメント (SLA) では信頼性およびパフォーマンスを保証しません。

送信先 ApsaraMQ for Kafka インスタンス:

  • 利用可能なストレージ容量が、ソース Db2 for LUW データベースの全データサイズより大きい必要があります。サイズ設計に関するガイダンスは、「概要」をご参照ください。

  • 移行データを受け取るトピックが作成済みである必要があります。「手順 3:リソースの作成」の「ステップ 1:トピックの作成」を参照してください。

サポートされる Db2 for LUW のバージョンについては、「データ移行シナリオの概要」をご参照ください。

必要な権限

移行タイプに応じて、Db2 for LUW データベースアカウントに以下の権限を付与してください。

移行タイプ必要な権限
完全なデータ移行CONNECT および SELECT
スキーマ移行CONNECT および SELECT
増分データ移行データベース管理者権限
増分データ移行では、DTS が Db2 のトランザクションログレコードを読み取るために、データベース管理者による権限付与が必要です。

アカウントの作成および権限の付与手順については、「Db2 データベースインストール用のグループおよびユーザー ID の作成」および「権限の概要」をご参照ください。

制限事項

カテゴリ制限事項
ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。そうでないと、移行速度が低下します。
ソースデータベーステーブルには、すべてのフィールドが一意である PRIMARY KEY または一意制約 (UNIQUE constraint) が設定されている必要があります。そうでないと、送信先に重複レコードが表示される可能性があります。
ソースデータベースオブジェクト名マッピングを使用して個別のテーブル(データベース全体ではなく)を移行する場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。1,000 個を超えるテーブルを移行する場合は、複数のタスクを設定するか、データベース全体を移行してください。
増分移行CDC レプリケーションは、Db2 for LUW の SQL Replication の制限に従います。詳細については、「SQL Replication の一般的なデータ制限」をご参照ください。
移行中完全なデータ移行中に、ソースで DDL 操作(スキーマ変更)を実行しないでください。スキーマ変更が検出されると、タスクは失敗します。
移行中完全なデータ移行のみを実行する場合、タスク実行中にソースデータベースへの書き込みを行わないでください。データの不整合が発生する可能性があります。ライブトラフィック下での整合性を確保するには、完全なデータ移行と増分データ移行の両方を選択してください。
パフォーマンス完全なデータ移行中、DTS はソースおよび送信先データベースの両方を読み書きするため、サーバー負荷が増加します。ピーク時間帯を避けて移行をスケジュールしてください。
ストレージ完全なデータ移行中の同時 INSERT 操作により、テーブルスペースフラグメントが発生します。移行完了後に、送信先のテーブルスペースがソースより大きくなる可能性があります。
データ隔離移行中は、ソースデータベースに関係のないデータを送信先に書き込まないでください。移行タスク完了後の DDL 操作には、Data Management (DMS) をご使用ください。
フェイルオーバータスク実行中に、ソースでプライマリ/セカンダリ スイッチオーバーが発生すると、タスクは失敗します。
移行遅延遅延は、最新の移行済みデータのタイムスタンプと現在のソースタイムスタンプとの差分で算出されます。ソースで長期間 DML 操作が行われていない場合、遅延の測定値は不正確になる可能性があります。遅延表示を更新するには、ソースで DML 操作を実行してください。データベース全体を移行する場合は、1 秒ごとに更新されるハートビートテーブルを作成してください。
ApsaraMQ for Kafka移行中に送信先 ApsaraMQ for Kafka インスタンスのスペックアップまたはスペックダウンを行う場合、タスクを再開するためにインスタンスを再起動する必要があります。

移行タスクの作成

ステップ 1:データ移行タスクページへ移動

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

  2. トップナビゲーションバーで、DTS をクリックします。

  3. 左側ナビゲーションウィンドウで、DTS (DTS)データ移行 を選択します。

DMS コンソールのレイアウトは、お客様の設定によって異なる場合があります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルのカスタマイズ」をご参照ください。あるいは、直接「新規 DTS コンソールのデータ移行タスクページ」にアクセスしてください。

ステップ 2:リージョンの選択

データ移行タスク の横にあるドロップダウンリストから、移行インスタンスを配置するリージョンを選択します。

新規 DTS コンソールでは、左上隅からリージョンを選択してください。

ステップ 3:ソースおよび送信先データベースの構成

タスクの作成 をクリックします。タスクの作成 ページで、以下のパラメーターを構成します。

タスク設定:

パラメーター説明
タスク名移行タスクの名前です。DTS が自動的にデフォルト名を割り当てます。識別しやすいように、意味のある名前を指定することを推奨します。名前は一意である必要はありません。

ソースデータベース(Db2 for LUW):

パラメーター説明
既存の DMS データベースインスタンスの選択(任意)以前に登録した DMS データベースインスタンスを選択します。選択した場合、DTS が以下のパラメーターを自動入力します。未指定の場合は、パラメーターを手動で構成してください。
データベースタイプDB2 for LUW を選択します。
アクセス方法ソースデータベースのデプロイ場所に応じて、アクセス方法を選択します。本例では Self-managed Database on ECS を使用します。その他のアクセス方法については、「事前準備の概要」をご参照ください。
インスタンスリージョンソース Db2 for LUW データベースが配置されているリージョンです。
Alibaba Cloud アカウント間でのデータ複製本例では いいえ を選択します。
ECS インスタンス IDソースデータベースをホストする ECS インスタンスの ID です。
ポート番号ソース Db2 for LUW データベースのサービスポートです。
データベース名移行対象オブジェクトを含むソースデータベースの名前です。
データベースアカウントデータベースアカウントです。「必要な権限」で最小限の権限要件をご確認ください。
データベースパスワードデータベースアカウントのパスワードです。

送信先データベース(ApsaraMQ for Kafka):

パラメーター説明
既存の DMS データベースインスタンスの選択(任意)以前に登録した DMS データベースインスタンスを選択します。選択した場合、DTS が以下のパラメーターを自動入力します。
データベースタイプKafka を選択します。
アクセス方法Express Connect、VPN Gateway、または Smart Access Gateway を選択します。DTS はこのアクセス方法を介して、自己管理 Kafka クラスターとして ApsaraMQ for Kafka インスタンスに接続します。
インスタンスリージョンApsaraMQ for Kafka インスタンスが配置されているリージョンです。
接続済み VPC送信先 ApsaraMQ for Kafka インスタンスの仮想プライベートクラウド(VPC)ID です。VPC ID を確認するには:ApsaraMQ for Kafka コンソールにログインし、「インスタンスの詳細」ページに移動して、VPC ID構成情報 セクション内の インスタンス情報 タブで確認します。
IP アドレスまたはドメイン名ApsaraMQ for Kafka インスタンスのデフォルトエンドポイントから取得した IP アドレスです。IP アドレスを確認するには:「インスタンスの詳細」ページで、エンドポイント情報 セクション(インスタンス情報 タブ内)に移動します。デフォルトエンドポイントタイプ 列に表示されているエンドポイントを見つけ、ドメイン名 列の値にカーソルを合わせて、表示された IP アドレスのいずれかをコピーします。
ポート番号ApsaraMQ for Kafka インスタンスのサービスポートです。デフォルト値:9092
データベースアカウントApsaraMQ for Kafka インスタンスの SASL ユーザー名です。アクセス制御リスト(ACL)機能が有効化されている場合にのみ必須です。ユーザー名を確認するには:「インスタンスの詳細」ページで、「SASL ユーザーの管理」タブに移動します。ACL の有効化手順については、「SASL ユーザーへの権限付与」をご参照ください。
データベースパスワードSASL パスワードです。「SASL ユーザーの管理」タブで該当アカウントを見つけ、パスワード 列の パスワードのコピー をクリックします。
Kafka バージョンApsaraMQ for Kafka インスタンスのバージョンです。インスタンスのバージョンが 0.10.2 の場合は 0.10 を選択します。バージョンが 2.6.2 または 2.2.0 の場合は 1.0 より後 を選択します。
暗号化セキュリティ要件に応じて、非暗号化 または SCRAM-SHA-256 を選択します。
トピック移行データを受け取るトピックです。ドロップダウンリストから選択します。
DDL 情報を格納するトピックDDL 情報を格納するトピックです。未構成の場合は、トピック で指定したトピックに DDL 情報が格納されます。
Kafka Schema Registry の使用Kafka Schema Registry を使用するかどうかです。いいえ を選択するとスキップされます。はい を選択した場合は、Avro スキーマを Kafka Schema Registry に格納する場合に、Schema Registry の URL または IP アドレスを入力します。

ステップ 4:接続性のテスト

接続性のテストと続行 をクリックします。

DTS は、Alibaba Cloud データベースインスタンスおよび ECS 上でホストされるデータベースのセキュリティ設定に、自動的に自社サーバーの CIDR ブロックを追加します。データセンターまたはサードパーティ環境でホストされる自己管理データベースの場合は、データベースのホワイトリストに DTS サーバーの CIDR ブロックを手動で追加する必要があります。CIDR ブロックの一覧および手順については、「オンプレミスデータベースのセキュリティ設定への DTS サーバー CIDR ブロックの追加」の「DTS サーバーの CIDR ブロック」セクションをご参照ください。

警告

DTS サーバーの CIDR ブロックをデータベースのホワイトリストまたは ECS セキュリティグループに追加すると、潜在的なセキュリティリスクが発生する可能性があります。続行する前に、以下の予防措置を講じてください:アカウントおよびパスワードのセキュリティ強化、公開ポートの制限、API 呼び出しの認証、ホワイトリストおよびセキュリティグループルールの定期的なレビュー(不正なエントリの削除)。可能であれば、パブリックエンドポイントではなく、Express Connect、VPN Gateway、または Smart Access Gateway を使用してデータベースを DTS に接続してください。

ステップ 5:オブジェクトの選択および移行設定の構成

パラメーター説明
移行タイプ実行する移行タイプを選択します:スキーマ移行完全なデータ移行、および 増分データ移行。移行中のサービス継続性を維持するには、すべてのタイプを選択してください。継続的なレプリケーションを伴わない単発の移行の場合は、スキーマ移行 および 完全なデータ移行 のみを選択します — タスク実行中にソースデータベースへの書き込みを行わないよう注意し、データの不整合を防止してください。
競合するテーブルの処理モード事前チェックおよびエラー報告:ソースおよび送信先で同名のテーブルがあるかをチェックします。競合が見つかると、タスクは開始されません。競合するテーブルの名前を変更するには、オブジェクト名マッピング機能をご利用ください。「オブジェクト名のマッピング」をご参照ください。エラーを無視して続行:競合チェックをスキップします。スキーマが一致する場合、重複するプライマリキーを持つ行はスキップされます。スキーマが異なる場合、一致するカラムのみが移行されるか、タスクが失敗します。慎重にご使用ください。
Kafka 内のデータ形式サポートされるのは DTS Avro のみです。データは DTS Avro スキーマを使用して解析されます。スキーマの詳細については、GitHub の「avro ディレクトリ」をご参照ください。
Kafka パーティションへのデータ配信ポリシー移行データを Kafka パーティションに分散するポリシーです。ビジネス要件に応じてポリシーを選択してください。利用可能なポリシーおよびその動作については、「Kafka パーティションへのデータ移行ポリシーの指定」をご参照ください。
宛先インスタンスにおけるオブジェクト名の大文字小文字の扱い宛先におけるデータベース名、テーブル名、カラム名の大文字小文字の扱いです。デフォルト値:DTS デフォルトポリシー。ソースまたは宛先と大文字小文字を一致させるには、対応するオプションを選択してください。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクトソースオブジェクト リストから移行対象のオブジェクトを選択し、アイコンをクリックして 選択済みオブジェクト に追加します。カラム、テーブル、またはデータベースを選択できます。テーブルまたはカラムを選択した場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトタイプは移行されません。
選択済みオブジェクト宛先でオブジェクト名を変更するには、選択済みオブジェクト セクションで該当オブジェクトを右クリックします。「単一オブジェクトの名前のマッピング」をご参照ください。複数のオブジェクトを一度に名前変更するには、一括編集 をクリックします。「複数のオブジェクト名を一度にマッピング」をご参照ください。WHERE 条件を使用して行をフィルターするには、オブジェクトを右クリックして条件を指定します。「フィルター条件の設定」をご参照ください。特定のオブジェクトに対してレプリケートする SQL 操作を選択するには、オブジェクトを右クリックして操作を選択します。
オブジェクト名マッピングを使用してオブジェクト名を変更する場合、それらに依存する他のオブジェクトが移行に失敗する可能性があります。

ステップ 6:高度な設定の構成

次へ:高度な設定 をクリックし、以下のパラメーターを構成します。

パラメーター説明デフォルト
タスクのスケジュールに使用する専用クラスターの選択デフォルトでは、DTS がタスクを共有クラスターにスケジュールします。専用クラスターを使用する場合は、ここから選択してください。詳細については、「DTS 専用クラスターとは」をご参照ください。共有クラスター
アラートの設定タスクが失敗した場合や移行遅延がしきい値を超えた場合にアラートを送信するかどうかです。はい を選択し、しきい値およびアラート連絡先を構成してください。「モニタリングとアラートの設定」をご参照ください。いいえ
接続失敗時の再試行時間ソースまたは送信先が到達不能になった場合の DTS の再接続試行時間です。この時間内に再接続されれば、DTS はタスクを再開します。それ以外の場合はタスクが失敗します。30 分を超える値を設定してください。有効範囲:10~1,440 分。複数のタスクが同じソースまたは送信先を共有する場合、最も最近設定された値が適用されます。720 分
ソースおよび送信先データベースでその他の問題が発生した際の再試行待機時間DDL または DML 操作の失敗時に DTS が再試行する待機時間です。接続失敗時の再試行時間 の値より小さくする必要があります。10 分を超える値を設定してください。有効範囲:1~1,440 分。10 分
完全なデータ移行におけるレート制限の有効化完全なデータ移行中の読み取り/書き込みレートを制限して、ソースおよび送信先の負荷を軽減するかどうかです。ソースデータベースへのクエリ/秒 (QPS)完全なデータ移行の RPS、および 完全なデータ移行のデータ移行速度 (MB/s) を構成します。完全なデータ移行 が選択されている場合にのみ表示されます。無効
増分データ移行におけるレート制限の有効化増分データ移行中のレートを制限するかどうかです。増分データ移行の RPS および 増分データ移行のデータ移行速度 (MB/s) を構成します。増分データ移行 が選択されている場合にのみ表示されます。無効
環境タグDTS インスタンスを識別するためのタグです。環境(例:本番またはテスト)に応じて選択してください。なし
ETL の構成移行データに抽出・変換・書き出し(ETL)処理を適用するかどうかです。はい を選択し、エディターにデータ処理文を入力してください。「データ移行または同期タスクにおける ETL の構成」をご参照ください。いいえ

ステップ 7:事前チェックの実行

次へ:タスク設定の保存および事前チェック をクリックします。

このタスク構成の API パラメーターを表示するには、次へ:タスク設定の保存および事前チェック にカーソルを合わせ、続行前に OpenAPI パラメーターのプレビュー をクリックします。

DTS は、移行タスクの開始前に事前チェックを実行します。事前チェックが失敗した場合:

  • 失敗項目については、項目の横にある 詳細の表示 をクリックし、報告された問題を修正してから、再チェック をクリックします。

  • 無視可能なアラート項目については、アラート詳細の確認 をクリックし、詳細の表示 ダイアログで 無視 をクリックします。確認メッセージで OK をクリックし、その後 再チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

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

ステップ 8:インスタンスの購入およびタスクの開始

インスタンスの購入 ページで、以下のパラメーターを構成します。

パラメーター説明
リソースグループ移行インスタンスのリソースグループです。デフォルト値:デフォルトリソースグループ。詳細については、「Resource Management とは
インスタンスクラスインスタンスクラスは移行速度を決定します。データ量および所要時間に応じて選択してください。仕様については、「データ移行インスタンスの仕様」をご参照ください。

Data Transmission Service(従量課金)の利用規約 チェックボックスをオンにし、購入および開始 をクリックします。

タスクがタスクリストに表示されます。そこから進行状況を監視できます。

次のステップ

  • 移行後の送信先で DDL 操作を実行するには、ロック問題を回避するために Data Management (DMS) をご使用ください。