Data Transmission Service (DTS) を使用すると、自己管理 Oracle データベースから ApsaraMQ for Kafka インスタンスへデータを移行できます。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしています。サービス継続性を確保し、データギャップを発生させずに継続的なレプリケーションを実現する必要があるライブシステムでは、これら 3 つの移行タイプを併用することを推奨します。
前提条件
開始する前に、以下のすべての手順を完了していることを確認してください。
ソースおよび宛先インスタンスの作成。 自己管理 Oracle データベースと ApsaraMQ for Kafka インスタンスの両方が起動中である必要があります。対応バージョンについては、「データ移行シナリオの概要」をご参照ください。
Oracle における ARCHIVELOG モードの有効化。 Oracle データベースは ARCHIVELOG モードで実行する必要があり、アーカイブログファイルにアクセス可能であることと、適切な保持期間が設定されている必要があります。「アーカイブ・リドゥ・ログ・ファイルの管理」をご参照ください。
Oracle における補足ログの有効化。 補足ログを有効化し、
SUPPLEMENTAL_LOG_DATA_PKおよびSUPPLEMENTAL_LOG_DATA_UIをYESに設定する必要があります。「補足ログ」をご参照ください。Kafka ストレージ容量の検証。 ApsaraMQ for Kafka インスタンスの利用可能なストレージは、Oracle データベースが占有するストレージ量を超える必要があります。
Kafka トピックの作成。 移行されたデータを受け取るためのトピックを ApsaraMQ for Kafka インスタンス内に作成します。「ステップ 1：トピックの作成」をご参照ください。
必要な権限を持つ Oracle データベースアカウントの作成。 下記の「Oracle アカウントの設定」をご参照ください。
Oracle に対する DTS の機能および制限事項の確認。 移行前のデータベース評価には、Advanced Database and Application Migration (ADAM) をご利用いただけます。「Oracle データベースの準備」および「概要」をご参照ください。
Oracle アカウントの設定
以下に示す権限を持つデータベースアカウントを作成します。既に該当するアカウントをお持ちの場合は、この手順をスキップできます。
| データベース | スキーマ移行 | 完全なデータ移行 | 増分データ移行 |
|---|---|---|---|
| ソース Oracle データベース | スキーマ所有者の権限 | スキーマ所有者の権限 | 詳細な権限 |
データベースアカウントの作成および必要な権限の付与に関する詳細な手順については、「データベースアカウントの準備」、「CREATE USER」および「GRANT」をご参照ください。
増分データ移行の場合、アーカイブログおよび補足ログの有効化も必須です。「Oracle データベースの構成」をご参照ください。
制限事項
DTS は外部キーを移行しません。ソースで定義された CASCADE および DELETE 動作は、宛先では適用されません。
ネットワークおよび接続性
ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行スループットが低下します。
Express Connect 経由で接続される Oracle Real Application Clusters（RAC）の場合：ソースデータベースの構成時に、データベースに対して仮想 IP アドレス（VIP）を指定する必要があります。
Express Connect、VPN Gateway、Smart Access Gateway、Database Gateway、または Cloud Enterprise Network（CEN）経由で接続される Oracle Real Application Clusters（RAC）の場合：Single Client Access Name（SCAN）IP の代わりに、単一の仮想 IP アドレス（VIP）を使用します。VIP を指定した後、その Oracle RAC データベースではノードフェイルオーバーがサポートされなくなります。
データ型
ソース Oracle のフィールドに空の
VARCHAR2文字列（Oracle ではNULLとして扱われる）が含まれており、対応する宛先フィールドにNOT NULL制約が設定されている場合、移行タスクは失敗します。移行中に
LONGTEXTフィールドを更新しないでください。LONGTEXTの更新が検出された場合、タスクは失敗します。
オブジェクト要件
テーブルには
PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。これを満たさない場合、宛先に重複レコードが発生する可能性があります。Oracle 12c 以降では、テーブル名は 30 バイトを超えてはなりません。
個別のテーブルを選択し、テーブルまたはカラムの名前を変更する必要がある場合：1 つのタスクでは最大 1,000 個のテーブルをサポートします。1,000 個を超えるテーブルを移行する場合は、複数のタスクに分割するか、1 つのタスクでデータベース全体を移行してください。
増分移行のためのログ保持
リドゥログおよびアーカイブログの有効化が必要です。
| 移行モード | 最低ログ保持期間 |
|---|---|
| 増分移行のみ | 24 時間以上 |
| 完全移行 ＋ 増分移行 | 最低 7 日間（完全移行完了後は 24 時間に短縮可能） |
DTS が必要なログにアクセスできない場合、タスクは失敗します。極端なケースでは、データの不整合や損失が発生する可能性があります。DTS のサービスレベル契約（SLA）では、ログ保持期間が不足したことによる失敗は保証対象外です。
移行中の運用制限
| フェーズ | 制限事項 |
|---|---|
| スキーマ移行および完全なデータ移行 | データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。 |
| 完全移行のみ | ソースデータベースへの書き込みを禁止します。整合性を保証するため、スキーマ移行、完全なデータ移行、および増分データ移行を同時に実行してください。 |
その他の考慮事項
ピーク時を避けて移行を実行してください。完全なデータ移行は、ソースおよび宛先サーバーの読み取りおよび書き込み負荷を増加させます。
完全なデータ移行後、宛先の表領域はソースよりも大きくなります。これは、同時実行の
INSERT操作によって断片化が発生するためです。DTS は、失敗した移行タスクを最大 7 日間再試行します。ワークロードを宛先に切り替える前に、失敗したタスクを停止または解放するか、
REVOKEを使用して DTS の書き込み権限を取り消してください。そうしないと、再開された失敗タスクが宛先データをソースデータで上書きする可能性があります。移行中に宛先 Kafka クラスターのスペックアップまたはスペックダウンが行われた場合、クラスターを再起動してください。
課金
| 移行タイプ | インスタンス構成料金 | インターネットトラフィック料金 |
|---|---|---|
| スキーマ移行 ＋ 完全なデータ移行 | 無料 | データが Alibaba Cloud 外のインターネットを経由して送信される場合にのみ課金されます。「課金概要」をご参照ください。 |
| 増分データ移行 | 課金対象です。「課金概要」をご参照ください。 | — |
移行タイプの選択
目的に応じて移行タイプを選択してください。ライブシステムでは、3 つのタイプを併用することを推奨します。
| 移行タイプ | 処理内容 | 使用タイミング |
|---|---|---|
| スキーマ移行 | Oracle から Kafka へのオブジェクトスキーマを移行します。トリガーはサポートされていません。データの不整合を防ぐため、移行前にソースのトリガーを削除してください。「トリガーを含むソースデータベース向けのデータ同期タスクの構成」をご参照ください。 | 常に最初のステップとして実行します。 |
| 完全なデータ移行 | Oracle から Kafka へのすべての既存データを移行します。このフェーズでは、移行済みオブジェクトに対する DDL を実行しないでください。 | ライブトラフィックがない場合の、一度限りの既存データロードにのみ使用します。 |
| 増分データ移行 | Oracle のリドゥログファイルを読み取り、変更を継続的に Kafka にストリーム配信します。移行中および移行後に宛先を同期状態に保ちます。 | ライブシステムでは、完全なデータ移行と併用してください。 |
推奨： スキーマ移行、完全なデータ移行、および 増分データ移行 を同時に選択してください。これは、自己管理 Oracle データベースからデータを移行する際にサービス継続性を確保する標準的な手法です。
増分移行でサポートされる SQL 操作
| 操作タイプ | SQL ステートメント |
|---|---|
| DML | INSERT、UPDATE、DELETE |
| DDL | CREATE TABLE、ALTER TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE |
| CREATE VIEW、ALTER VIEW、DROP VIEW | |
| CREATE PROCEDURE、ALTER PROCEDURE、DROP PROCEDURE | |
| CREATE FUNCTION、DROP FUNCTION、CREATE TRIGGER、DROP TRIGGER | |
| CREATE INDEX、DROP INDEX |
移行タスクの構成および開始
ステップ 1: データ移行タスクページを開く
Data Management（DMS）コンソール にログインします。
トップナビゲーションバーで、DTS をクリックします。
左側のナビゲーションウィンドウで、DTS（DTS） > データ移行 を選択します。
正確なナビゲーションパスは、DMS コンソールのモードおよびレイアウトによって異なります。「シンプルモード」および「DMS コンソールのレイアウトおよびスタイルのカスタマイズ」をご参照ください。あるいは、直接「データ移行タスクページ」にアクセスしてください。
データ移行タスク の横にあるドロップダウンリストから、移行インスタンスを配置するリージョンを選択します。
新しい DTS コンソールでは、左上隅からリージョンを選択します。
ステップ 2：ソースおよび宛先データベースの構成
タスクの作成 をクリックします。[タスクの作成] ページで、以下のパラメーターを構成します。
ソースおよび宛先データベースの構成後、次のステップに進む前に、ページ上部に表示される 制限事項 を必ずご確認ください。このステップをスキップすると、タスクが失敗したり、データの不整合が発生したりする可能性があります。
ソースデータベース
| パラメーター | 説明 |
|---|---|
| タスク名 | タスクの名前です。DTS が自動的に名前を割り当てますが、識別しやすいように、意味のある名前に置き換えてください。名前は一意である必要はありません。 |
| DMS データベースインスタンスの選択 | 既存のインスタンスを選択する（DTS がパラメーターを自動入力）か、空白のままにして手動で構成します。 |
| データベースタイプ | Oracle を選択します。 |
| アクセス方法 | ソースデータベースのデプロイ場所に応じた方法を選択します。この例では、ECS 上の自己管理データベース を使用します。自己管理データベースを使用する場合は、事前に必要なネットワーク環境を構成してください。「事前準備の概要」をご参照ください。 |
| インスタンスリージョン | ソース Oracle データベースが配置されているリージョンです。 |
| ECS インスタンス ID | Oracle データベースをホストする Elastic Compute Service（ECS）インスタンスの ID です。 |
| ポート番号 | Oracle サービスポートです。デフォルト値：1521。 |
| Oracle タイプ | 非 RAC インスタンス（SID パラメーターが必要）または RAC または PDB インスタンス（サービス名 パラメーターが必要）を選択します。この例では、非 RAC インスタンス を使用します。 |
| データベースアカウント | 「Oracle アカウントの設定」で説明されている権限を持つ Oracle アカウントです。 |
| データベースパスワード | データベースアカウントのパスワードです。 |
宛先データベース
| パラメーター | 説明 |
|---|---|
| DMS データベースインスタンスの選択 | 既存のインスタンスを選択する（DTS がパラメーターを自動入力）か、空白のままにして手動で構成します。 |
| データベースタイプ | Kafka を選択します。 |
| アクセス方法 | Express Connect、VPN Gateway、または Smart Access Gateway を選択します。ApsaraMQ for Kafka は直接アクセス方法として提供されていないため、自己管理 Kafka データベースとして構成してください。 |
| インスタンスリージョン | ApsaraMQ for Kafka インスタンスのリージョンです。 |
| 接続済み VPC | ApsaraMQ for Kafka インスタンスの仮想プライベートクラウド（VPC）ID です。確認方法：ApsaraMQ for Kafka コンソールで、インスタンスの インスタンスの詳細 ページ > インスタンス情報 タブ > 構成情報 セクションに移動します。 |
| IP アドレスまたはドメイン名 | ApsaraMQ for Kafka インスタンスの デフォルトエンドポイント からの IP アドレスです。確認方法：ApsaraMQ for Kafka コンソールで、インスタンスの詳細 > インスタンス情報 タブ > エンドポイント情報 セクション > デフォルトエンドポイント に移動します。 |
| ポート番号 | Kafka サービスポートです。デフォルト値：9092。 |
| データベースアカウント | ApsaraMQ for Kafka アカウントです。インスタンスタイプが VPC タイプ の場合は不要です。 |
| データベースパスワード | データベースアカウントのパスワードです。インスタンスタイプが VPC タイプ の場合は不要です。 |
| Kafka バージョン | 宛先 ApsaraMQ for Kafka インスタンスのバージョンです。 |
| 暗号化 | セキュリティ要件に応じて、暗号化なし または SCRAM-SHA-256 を選択します。 |
| トピック | 移行されたデータを受け取るトピックです。ドロップダウンリストから選択します。 |
| DDL イベントを保存するトピック | DDL イベントを保存するトピックです。空白のままにした場合、DDL イベントは トピック で指定されたトピックに保存されます。 |
| Kafka Schema Registry の使用 | Avro スキーマ管理のために Kafka Schema Registry を使用するかどうかです。はい を選択し、必要に応じてレジストリ URL を入力するか、いいえ を選択します。 |
ステップ 3：接続性のテストおよび DTS CIDR ブロックの追加
ソースデータベースで IP アローリストが構成されている場合、DTS サーバーの CIDR ブロックをそのリストに追加してください。
DTS CIDR ブロックをデータベースのアローリストまたは ECS セキュリティグループに追加すると、潜在的なセキュリティリスクが発生する可能性があります。実行前に、認証情報の強化、公開ポートの制限、API 呼び出しの認証、アローリストルールの定期的なレビュー、不正な CIDR 範囲のブロックなどの予防措置を講じてください。あるいは、パブリックアクセスを開放する代わりに、Express Connect、VPN Gateway、または Smart Access Gateway を介して DTS をデータベースに接続することもできます。
接続性のテストと続行 をクリックします。
ステップ 4：オブジェクトの選択および移行設定の構成
| パラメーター | 説明 |
|---|---|
| 移行タイプ | 一度限りの移行を行う場合は、スキーマ移行 および 完全なデータ移行 を選択します。宛先を同期状態に保ち、サービス継続性を維持する場合は、スキーマ移行、完全なデータ移行、および 増分データ移行 の 3 つをすべて選択します。 増分データ移行 を選択しない場合、データの不整合を防ぐため、移行中にソースデータベースへの書き込みを避けてください。 |
| 競合テーブルの処理モード | 事前チェックおよびエラー報告（デフォルト）：宛先にソースと同じ名前のテーブルが存在する場合、事前チェックが失敗します。競合テーブルを削除できない場合は、オブジェクト名マッピングを使用して名前を変更してください。「オブジェクト名のマッピング」をご参照ください。エラーを無視して続行：名前競合のチェックをスキップします。主キーが一致するレコードは移行されず、スキーマの不一致により部分的な移行またはタスクの失敗が発生する可能性があります。慎重に使用してください。 |
| Kafka 内のデータ形式 | DTS Avro：DTS Avro スキーマを使用してデータを解析します。スキーマ定義については、「GitHub」をご参照ください。SharePlex JSON：データは SharePlex JSON 形式で保存されます。「Shareplex Json」セクション（「Kafka クラスターのデータ形式」）をご参照ください。 |
| Kafka パーティションへのデータ送信ポリシー | 移行データのパーティショニングポリシーです。「Kafka パーティションへのデータ移行ポリシーの指定」をご参照ください。 |
| ソースオブジェクト／選択済みオブジェクト | ソースオブジェクト で移行するテーブルまたはデータベースを選択し、矢印アイコンをクリックして 選択済みオブジェクト に移動します。単一のオブジェクトの名前を変更するには、選択済みオブジェクト 内で右クリックします。「単一オブジェクトの名前のマッピング」をご参照ください。複数のオブジェクトを一度に名前変更するには、一括編集 をクリックします。「複数のオブジェクト名を一度にマッピング」をご参照ください。WHERE 句を使用して行を条件付きでフィルターするには、テーブルを右クリックして WHERE 句を指定します。「フィルター条件の設定」をご参照ください。特定のオブジェクトに対して増分移行される SQL 操作を制限するには、そのオブジェクトを右クリックして操作を選択します。 |
オブジェクト名マッピングを使用してオブジェクトの名前を変更した場合、それらに依存する他のオブジェクトが移行に失敗する可能性があります。
ステップ 5：高度な設定の構成
次へ：高度な設定 をクリックします。
| パラメーター | 説明 |
|---|---|
| タスクのスケジュールに使用する専用クラスターの選択 | DTS はデフォルトで共有クラスターにタスクをスケジュールします。このタスクを専用クラスターで実行するには、専用クラスターを購入して、ここから選択してください。「DTS 専用クラスターとは」をご参照ください。 |
| 接続失敗時の再試行時間 | 接続失敗後の DTS の再試行時間です。有効値：10～1440 分。デフォルト値：720 分。30 分を超える値を設定してください。このウィンドウ内で DTS が再接続できた場合、タスクは再開されます。そうでない場合、タスクは失敗します。複数のタスクが同じソースまたは宛先データベースを共有する場合、最も最近設定された再試行ウィンドウがすべてのタスクに適用されます。再試行期間中は、DTS インスタンスに対して課金されます。 |
| ソースおよび宛先データベースでその他の問題が発生した際の再試行までの待機時間 | DDL または DML 操作の失敗後の DTS の再試行時間です。有効値：1～1440 分。デフォルト値：10 分。10 分を超える値を設定してください。この値は、接続失敗時の再試行時間 よりも小さくなければなりません。 |
| 完全なデータ移行のスロットリングの有効化 | 完全移行中の読み取り／書き込みスループットを制限して、データベースサーバーの負荷を軽減します。ソースデータベースへのクエリ数（QPS）、完全なデータ移行の RPS、および 完全移行のデータ移行速度（MB/s） を構成します。完全なデータ移行 が選択されている場合にのみ利用可能です。 |
| 増分データ移行のスロットリングの有効化 | 増分移行中のスループットを制限します。増分データ移行の RPS および 増分移行のデータ移行速度（MB/s） を構成します。増分データ移行 が選択されている場合にのみ利用可能です。 |
| 環境タグ | DTS インスタンスを環境（例：本番環境または開発環境）で分類するための任意のタグです。 |
| 実際の書き込みコード | 宛先に書き込まれるデータの文字コードです。データ要件に応じて選択してください。 |
| ETL の構成 | 宛先に書き込む前にデータを変換するかどうかです。はい を選択すると、コードエディタで処理ステートメントを入力できます。「データ移行またはデータ同期タスクでの ETL の構成」をご参照ください。いいえ を選択すると、ETL をスキップします。「ETL とは |
| モニタリングとアラート | タスクの失敗または高い移行遅延に対してアラートを構成するかどうかです。はい を選択し、しきい値およびアラート連絡先を指定します。「新しい DTS タスクのモニタリングおよびアラートの構成」をご参照ください。 |
ステップ 6：事前チェックの実行
次へ：タスク設定の保存および事前チェック をクリックします。
この構成で使用される API パラメーターを確認するには、次へ：タスク設定の保存および事前チェック の上にカーソルを合わせ、API 呼び出しのプレビュー をクリックします。
DTS はタスクを開始する前に事前チェックを実行します。いずれかの項目が失敗した場合：
失敗した項目の横にある 詳細の表示 をクリックし、問題を修正してから、再度事前チェック をクリックします。
アラート項目が重大でなく、無視できる場合は、アラート詳細の確認 > 無視 > OK をクリックし、その後 再度事前チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
成功率 が 100 % になるまで待ち、その後 次へ：インスタンスの購入 をクリックします。
ステップ 7：インスタンスの購入およびタスクの開始
インスタンスの購入 ページで、インスタンスクラスを構成します。
| セクション | パラメーター | 説明 |
|---|---|---|
| 新規インスタンスクラス | リソースグループ | 移行インスタンスのリソースグループ。デフォルト: デフォルト リソースグループ。詳しくは、「Resource Management とは？ |
| インスタンスクラス | インスタンスクラスは、移行スループットを決定します。「データ移行インスタンスの仕様」をご参照ください。 |
Data Transmission Service（従量課金）サービス利用規約 のチェックボックスをオンにし、購入および開始 をクリックします。
タスク管理 ページで進行状況を監視します。
次のステップ
データ移行シナリオの概要 — 対応するソースおよび宛先バージョンの完全なリストをご確認ください。
オブジェクト名のマッピング — オブジェクトが宛先に到着した際に名前を変更します。
フィルター条件の設定 — WHERE 条件を使用して、行のサブセットを移行します。
Kafka パーティションへのデータ移行ポリシーの指定 — Kafka パーティション全体へのデータの分散方法を制御します。