Data Transmission Service (DTS) の使用中にエラーメッセージが表示された場合は、「一般的なエラー」で解決策をご参照ください。特定のエラーメッセージが表示されない場合は、次のカテゴリに基づいて問題と解決策をご確認ください。
問題のカテゴリ
次のような種類の一般的な問題が発生する可能性があります。
課金に関する問題
DTS の課金方法
DTS は、サブスクリプションと従量課金の 2 つの課金方法を提供しています。課金方法の詳細については、「課金概要」をご参照ください。
DTS の請求書の確認方法
DTS の請求書の確認方法については、「請求書の表示」をご参照ください。
一時停止中のインスタンスは課金されますか。
一時停止中のデータ移行インスタンスは課金されません。
データ同期がデータ移行より高価な理由
データ同期は、オンラインでの同期オブジェクトの変更や、MySQL データベース間の双方向データ同期の設定など、より高度な機能を提供します。さらに、データ同期は内部ネットワーク伝送を使用するため、ネットワーク遅延が低く抑えられます。
支払い遅延による影響
支払い遅延による影響の詳細については、「有効期限切れまたは支払い遅延」をご参照ください。
サブスクリプションタスクを事前にリリースする方法
まず、サブスクリプションタスクの課金方法を従量課金に切り替えてから、タスクをリリースします。課金方法の切り替え方法の詳細については、「課金方法の切り替え」をご参照ください。
タスクの課金方法をサブスクリプションから従量課金に切り替えることはできますか。
はい、できます。詳細については、「課金方法の切り替え」をご参照ください。
タスクの課金方法を従量課金からサブスクリプションに切り替えることはできますか。
はい、データ同期または変更追跡タスクの場合は可能です。詳細については、「課金方法の切り替え」をご参照ください。
データ移行タスクは、従量課金のみをサポートしています。
DTS タスクが突然課金されるようになった理由
インスタンスの無料トライアル期間が終了した可能性があります。DTS は、ターゲットデータベースが Alibaba Cloud によって開発されたエンジンであるタスクに対して無料トライアルを提供しています。無料トライアル期間が終了すると、これらのタスクは課金対象となります。
リリース済みのタスクがまだ課金されている理由
従量課金の DTS タスクの請求書は毎日生成されます。タスクをリリースした日は、その日に DTS サービスを使用したため課金されます。
従量課金の仕組み
従量課金タスクは、タスクが実行中の場合にのみ課金されます。この期間には、増分データ同期 タスクが一時停止されている時間が含まれますが、増分データ移行 タスクが一時停止されている時間は含まれません。詳細については、「課金方法」をご参照ください。
DTS はトラフィックに対して課金しますか。
一部の DTS タスクでは、ソースデータベースとターゲットデータベースのリージョンに関係なく、パブリックネットワークとデータトラフィックの料金が発生します。移行タスクでは、ターゲットデータベースの アクセス方法 が パブリック IP アドレス に設定されている場合、パブリックネットワークのトラフィック料金が発生します。行サンプリングによるフルフィールド検証 モードの完全検証タスクでは、検証されたデータ量に基づいてデータトラフィック料金が発生します。詳細については、「課金項目」をご参照ください。
パフォーマンスと仕様に関する問題
インスタンスタイプの違い
インスタンスタイプの違いについては、「データ移行リンク仕様」および「データ同期リンク仕様」をご参照ください。
インスタンスタイプをスペックアップできますか。
はい、できます。詳細については、「インスタンスのリンク仕様をアップグレードする」をご参照ください。
インスタンスタイプをスペックダウンできますか。
現在、データ同期インスタンスのみスペックダウンできます。詳細については、「データ同期インスタンスの仕様をダウングレードする」をご参照ください。
DTS タスクのインスタンスタイプをスペックダウンできますか。
対象となる DTS タスクのリンク仕様をスペックダウンできます。詳細については、「インスタンスのリンク仕様をダウングレードする」をご参照ください。
DTS タスクを中仕様より低い仕様にスペックダウンできますか。
サポートされていません。
データの同期または移行にかかる時間
DTS タスクに必要な時間を正確に見積もることはできません。パフォーマンスは、DTS、ソース、およびターゲットデータベースインスタンスの負荷、データ量、増分タスクの有無、ネットワーク状態など、多くの要因に依存します。高いパフォーマンス要件がある場合は、より高いパフォーマンス制限を持つインスタンスタイプを選択してください。仕様の詳細については、「データ移行リンク仕様」および「データ同期リンク仕様」をご参照ください。
データ移行またはデータ同期タスクのパフォーマンス情報の表示方法
パフォーマンス情報の表示方法については、「増分移行リンクのステータスとパフォーマンスの表示」または「同期リンクのステータスとパフォーマンスの表示」をご参照ください。
コンソールで特定の DTS インスタンスが見つからない理由
考えられる原因：指定された DTS インスタンスが、有効期限が切れてリリースされたサブスクリプションインスタンスである可能性があります。
選択したリソースグループが正しくありません。[すべてのリソース] を選択することを推奨します。
選択したリージョンが正しくありません。ターゲットインスタンスが存在するリージョンを選択していることを確認してください。
インスタンスに選択したタスクタイプが正しくありません。現在のタスクリストページがターゲットインスタンスのタスクタイプと一致していることを確認してください。たとえば、同期インスタンスは データ同期タスク リストにのみ表示されます。
インスタンスは、有効期限切れまたは支払い遅延のためにリリースされました。DTS インスタンスの有効期限が切れるか、支払い遅延が発生すると、データ転送タスクは停止します。7 日以内に支払いが行われない場合、システムはインスタンスをリリースして削除します。詳細については、「有効期限切れまたは支払い遅延」をご参照ください。
事前チェックに関する問題
Redis のエビクションポリシーチェック項目でアラートが生成される理由
ターゲットデータベースのデータエビクションポリシー (maxmemory-policy) が noeviction 以外の値に設定されている場合、ターゲットのデータがソースのデータと不整合になる可能性があります。データエビクションポリシーの詳細については、「Redis データエビクションポリシーの概要」をご参照ください。
増分データ移行中にバイナリロギング関連の事前チェック項目が失敗した場合の対処方法
ソースデータベースのバイナリログが正しく機能しているかどうかを確認できます。詳細については、「ソースデータベースのバイナリロギングチェック」をご参照ください。
データベース接続に関する問題
ソースデータベースへの接続が失敗した場合の対処方法
ソースデータベースの情報と設定が正しいかどうかを確認できます。詳細については、「ソースデータベースの接続性チェック」をご参照ください。
ターゲットデータベースへの接続が失敗した場合の対処方法
ターゲットデータベースの情報と設定が正しいかどうかを確認できます。詳細については、「ターゲットデータベースの接続性チェック」をご参照ください。
ソースまたはターゲットインスタンスが DTS でサポートされていないリージョンにあり、データ移行と同期を実行したい場合の対処方法
データ移行タスクの場合、RDS MySQL インスタンスなどのデータベースインスタンスのパブリックエンドポイントをリクエストし、パブリック IP アドレス 接続タイプを使用できます。これには、インスタンスに DTS がサポートするリージョンを選択し、そのリージョンの DTS サーバーの CIDR ブロックをインスタンスのホワイトリストに追加する必要があります。ホワイトリストに追加する IP アドレスについては、「DTS サーバーの CIDR ブロックを IP ホワイトリストに追加する」をご参照ください。
DTS はデータベースインスタンスの パブリック IP アドレス 接続タイプをサポートしていないため、これらのリージョンでのデータ同期はサポートしていません。
DTS がソースまたはターゲットインスタンスのドメイン名スイッチを検出するまでにかかる時間
DTS は 10 分以内にドメイン名バインディングの切り替えを検出し、DTS タスクをドメイン名にバインドされた新しい IP アドレスに自動的に切り替えます。ドメイン名の切り替え中は、古いインスタンスと新しいインスタンス間のバイナリロギングレプリケーション関係が 10 分以上維持されていることを確認してください。
データ同期に関する問題
DTS が同期をサポートするデータベースインスタンス
DTS は、リレーショナルデータベース管理システム (RDBMS)、NoSQL データベース、オンライン分析処理 (OLAP) データベースなど、さまざまなデータソース間のデータ同期をサポートしています。サポートされているデータベースインスタンスについては、「データ同期ソリューションの概要」をご参照ください。
データ移行とデータ同期の違い
次の表に、データ移行とデータ同期の違いを示します。
DTS インスタンスを設定する際に、アクセス方法 が Alibaba Cloud インスタンス に設定されていない場合、データベースインスタンスは自己管理データベースとして分類されます。自己管理データベースには、サードパーティクラウドのデータベースインスタンス、オンプレミスサーバーにデプロイされたデータベース、ECS インスタンスにデプロイされたデータベースが含まれます。
項目 | データ移行 | データ同期 |
シナリオ | 主に、オンプレミスデータベース、ECS インスタンス上の自己管理データベース、またはサードパーティのクラウドデータベースを Alibaba Cloud データベースに移行するなど、クラウド移行に使用されます。 | 主に 2 つのデータソース間のリアルタイムデータ同期に使用されます。アクティブ地理的冗長性、データディザスタリカバリ、越境データ同期、クエリとレポートのオフロード、クラウドビジネスインテリジェンス (BI)、リアルタイムデータウェアハウスなどのシナリオに適しています。 |
サポートされているデータベース | 詳細については、「データ移行ソリューションの概要」をご参照ください。 説明 データ同期がサポートしていない一部のデータベースについては、データ移行を使用してデータ同期を実現できます。例としては、単一ノードの MongoDB データベースや OceanBase (MySQL モード) データベースなどがあります。 | 詳細については、「データ同期ソリューションの概要」をご参照ください。 |
サポートされているデータベースのデプロイ場所 (接続タイプ) |
|
説明 データ同期は内部ネットワーク伝送に基づいており、ネットワーク遅延が低く抑えられます。 |
機能の違い |
|
|
課金方法 | 従量課金のみをサポートします。 | 従量課金とサブスクリプションをサポートします。 |
有料サービスですか。 | はい、ただし、増分移行タスクを含む移行インスタンスに対してのみ料金が発生します。 | はい。同期インスタンスにはデフォルトで増分同期タスクが含まれており、常に料金が発生します。 |
課金ルール | 増分データ移行が実行中の場合にのみ課金されます。増分データ移行が一時停止されている場合は課金されません。スキーマ移行または完全データ移行には課金されません。 |
|
データ同期の仕組み
データ同期の仕組みについては、「サービスアーキテクチャと機能」をご参照ください。
同期遅延の計算方法
同期遅延は、ターゲットデータベースに同期された最新データのタイムスタンプと、ソースデータベースの現在のタイムスタンプとのミリ秒単位の時間差です。
通常の遅延は 1,000 ミリ秒以内です。
データ同期タスクの同期オブジェクトを変更できますか。
はい、できます。同期オブジェクトの変更方法については、「同期オブジェクトの追加」および「同期オブジェクトの削除」をご参照ください。
データ同期タスクに新しいテーブルを追加できますか。
はい、できます。新しいテーブルの追加方法については、「同期オブジェクトの追加」をご参照ください。
実行中の同期タスクのテーブルやフィールドなどの同期オブジェクトを変更する方法
タスクの完全同期フェーズが完了し、増分データ同期フェーズが開始された後に、同期オブジェクトを変更できます。同期オブジェクトの変更方法については、「同期オブジェクトの追加」および「同期オブジェクトの削除」をご参照ください。
同期タスクを一時停止し、しばらくしてから再開すると、データの不整合が発生しますか。
同期タスクが一時停止中にソースデータベースが変更されると、ソースデータベースとターゲットデータベース間でデータの不整合が発生する可能性があります。同期タスクを再開し、増分データがターゲットデータベースに同期されると、ターゲットデータベースのデータはソースデータベースのデータと一致するようになります。
増分同期タスクのソースデータベースからデータを削除すると、ターゲットデータベースの同期されたデータも削除されますか。
増分同期タスクで同期する DML 操作に delete が含まれていない場合、ターゲットデータベースのデータは削除されません。含まれている場合は、ターゲットデータベースの同期されたデータも削除されます。
Redis インスタンス間の同期中に、ターゲット Redis インスタンスのデータは上書きされますか。
はい、同じキーを持つデータは上書きされます。DTS は事前チェックフェーズでターゲットをチェックします。ターゲットが空でない場合、エラーが報告されます。
同期タスクで一部のフィールドやデータをフィルタリングできますか。
はい、できます。マッピング機能を使用して、同期する必要のない列をフィルタリングし、SQL WHERE 条件を指定して同期するデータをフィルタリングできます。詳細については、「一部の列を同期または移行する」および「SQL 条件を使用してデータをフィルタリングする」をご参照ください。
同期タスクを移行タスクに変換できますか。
いいえ、できません。異なるタイプのタスクを相互に変換することはできません。
スキーマを同期せずにデータのみを同期できますか。
はい、できます。同期タスクを設定する際に、スキーマ同期 を選択しないでください。
データ同期インスタンスのソースとターゲット間でデータが不整合になる考えられる原因
データ不整合の考えられる原因は次のとおりです。
タスクを設定する際にターゲットのデータをクリアしなかったため、ターゲットに既存データが含まれている。
タスクを設定する際に、完全同期ではなく増分同期のみを選択した。
タスクを設定する際に、増分同期ではなく完全同期のみを選択し、タスク完了後にソースデータが変更された。
DTS タスク以外のソースからターゲットにデータが書き込まれた。
増分書き込みに遅延があり、すべての増分データがターゲットに書き込まれていない。
データ同期タスクで、ターゲットデータベース内のソースデータベースの名前を変更できますか。
はい、できます。ターゲットデータベース内のソースデータベースの名前を変更する方法については、「ターゲットインスタンスでの同期オブジェクトの名前の設定」をご参照ください。
DML または DDL 操作のリアルタイム同期はサポートされていますか。
はい。リレーショナルデータのデータ同期は、DML (INSERT、UPDATE、DELETE) および DDL (CREATE、DROP、ALTER、RENAME、TRUNCATE) 操作をサポートしています。
サポートされている DML または DDL 操作はシナリオによって異なります。「データ同期ソリューションの概要」でビジネスニーズに合ったリンクを選択し、特定のリンク設定ドキュメントでサポートされている DML または DDL 操作を確認してください。
読み取り専用インスタンスを同期タスクのソースインスタンスとして使用できますか。
デフォルトでは、同期タスクには増分データ同期が含まれます。これにより、次の 2 つのシナリオが発生します。
インスタンスが ApsaraDB RDS for MySQL 5.7 または 8.0 インスタンスなど、トランザクションログを記録する読み取り専用インスタンスである場合、ソースインスタンスとして使用できます。
インスタンスが ApsaraDB RDS for MySQL 5.6 インスタンスなど、トランザクションログを記録しない読み取り専用インスタンスである場合、ソースインスタンスとして使用できません。
DTS はシャーディングされたデータベースとテーブルのデータ同期をサポートしていますか。
はい、できます。たとえば、MySQL および PolarDB for MySQL から AnalyticDB for MySQL に同期することで、複数のシャーディングされたテーブルをマージできます。
同期タスク完了後、ターゲットインスタンスのデータ量がソースインスタンスより少ない理由
同期中にデータがフィルタリングされた場合、またはソースインスタンスに多くのテーブルフラグメントがある場合、同期完了後のターゲットインスタンスのデータ量はソースインスタンスよりも少なくなる可能性があります。
クロスアカウントデータ同期タスクは双方向同期をサポートしていますか。
はい、ただし現在、ApsaraDB RDS for MySQL インスタンス間、PolarDB for MySQL クラスター間、Tair (Enterprise Edition) インスタンス間、ApsaraDB for MongoDB (ReplicaSet) インスタンス間、または ApsaraDB for MongoDB (シャードクラスター) インスタンス間の双方向同期タスクのみがクロスアカウント双方向同期をサポートしています。
双方向同期インスタンスの逆方向同期は DDL 同期をサポートしていますか。
いいえ、サポートしていません。順方向同期タスク (ソースデータベースからターゲットデータベースへ) のみが DDL 同期をサポートしています。逆方向同期タスク (ターゲットデータベースからソースデータベースへ) は DDL 同期をサポートしておらず、DDL 操作を自動的にフィルタリングします。
現在の逆方向同期タスクの DDL 操作を同期するには、ビジネスで許可されている場合は 双方向同期インスタンスの方向を逆にすることができます。
逆方向同期タスクを手動で設定する必要がありますか。
はい。順方向同期タスクの初期化が完了するまで待ちます (ステータス が 実行中 になるまで)。次に、逆方向同期タスクを見つけて タスクの設定 をクリックします。
順方向同期タスクに遅延がない (遅延が 0 ミリ秒) 後に、逆方向同期タスクを設定することを推奨します。
DTS は越境双方向同期タスクをサポートしていますか。
いいえ、そうではありません。
双方向同期タスクで、一方のデータベースにレコードを追加したときに、もう一方のデータベースに追加されない理由
逆再生タスクが設定されていないため、この問題が発生することがあります。
増分同期タスクが 100% に達しない理由
増分同期タスクは、ソースからターゲットへの変更をリアルタイムで継続的に同期し、自己終了しません。つまり、100% の完了状態はありません。リアルタイム同期が不要になった場合は、DTS コンソールでタスクを終了できます。
増分同期タスクがデータを同期できない理由
DTS インスタンスが増分同期のみに設定されている場合、DTS はタスク開始後に生成された増分データのみを同期します。つまり、タスク開始前に生成されたデータはターゲットデータベースに同期されません。データ整合性を確保するために、タスクを設定する際には 増分データ同期、スキーマ同期、および 完全データ同期 を選択することを推奨します。
RDS データベースからの完全データ同期は、ソース RDS インスタンスのパフォーマンスに影響しますか。
はい、ソースデータベースのクエリパフォーマンスに影響します。次の 3 つの方法のいずれかを使用して、DTS タスクがソースデータベースに与える影響を軽減できます。
ソースデータベースインスタンスの仕様をスペックアップします。
DTS タスクを一時停止し、ソースデータベースの負荷が低いときに再開します。
DTS タスクのレートを下げます。レートの調整方法については、「完全移行レートの調整」をご参照ください。
PolarDB-X 1.0 ソースを持つ同期インスタンスが遅延を表示しない理由
PolarDB-X 1.0 ソースを持つインスタンスの遅延情報は表示されません。これは、インスタンスが分散タスクとして実行され、DTS によって監視されるメトリックがサブタスクにのみ存在するためです。遅延情報を表示するには、インスタンス ID をクリックし、タスク管理 ページの サブタスクの詳細 セクションに移動します。
複数テーブルマージタスクが DTS-071001 エラーを報告する理由
このエラーは、複数テーブルマージタスクの実行中にソースデータベースでオンライン DDL 操作を実行したために発生する可能性があります。これらの操作によりソースデータベースのテーブルスキーマが変更されましたが、ターゲットデータベースで対応する変更を行っていません。
以前のコンソールでタスクを設定する際にホワイトリストの追加が失敗した場合の対処方法
新しいコンソールを使用してタスクを設定できます。
プロセス中にソースデータベースで DDL 操作が実行されたためにデータ同期タスクが失敗した場合の対処方法
ソースデータベースで実行された DDL 操作に基づいて、ターゲットデータベースで DDL 操作を手動で実行し、タスクを再起動します。データ同期中は、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。実行すると、同期は失敗します。DTS データ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行するか、同期オブジェクトを変更して DDL 操作の影響を受けるテーブルを削除できます。同期オブジェクトの削除方法については、「同期オブジェクトの削除」をご参照ください。
プロセス中にターゲットデータベースで DDL 操作が実行されたためにデータ同期タスクが失敗した場合の対処方法
増分同期中にターゲットデータベースのデータベースまたはテーブルが削除され、タスクが異常になった場合は、次の 2 つの解決策のいずれかを使用してタスクを復元できます。
方法 1：タスクを再設定し、失敗の原因となったデータベースまたはテーブルを同期オブジェクトとして選択しない。
方法 2：同期オブジェクトを変更して、失敗の原因となったデータベースまたはテーブルを削除する。詳細については、「同期オブジェクトの削除」をご参照ください。
リリース後に同期タスクを復元できますか。タスクを再設定することでデータ整合性を確保できますか。
リリースされた同期タスクは復元できません。完全データ同期 を選択せずにタスクを再設定すると、元のタスクのリリースから新しいタスクの開始までに追加されたデータはターゲットデータベースに同期されず、データ整合性は保証できません。ビジネスにとってデータの精度が重要な場合は、ターゲットデータベースのデータを削除し、同期タスクを再設定して、タスクのステージ で スキーマ同期 と 完全データ同期 の両方を選択できます。増分データ同期 はデフォルトで選択されています。
DTS 完全同期タスクが長時間進捗しない場合の対処方法
同期するテーブルにプライマリキーがない場合、完全同期は非常に遅くなります。同期を開始する前に、ソースデータベースの同期するテーブルにプライマリキーを追加することを推奨します。
同じ名前のテーブル間でデータを同期する場合、ソーステーブルのデータがターゲットテーブルに存在しない場合にのみ転送されるように設定できますか。
はい。タスクを設定する際に、競合するテーブルの処理モード を エラーを無視して続行 に設定できます。テーブルスキーマが一致し、ソースデータベースのレコードがターゲットデータベースにすでに存在するプライマリキー値を持つ場合、そのレコードは完全同期中に同期されません。
クロスアカウント同期タスクの設定方法
まず、「クロスアカウントタスクのシナリオ」を理解する必要があります。次に、データベースインスタンスが属する Alibaba Cloud アカウントを使用して、「クロス Alibaba Cloud アカウントタスクの RAM 認可を設定する」を実行します。最後に、「クロス Alibaba Cloud アカウントタスクを設定する」を実行します。
DMS LogicDB インスタンスを選択できない場合の対処方法
インスタンスのリージョンが正しいことを確認してください。それでもインスタンスを選択できない場合は、インスタンスが 1 つしかない可能性があります。他のパラメーターの設定を続行できます。
SQL Server ソースを持つ同期タスクは関数の同期をサポートしていますか。
いいえ、サポートしていません。同期オブジェクトの粒度がテーブルに設定されている場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトはターゲットデータベースに同期されません。
データ同期タスクがエラーを報告した場合の対処方法
エラーメッセージに基づいて、「一般的なエラー」で解決策を見つけることができます。
同期タスクのホットスポットマージを有効にする方法
「パラメーター値の変更」を参照して、trans.hot.merge.enable の値を true に変更します。
ソースデータベースにトリガーがある場合の同期方法
同期オブジェクトがデータベース全体であり、データベース内のトリガーがデータベース内のテーブルを更新する場合、ソースデータベースとターゲットデータベース間でデータの不整合が発生する可能性があります。同期操作については、「ソースデータベースにトリガーがある場合の同期または移行ジョブの設定」をご参照ください。
DTS は sys データベースとシステムデータベースの同期をサポートしていますか。
いいえ、サポートしていません。
DTS は MongoDB の admin および local データベースの同期をサポートしていますか。
いいえ、サポートしていません。DTS は、MongoDB の admin および local データベースをソースまたはターゲットとして使用することをサポートしていません。
双方向同期タスクの逆方向タスクはいつ設定できますか。
双方向同期タスクの逆方向タスクは、順方向増分タスクに遅延がなくなった後にのみ設定できます。
PolarDB-X 1.0 がソースの場合、同期タスクのソース PolarDB-X 1.0 はノードスケーリングをサポートしていますか。
いいえ、サポートしていません。ソース PolarDB-X 1.0 がノードスケーリングを行う場合は、タスクを再設定する必要があります。
DTS によって Kafka に同期されたデータが一意であることを保証できますか。
いいえ、できません。Kafka に書き込まれるデータは追加されるため、DTS タスクが再起動されたときや、ソースからログを繰り返しプルしたときに、重複データが存在する可能性があります。DTS はデータのべき等性を保証します。つまり、データは順序付けられ、重複データの最新の値が最後に配置されます。
DTS は RDS for MySQL から AnalyticDB for MySQL へのデータ同期をサポートしていますか。
はい、サポートしています。設定方法については、「RDS for MySQL から AnalyticDB for MySQL 3.0 へのデータ同期」をご参照ください。
Redis インスタンス間の同期タスクで完全同期が表示されない理由
Redis インスタンス間の同期には、完全データ同期と増分データ同期の両方が含まれます。これら 2 つの方法は、まとめて 増分データ同期 として表示されます。
完全同期をスキップできますか。
はい、できます。完全同期をスキップした後、増分同期は続行されますが、エラーが発生する可能性があります。完全同期をスキップしないことを推奨します。
自動同期をスケジュールできますか。
いいえ、DTS は現在、データ同期タスクの開始をスケジューリングすることをサポートしていません。
プロセス中にテーブルの断片化は同期されますか。
いいえ、されません。
MySQL 8.0 から MySQL 5.6 に同期する際の注意点
同期操作を実行する前に、MySQL 5.6 でデータベースを作成する必要があります。互換性を確保するために、ソースとターゲットのデータベースバージョンを一致させるか、下位バージョンから上位バージョンに同期することを推奨します。上位バージョンから下位バージョンに同期すると、データベースの互換性の問題が発生する可能性があります。
ソースデータベースのアカウントをターゲットデータベースに同期できますか。
現在、ApsaraDB RDS for MySQL インスタンス間の同期タスクのみがアカウントの同期をサポートしています。他の同期タスクはサポートしていません。
クロスアカウントの双方向同期タスクを設定できますか。
はい、ただし現在、ApsaraDB RDS for MySQL インスタンス間、PolarDB for MySQL クラスター間、Tair (Enterprise Edition) インスタンス間、ApsaraDB for MongoDB (ReplicaSet) インスタンス間、または ApsaraDB for MongoDB (シャードクラスター) インスタンス間の双方向同期タスクのみがクロスアカウント双方向同期をサポートしています。
Alibaba Cloud アカウント間でデータを複製 設定項目がないタスクについては、CEN を使用してクロスアカウント双方向同期タスクを設定できます。詳細については、「Alibaba Cloud アカウントまたはリージョン間でデータベースリソースにアクセスする」をご参照ください。
Message Queue for Apache Kafka がターゲットの場合のパラメーター設定方法
必要に応じてパラメーターを設定できます。一部の特殊なパラメーターの設定方法については、「Message Queue for Apache Kafka インスタンスのパラメーターを設定する」をご参照ください。
DTS を使用して Redis データを同期または移行する際に ERR invalid DB index エラーを解決する方法
原因：ERR invalid DB index エラーは、ターゲットデータベースが SELECT DB 操作を実行するときに発生します。これは通常、ターゲットデータベースの databases の数が不十分なために発生します。ターゲットデータベースがプロキシを使用している場合は、プロキシが databases の数の制限を解除できるかどうかを確認してください。
解決策：ターゲットデータベースの databases 設定を変更します。ソースデータベースに合わせて数を増やし、DTS タスクを再起動します。次のコマンドを実行して、ターゲットデータベースの databases 設定をクエリできます。
CONFIG GET databases;SQL Server データを AnalyticDB for PostgreSQL に同期または移行する際の IDENTIFIER CLUSTERED エラーの解決方法
原因：SQL Server データを AnalyticDB for PostgreSQL に同期または移行する際に、CREATE CLUSTERED INDEX コマンドがサポートされていないため、タスクが失敗します。
解決策：遅延期間中に他の DDL コマンドがないことを確認した後、インスタンスパラメーター sink.ignore.failed.ddl を true に変更して、すべての DDL 実行をフィルタリングします。増分同期または移行オフセットが進んだ後、sink.ignore.failed.ddl を false に戻します。
Redis の同期または移行タスクにおいて、ターゲットデータベースのキーの有効期限を延長することに実用的な効果はありますか。
完全データ同期中にキーが期限切れになるのを防ぐために、ターゲットデータベースのキーの有効期限を延長できます。増分同期または移行を含む DTS タスクの場合、ソースデータベースのキーが期限切れになって削除されると、ターゲットデータベースの対応するキーも解放されます。
ターゲットデータベースのキーに延長された有効期限を設定した後、ソースデータベースのキーが期限切れになった場合、ターゲットデータベースのキーはすぐに解放されますか。
ターゲットデータベースのキーは、有効期限が切れても必ずしもすぐに解放されるわけではありません。ソースデータベースの対応するキーが期限切れになってクリアされた場合にのみ、すぐに解放されます。
たとえば、ソースデータベースのキーが 5 秒で期限切れになるように設定されていても、ターゲットデータベースのキーの有効期限が 30 秒である場合、ソースキーが期限切れになるとターゲットデータベースのキーは削除されます。ソースデータベースのキーが期限切れになると、システムは追加専用ファイル (AOF) に削除操作を追加します。このリクエストは、ターゲットデータベースに同期されて実行されます。
DTS を使用して SelectDB にデータを同期する際の column_name[xxx], the length of input string is too long than vec schema エラーの解決方法
詳細なエラーメッセージ：
Reason: The input string for column_name[xxx] is longer than the length specified in the vector schema. First 32 bytes of the input string: [01a954b4-xxx-xxx-xxx-95b675b9]. Schema length: 2147483643. Limit length: 1048576. Actual length: 7241898. Source line: [].原因：ソースの xxx フィールドの増分データのサイズが、対応するターゲットフィールドの長さ制限を超えています。
解決策：フィールドが
STRING型の場合、SelectDB コンソールで string_type_length_soft_limit_bytes パラメーターを増やすことができます。値はactual length(7241898) より大きい必要があります。
DTS を使用して SelectDB にデータを同期する際の column(xxx) values is null while columns is not nullable. エラーの解決方法
詳細なエラーメッセージ：
Reason: column(xxx) values is null while columns is not nullable. src line [ xxx ];原因：ターゲットの xxx フィールドは
NOT NULLですが、NULL値が書き込まれています。説明一般的なシナリオ：ソースの日付形式に
0000-0000-0000などの無効なデータが含まれているため、DTS はそれを自動的にNULL値に変換し、エラーをトリガーします。解決策：
ターゲットのフィールドタイプを変更して、NULL 値を許可します。
同期オブジェクトを変更します。問題のあるテーブルを削除し、ソースデータを修正してから、ターゲットのテーブルを削除します。次に、同期オブジェクトを再度変更してテーブルを再度追加し、最後に完全同期と増分同期を再実行します。
データ移行に関する問題
データ移行タスクを実行した後、ソースデータベースのデータはまだ存在しますか。
DTS は、ソースデータベースからターゲットデータベースにデータをコピーすることでデータ移行と同期を実行し、ソースには影響しません。
DTS が移行をサポートするデータベースインスタンス
DTS は、RDBMS、NoSQL データベース、OLAP データベースなど、さまざまなデータソース間のデータ移行をサポートしています。サポートされている移行インスタンスについては、「データ移行ソリューションの概要」をご参照ください。
データ移行の仕組み
データ移行の仕組みについては、「サービスアーキテクチャと機能」をご参照ください。
データ移行タスクの移行オブジェクトを変更できますか。
いいえ、できません。
データ移行タスクに新しいテーブルを追加できますか。
いいえ、できません。
実行中の移行タスクのテーブルやフィールドなどの移行オブジェクトを変更する方法
移行タスクは、移行オブジェクトの変更をサポートしていません。
移行タスクを一時停止し、しばらくしてから再開すると、データの不整合が発生しますか。
移行タスクが一時停止中にソースデータベースが変更されると、ソースデータベースとターゲットデータベース間でデータの不整合が発生する可能性があります。移行タスクを再開し、増分データがターゲットデータベースに移行されると、ターゲットデータベースのデータはソースデータベースのデータと一致するようになります。
移行タスクを同期タスクに変換できますか。
いいえ、できません。異なるタイプのタスクを相互に変換することはできません。
スキーマを移行せずにデータのみを移行できますか。
はい、できます。移行タスクを設定する際に、スキーマ移行 を選択しないでください。
データ移行インスタンスのソースとターゲット間でデータが不整合になる考えられる原因
データ不整合の考えられる原因は次のとおりです。
タスクを設定する際にターゲットのデータをクリアしなかったため、ターゲットに既存データが含まれている。
タスクを設定する際に、完全移行ではなく増分移行のみを選択した。
タスクを設定する際に、増分移行ではなく完全移行のみを選択し、タスク完了後にソースデータが変更された。
DTS タスク以外のソースからターゲットにデータが書き込まれた。
増分書き込みに遅延があり、すべての増分データがターゲットに書き込まれていない。
データ移行タスクで、ターゲットデータベース内のソースデータベースの名前を変更できますか。
はい、できます。ターゲットデータベース内のソースデータベースの名前を変更する方法については、「データベース、テーブル、列のマッピング」をご参照ください。
同じインスタンス内でのデータ移行はサポートされていますか。
はい、サポートされています。同じインスタンス内でデータを移行する方法については、「異なるデータベース名間のデータ同期または移行」をご参照ください。
DML または DDL 操作のリアルタイム移行はサポートされていますか。
はい、サポートされています。リレーショナルデータベース間のデータでサポートされている DML 操作は INSERT、UPDATE、DELETE です。サポートされている DDL 操作は CREATE、DROP、ALTER、RENAME、TRUNCATE です。
サポートされている DML または DDL 操作はシナリオによって異なります。「データ移行ソリューションの概要」でビジネスニーズに合ったリンクを選択し、特定のリンク設定ドキュメントでサポートされている DML または DDL 操作を確認してください。
読み取り専用インスタンスを移行タスクのソースインスタンスとして使用できますか。
移行タスクが増分データ移行を必要としない場合は、読み取り専用インスタンスをソースインスタンスとして使用できます。移行タスクが増分データ移行を必要とする場合は、次の 2 つのシナリオがあります。
インスタンスが ApsaraDB RDS for MySQL 5.7 または 8.0 インスタンスなど、トランザクションログを記録する読み取り専用インスタンスである場合、ソースインスタンスとして使用できます。
インスタンスが ApsaraDB RDS for MySQL 5.6 インスタンスなど、トランザクションログを記録しない読み取り専用インスタンスである場合、ソースインスタンスとして使用できません。
DTS はシャーディングされたデータベースとテーブルのデータ移行をサポートしていますか。
はい、サポートしています。たとえば、MySQL および PolarDB for MySQL のシャーディングされたデータベースとテーブルを AnalyticDB for MySQL に移行して、複数のテーブルをマージできます。
移行タスクで一部のフィールドやデータをフィルタリングできますか。
はい、できます。マッピング機能を使用して、移行する必要のない列をフィルタリングし、SQL WHERE 条件を指定して移行するデータをフィルタリングできます。詳細については、「一部の列を同期または移行する」および「移行するデータをフィルタリングする」をご参照ください。
移行タスク完了後、ターゲットインスタンスのデータ量がソースインスタンスより少ない理由
移行中にデータがフィルタリングされた場合、またはソースインスタンスに多くのテーブルフラグメントがある場合、移行完了後のターゲットインスタンスのデータ量はソースインスタンスよりも少なくなる可能性があります。
移行タスクで「完了」の値が合計より大きい理由
表示される合計は推定値です。移行タスクが完了すると、合計は正確な値に調整されます。
データ移行中にターゲットデータベースに追加される increment_trx テーブルの目的
increment_trx テーブルは、DTS 増分移行がターゲットインスタンスに作成するオフセットテーブルです。主に増分移行のオフセットを記録し、異常なタスク再起動後のブレークポイントからの再開の問題を解決するために使用されます。移行プロセス中に削除しないでください。削除すると、移行は失敗します。
データ移行タスクは、完全移行フェーズ中にブレークポイントからの再開をサポートしていますか。
はい、サポートしています。完全移行フェーズ中にタスクを一時停止してから再起動すると、タスクは最初からやり直すのではなく、中断したところから続行されます。
Alibaba Cloud 以外のインスタンスを Alibaba Cloud に移行する方法
Alibaba Cloud 以外のインスタンスを Alibaba Cloud に移行する方法については、「サードパーティクラウドから Alibaba Cloud へのデータ移行」をご参照ください。
オンプレミスの Oracle データベースを PolarDB に移行する方法
オンプレミスの Oracle データベースを PolarDB に移行する方法については、「自己管理 Oracle データベースから PolarDB for PostgreSQL (Oracle 互換) データベースへのデータ移行」をご参照ください。
完全移行フェーズを完了していないデータ移行タスクを一時停止できますか。
はい、できます。
RDS for MySQL から自己管理 MySQL データベースに一部のデータを移行する方法
移行タスクを設定する際に、ソースオブジェクト セクションで移行するオブジェクトを選択するか、[選択済みオブジェクト] セクションで必要に応じてフィルタリングできます。MySQL データベース間の移行操作は類似しています。詳細については、「自己管理 MySQL データベースから ApsaraDB RDS for MySQL インスタンスへのデータ移行」をご参照ください。
同じ Alibaba Cloud アカウント配下の RDS インスタンスの移行方法
DTS は RDS インスタンス間の移行と同期をサポートしています。設定方法については、「データ移行ソリューションの概要」の関連設定ドキュメントをご参照ください。
移行タスク開始後にソースデータベースで IOPS アラートがトリガーされた場合の対処方法と、ソースデータベースビジネスの安定性を確保する方法
DTS タスクの実行中にソースデータベースインスタンスの負荷が高い場合は、次の 3 つの方法のいずれかを使用して、DTS タスクがソースデータベースに与える影響を軽減できます。
ソースデータベースインスタンスの仕様をスペックアップします。
DTS タスクを一時停止し、ソースデータベースの負荷が低いときに再開します。
DTS タスクのレートを下げます。レートの調整方法については、「完全移行レートの調整」をご参照ください。
データ移行タスクで「test」という名前のデータベースを選択できない理由
DTS データ移行はシステムデータベースの移行をサポートしていません。移行には、ビジネスで作成されたデータベースを選択する必要があります。
PolarDB-X 1.0 ソースを持つ移行インスタンスが遅延を表示しない理由
PolarDB-X 1.0 ソースを持つインスタンスの遅延情報は表示されません。これは、インスタンスが分散タスクとして実行され、DTS によって監視されるメトリックがサブタスクにのみ存在するためです。遅延情報を表示するには、インスタンス ID をクリックし、タスク管理 ページの サブタスクの詳細 セクションに移動します。
DTS が MongoDB データベースを移行できない理由
これは、移行するデータベースが「local」または「admin」であるため可能性があります。DTS は、MongoDB の admin および local データベースをソースまたはターゲットとして使用することをサポートしていません。
複数テーブルマージタスクが DTS-071001 エラーを報告する理由
このエラーは、複数テーブルマージタスクの実行中にソースデータベースでオンライン DDL 操作を実行したために発生する可能性があります。これらの操作によりソースデータベースのテーブルスキーマが変更されましたが、ターゲットデータベースで対応する変更を行っていません。
以前のコンソールでタスクを設定する際にホワイトリストの追加が失敗した場合の対処方法
新しいコンソールを使用してタスクを設定できます。
プロセス中にソースデータベースで DDL 操作が実行されたためにデータ移行タスクが失敗した場合の対処方法
ソースデータベースで実行された DDL コンテンツに基づいて、ターゲットで DDL 操作を手動で実行し、タスクを再起動します。データ移行中は、pt-online-schema-change などのツールを使用してソースデータベースの移行オブジェクトに対してオンライン DDL 操作を実行しないでください。実行すると、移行は失敗します。DTS データ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。
プロセス中にターゲットデータベースで DDL 操作が実行されたためにデータ移行タスクが失敗した場合の対処方法
増分移行中にターゲットデータベースのデータベースまたはテーブルが削除され、タスクが異常になった場合は、タスクを再設定し、失敗の原因となったデータベースまたはテーブルを移行オブジェクトとして選択しないようにします。
リリース後に移行タスクを復元できますか。タスクを再設定することでデータ整合性を確保できますか。
リリースされた移行タスクは復元できません。完全データ移行 を選択せずにタスクを再設定すると、タスクのリリース後に追加されたデータはターゲットデータベースに移行されず、データ整合性は保証できません。高いデータ精度が必要な場合は、ターゲットデータベースのデータを削除し、移行タスクを再設定して、タスクのステージ で スキーマ移行、増分データ移行、および 完全データ移行 を選択できます。
DTS 完全移行タスクが長時間進捗しない場合の対処方法
移行するテーブルにプライマリキーがない場合、完全移行は非常に遅くなります。移行を開始する前に、ソースデータベースの移行するテーブルにプライマリキーを追加することを推奨します。
同じ名前のテーブル間でデータを移行する場合、ソーステーブルのデータがターゲットテーブルに存在しない場合にのみ転送されるように設定できますか。
はい、できます。タスクを設定する際に、競合するテーブルの処理モード を エラーを無視して続行 に設定できます。テーブルスキーマが一致する場合、ターゲットデータベースにすでに存在するプライマリキーを持つソースレコードは、完全移行中に移行されません。
クロスアカウント移行タスクの設定方法
まず、「クロスアカウントタスクのシナリオ」を理解する必要があります。次に、データベースインスタンスが属する Alibaba Cloud アカウントを使用して、「クロス Alibaba Cloud アカウントタスクの RAM 認可を設定する」を実行します。最後に、「クロス Alibaba Cloud アカウントタスクを設定する」を実行します。
データ移行タスクがオンプレミスデータベースに接続する方法
オンプレミスデータベースの アクセス方法 を パブリック IP アドレス に設定して、移行タスクを設定します。詳細については、「自己管理 MySQL データベースから ApsaraDB RDS for MySQL インスタンスへのデータ移行」をご参照ください。
データ移行が DTS-31008 エラーで失敗した場合の対処方法
エラーメッセージに基づいて、原因を表示 をクリックするか、「一般的なエラー」をご参照ください。
専用回線経由で自己管理データベースに接続する際にネットワークが切断された場合の対処方法
DTS 関連の IP アドレスホワイトリストが専用回線に正しく設定されているか確認してください。ホワイトリストに追加する IP アドレスのリストについては、「」「DTS サーバーの IP アドレス範囲を自己管理データベースの IP アドレスホワイトリストに追加する」をご参照ください。
SQL Server ソースを持つ移行タスクは関数の移行をサポートしていますか。
いいえ、サポートしていません。移行オブジェクトの粒度がテーブルに設定されている場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトはターゲットデータベースに移行されません。
DTS の完全移行が遅い場合の対処方法
データ移行が完了するまでに時間がかかる場合があります。タスク管理 ページのタスク詳細の 完全データ移行 モジュールで移行の進捗状況を確認できます。
スキーマ移行がエラーを報告した場合の対処方法
インスタンス ID をクリックしてタスク詳細ページに移動します。タスク管理 ページのスキーマ移行モジュールでエラーメッセージを表示し、それに応じてエラーを解決します。一般的なエラーの解決策については、「一般的なエラー」をご参照ください。
スキーマ移行と完全移行は無料ですか。
このサービスは無料です。詳細については、「課金項目」をご参照ください。
Redis インスタンス間のデータ移行タスク中に、ターゲットの zset データは上書きされますか。
はい、ターゲットの zset は上書きされます。ソースと同じキーがターゲットにすでに存在する場合、DTS はまずターゲットの対応するキーの zset を削除し、次にソース zset コレクションの各オブジェクトをターゲットに zadd します。
完全移行がソースデータベースに与える影響
DTS の完全移行プロセスは、まずデータをセグメント化し、次にセグメント内のデータを読み書きします。ソースデータベースの場合、データセグメント化プロセス中にソースデータベースの IOPS が増加します。セグメント内のデータを読み取るプロセス中に、ソースデータベースの IOPS、CachePool、およびアウトバウンド帯域幅がある程度影響を受けます。DTS の実務経験に基づくと、これらの影響は無視できます。
PolarDB-X 1.0 がソースの場合、移行タスクのソース PolarDB-X 1.0 はノードスケーリングをサポートしていますか。
いいえ、サポートしていません。ソース PolarDB-X 1.0 がノードスケーリングを行う場合は、タスクを再設定する必要があります。
DTS によって Kafka に移行されたデータが一意であることを保証できますか。
いいえ、できません。Kafka に書き込まれるデータは追加されるため、DTS タスクが再起動されたときや、ソースからログを繰り返しプルしたときに、重複データが存在する可能性があります。DTS はデータのべき等性を保証します。つまり、データは順序付けられ、重複データの最新の値が最後に配置されます。
最初に完全移行タスクを設定し、次に増分データ移行タスクを設定すると、データの不整合が発生しますか。
はい、データの不整合が発生する可能性があります。増分データ移行タスクが個別に設定されている場合、タスクは開始後にのみデータの移行を開始します。増分移行タスクが開始される前にソースインスタンスで生成された増分データは、ターゲットインスタンスに同期されません。ゼロダウンタイム移行を実行するには、タスクを設定する際に移行タイプとしてスキーマ移行、完全データ移行、および増分データ移行を選択することを推奨します。
増分移行タスクを設定する際にスキーマ移行を選択する必要がありますか。
スキーマ移行は、データ移行が開始される前に移行オブジェクトの定義をターゲットインスタンスに移行するプロセスです。たとえば、テーブル A のテーブル定義をターゲットインスタンスに移行します。増分移行を実行するには、データ整合性を確保するためにスキーマ移行、完全データ移行、および増分データ移行を選択することを推奨します。
自己管理データベースから RDS への移行中に、RDS が使用するストレージ容量がソースデータベースより大きい理由
DTS は論理的な移行を実行するため、移行するデータを SQL にカプセル化し、ターゲット RDS インスタンスに移行します。このとき、ターゲット RDS インスタンスでバイナリログデータが生成されるため、移行プロセス中に RDS が使用するストレージ容量がソースデータベースより大きくなる可能性があります。
DTS は VPC 内の MongoDB の移行をサポートしていますか。
はい、サポートしています。DTS は現在、VPC 内の ApsaraDB for MongoDB を移行のソースデータベースとして使用することをサポートしています。
データ移行中にソースデータベースが変更された場合、移行されたデータはどうなりますか。
移行タスクがスキーマ移行、完全移行、および増分移行で設定されている場合、移行中にソースデータベースで発生したデータ変更はすべて DTS によってターゲットデータベースに移行されます。
完了した移行タスクをリリースすると、移行されたデータベースの使用に影響しますか。
いいえ。移行タスクは、ステータス が 完了 になったときにのみ安全にリリースできます。
DTS は MongoDB の増分移行をサポートしていますか。
はい、サポートしています。関連する設定例については、「データ移行ソリューションの概要」をご参照ください。
移行タスクのソースとして、RDS インスタンスとパブリック IP アドレスを持つ自己管理データベースインスタンスを使用する場合の違い
移行タスクを設定する際に RDS インスタンスを選択すると、DTS 移行タスクは RDS インスタンスの DNS 変更やネットワークタイプスイッチなどの変更に適応でき、リンクの信頼性を効果的に確保できます。
DTS は VPC 内の ECS インスタンス上の自己管理データベースを RDS インスタンスに移行することをサポートしていますか。
はい、サポートしています。
ソース ECS インスタンスとターゲット RDS インスタンスが同じリージョンにある場合、DTS は VPC 内の ECS インスタンス上の自己管理データベースに直接アクセスできます。
ソース ECS インスタンスとターゲット RDS インスタンスが異なるリージョンにある場合、ECS インスタンスに EIP をマウントする必要があります。移行タスクを設定する際に、ソースインスタンスとして ECS インスタンスを選択すると、DTS は ECS インスタンスの EIP を自動的に使用して ECS インスタンス上のデータベースにアクセスします。
DTS は移行中にテーブルをロックしますか。ソースデータベースに影響しますか。
DTS は、完全データ移行および増分データ移行中にソースデータベースのテーブルをロックしません。完全データ移行および増分データ移行中、移行元のデータテーブルは通常どおり読み書きアクセスできます。
DTS が RDS 移行を実行するとき、プライマリ RDS データベースとセカンダリ RDS データベースのどちらからデータを取得しますか。
DTS がデータ移行を実行するとき、プライマリ RDS データベースからデータをプルします。
自動移行をスケジュールできますか。
いいえ、DTS は現在、データ移行タスクの開始をスケジューリングすることをサポートしていません。
DTS は VPC モードの RDS インスタンスのデータ移行をサポートしていますか。
はい、移行タスクを設定する際に RDS インスタンス ID を指定できます。
DTS が同じアカウントまたはクロスアカウントで移行または同期を実行する場合、ECS および RDS インスタンスに内部ネットワークとパブリックネットワークのどちらを使用しますか。トラフィック料金はかかりますか。
DTS が同期または移行タスクに使用するネットワーク (内部またはパブリック) は、タスクがクロスアカウントであるかどうかとは関係ありません。トラフィック料金が課金されるかどうかは、タスクタイプによって異なります。
使用するネットワーク
移行タスク：同じリージョン内でデータ移行が実行される場合、DTS は内部ネットワークを使用して ECS および RDS インスタンスに接続します。リージョンをまたいで移行が実行される場合、DTS はパブリックネットワークを使用してソースインスタンス (ECS または RDS) に接続し、内部ネットワークを使用してターゲット RDS インスタンスに接続します。
同期タスク：内部ネットワークを使用します。
トラフィック料金
移行タスクの場合、ターゲットデータベースインスタンスの アクセス方法 が パブリック IP アドレス の場合、パブリックネットワークのアウトバウンドトラフィック料金が課金されます。他のタイプの DTS インスタンスではトラフィック料金は発生しません。
同期タスク：トラフィック料金は課金されません。
DTS を使用した移行後、ソースデータベースのデータは削除されますか。
いいえ、されません。DTS がデータ移行を実行するとき、ソースデータベースからターゲットデータベースにデータをコピーし、ソースデータベースのデータには影響しません。
DTS が RDS インスタンス間でデータ移行を実行するとき、ターゲットデータベースの名前を指定できますか。
はい、できます。RDS インスタンス間でデータ移行を実行するとき、DTS が提供するデータベース名マッピング機能を使用して、ターゲットデータベースの名前を指定できます。詳細については、「異なるデータベース名間のデータ同期または移行」をご参照ください。
DTS 移行タスクのソースが ECS インスタンスに接続できない場合の対処方法
ECS インスタンスにパブリック IP アドレスが公開されていない可能性があります。EIP を ECS インスタンスにバインドして、再試行してください。EIP のバインド方法については、「EIP」をご参照ください。
Redis インスタンス間の移行タスクで完全移行が表示されない理由
増分データ移行 を使用して Redis インスタンス間でデータを移行できます。これには、完全データ移行と増分データ移行が組み合わされています。
完全移行をスキップできますか。
はい、できます。完全移行をスキップした後、増分移行は続行されますが、エラーが発生する可能性があります。完全移行をスキップしないことを推奨します。
Redis のクラスター版は、パブリック IP アドレスでの DTS への接続をサポートしていますか。
いいえ、サポートしていません。現在、スタンドアロン版の Redis のみが、パブリック IP アドレスを持つ DTS 移行インスタンスへの接続をサポートしています。
MySQL 8.0 から MySQL 5.6 に移行する際の注意点
移行操作を実行する前に、MySQL 5.6 でデータベースを作成する必要があります。互換性を確保するために、ソースとターゲットのデータベースバージョンを一致させるか、下位バージョンから上位バージョンに移行することを推奨します。上位バージョンから下位バージョンに移行すると、データベースの互換性の問題が発生する可能性があります。
ソースデータベースのアカウントをターゲットデータベースに移行できますか。
現在、ApsaraDB RDS for MySQL インスタンス間の移行タスクのみがアカウントの移行をサポートしています。他の移行タスクはサポートしていません。
Message Queue for Apache Kafka がターゲットの場合のパラメーター設定方法
必要に応じてパラメーターを設定できます。一部の特殊なパラメーターの設定方法については、「Message Queue for Apache Kafka インスタンスのパラメーターを設定する」をご参照ください。
スケジュールされた完全移行の実行方法
データ統合機能のスケジューリングポリシーを使用して、ソースデータベースからターゲットデータベースにスキーマと既存データを定期的に移行できます。詳細については、「ApsaraDB RDS for MySQL インスタンス間のデータ統合タスクの設定」をご参照ください。
ECS インスタンス上の自己管理 SQL Server をオンプレミスの自己管理 SQL Server に移行することはサポートされていますか。
はい、サポートされています。オンプレミスの自己管理 SQL Server を Alibaba Cloud に接続する必要があります。詳細については、「準備の概要」をご参照ください。
他のクラウドからの PostgreSQL データベースの移行はサポートされていますか。
はい、別のクラウドの PostgreSQL データベースがパブリックネットワーク経由で DTS にアクセスできる場合、DTS によるデータ移行がサポートされます。
PostgreSQL のバージョンが 10.0 より前の場合、増分移行はサポートされていません。
データサブスクリプションに関する問題
データサブスクリプションの仕組み
データサブスクリプションの詳細については、「サービスアーキテクチャと原則」をご参照ください。
変更追跡タスクの有効期限が切れた後、コンシューマーグループは削除されますか。
DTS 変更追跡タスクの有効期限が切れた後、データコンシューマーグループは 7 日間保持されます。有効期限が切れてから 7 日以内にインスタンスが更新されない場合、インスタンスはリリースされ、対応するコンシューマーグループも削除されます。
読み取り専用インスタンスを追跡タスクのソースインスタンスとして使用できますか。
これは、次の 2 つの状況で発生する可能性があります。
インスタンスが ApsaraDB RDS for MySQL 5.7 または 8.0 インスタンスなど、トランザクションログを記録する読み取り専用インスタンスである場合、ソースインスタンスとして使用できます。
インスタンスが ApsaraDB RDS for MySQL 5.6 インスタンスなど、トランザクションログを記録しない読み取り専用インスタンスである場合、ソースインスタンスとして使用できません。
追跡データの消費方法
詳細については、「サブスクリプションデータの消費」をご参照ください。
変更追跡機能を使用してデータが転送された後、日付データの形式が変更される理由
DTS のデフォルトの日付データストレージ形式は YYYY:MM:DD です。YYYY-MM-DD は表示形式ですが、実際のストレージ形式は YYYY:MM:DD です。したがって、転送されるデータの形式に関係なく、最終的にはデフォルトの形式に変換されます。
追跡タスクのトラブルシューティング方法
追跡タスクのトラブルシューティング方法については、「追跡タスクのトラブルシューティング」をご参照ください。
SDK が突然一時停止し、データを正常にダウンロードしている間にデータを追跡できなくなった場合の対処方法
SDK コードで ackAsConsumed インターフェイスが呼び出されてコンシューマーオフセットが報告されているかどうかを確認してください。ackAsConsumed が呼び出されてオフセットが報告されない場合、SDK 内部に設定された Record キャッシュスペースのデータは削除されません。キャッシュが完全に占有されると、新しいデータをプルできなくなり、SDK が一時停止してデータを追跡できなくなります。
再実行後に SDK がデータを正常に追跡できない場合の対処方法
SDK を開始する前に、コンシューマーオフセットを変更してデータ範囲内に収まるようにします。コンシューマーオフセットの変更方法については、「コンシューマーオフセットの保存とクエリ」をご参照ください。
クライアントがデータ消費の時点を指定する方法
追跡データを消費するときに、initCheckpoint パラメーターを入力して時点を指定できます。詳細については、「SDK サンプルコードを使用して追跡データを消費する」をご参照ください。
DTS 追跡タスクにバックログがある場合にオフセットをリセットする方法
SDK クライアントの使用モードに従って、DTSConsumerAssignDemo.java や DTSConsumerSubscribeDemo.java などの対応するコードファイルを開きます。
説明詳細については、「SDK サンプルコードを使用して追跡データを消費する」をご参照ください。
追跡タスクリストの データ範囲 列で、ターゲット追跡インスタンスの変更可能なオフセット範囲を表示できます。
必要に応じて新しいコンシューマーオフセットを選択し、UNIX タイムスタンプに変換します。
変換された新しいコンシューマーオフセットを使用して、コードファイル内の古いコンシューマーオフセット (initCheckpoint パラメーター) を置き換えます。
クライアントを再実行します。
追跡タスクの VPC アドレスを使用してクライアントが接続できない場合の対処方法
クライアントが配置されているマシンが、追跡タスクの設定時に指定された VPC にない可能性があります (たとえば、クライアント VPC が変更された)。タスクを再設定する必要があります。
コンソールのコンシューマーオフセットがデータ範囲の最大値より大きい理由
これは、追跡チャネルのデータ範囲の更新頻度が 1 分であるのに対し、コンシューマーオフセットの更新頻度は 10 秒であるためです。したがって、リアルタイムで消費する場合、コンシューマーオフセットの値が追跡チャネルのデータ範囲の最大値より大きくなる可能性があります。
DTS が SDK によって追跡されたデータが完全なトランザクションであることを保証する方法
DTS は、提供されたコンシューマーオフセットに対応する完全なトランザクションを検索します。サーバー側は、トランザクション全体の BEGIN ステートメントから下流にデータを配信するため、完全なトランザクションコンテンツを受信できます。
データが正常に消費されていることを確認する方法
データが正常に消費されている場合、Data Transmission Service コンソールのコンシューマーオフセットは正常に前進します。
変更追跡 SDK の usePublicIp=true の意味
変更追跡 SDK の設定で、usePublicIp=true は、SDK がパブリックネットワーク経由で DTS 追跡チャネルにアクセスすることを意味します。
変更追跡タスクのプライマリ RDS データベースが切り替えられたり再起動されたりすると、ビジネスに影響はありますか。
ApsaraDB RDS for MySQL、ApsaraDB RDS for PostgreSQL、PolarDB for MySQL、PolarDB for PostgreSQL、または PolarDB-X 1.0 (ストレージタイプは RDS for MySQL) インスタンスでプライマリ/セカンダリ スイッチオーバーまたは再起動が発生した場合、DTS は適応的に切り替え、ビジネスに影響はありません。
RDS は、ローカルサーバーへの自動バイナリログダウンロードツールを提供していますか。
DTS の変更追跡機能は、RDS バイナリログのリアルタイム追跡をサポートしています。DTS 変更追跡サービスをアクティブ化し、DTS SDK を使用して RDS バイナリログデータを追跡し、リアルタイムでローカルサーバーに同期できます。
変更追跡のリアルタイム増分データは、新しいデータのみを指しますか、それとも変更されたデータも含まれますか。
DTS 変更追跡で追跡できる増分データには、すべての追加、削除、変更、およびスキーマ変更 (DDL) が含まれます。
変更追跡タスクのコンシューマー側でレコードが ACK されない場合、再起動後に SDK が重複データを受信する理由
メッセージが SDK によって ACK されない場合、サーバー側はバッファー内のすべてのメッセージのプッシュを完了します。プッシュが完了すると、SDK はメッセージを受信できなくなります。このとき、サーバー側に保存されているコンシューマーオフセットは、ACK されなかったメッセージの前の最後のメッセージのオフセットです。SDK が再起動すると、メッセージが失われないようにするために、サーバー側は ACK されなかったメッセージの前のメッセージに対応するオフセットからデータを再プッシュします。したがって、SDK はいくつかの重複メッセージを受信します。
変更追跡コンシューマーオフセットはどのくらいの頻度で更新されますか。また、再起動時に SDK が重複データを受信することがあるのはなぜですか。
変更追跡 SDK が各メッセージを消費した後、ackAsConsumed を呼び出してサーバー側に ACK を返信する必要があります。ACK を受信した後、サーバー側はメモリ内のコンシューマーオフセットを更新し、10 秒ごとにコンシューマーオフセットを永続化します。最新の ACK が永続化される前に SDK が再起動されると、サーバー側はメッセージが失われないようにするために、最後に永続化されたコンシューマーオフセットからメッセージのプッシュを開始します。この場合、SDK は重複メッセージを受信します。
1 つの変更追跡インスタンスで複数の RDS インスタンスを追跡できますか。
いいえ、できません。現在、1 つの変更追跡インスタンスは 1 つの RDS インスタンスのみを追跡できます。
変更追跡インスタンスでデータの不整合は発生しますか。
いいえ、発生しません。変更追跡タスクは、ソースデータベースからの変更のみを取得し、データの不整合は発生しません。クライアントによって消費されたデータが期待と異なる場合は、自分でトラブルシューティングする必要があります。
サブスクリプションデータを消費しているときに UserRecordGenerator が表示された場合の対処方法
追跡データを消費しているときに、UserRecordGenerator: haven't receive records from generator for 5s などのメッセージが表示された場合は、コンシューマーオフセットが増分データ取り込みモジュールのオフセット範囲内にあることを確認し、コンシューマー側が正常に実行されていることを確認する必要があります。
1 つのトピックに複数のパーティションを作成できますか。
いいえ、できません。メッセージのグローバルな順序を保証するために、DTS の各追跡トピックには 1 つのパーティションしかなく、パーティション 0 に固定的に割り当てられています。
変更追跡 SDK は Go をサポートしていますか。
サポートされています。サンプルコードについては、dts-subscribe-demo リポジトリをご参照ください。
変更追跡 SDK は Python をサポートしていますか。
はい、あります。サンプルコードについては、dts-subscribe-demo をご参照ください。
flink-dts-connector は、追跡データのマルチスレッド同時消費をサポートしていますか。
いいえ、サポートしていません。
データ検証に関する問題
データ検証タスクでデータが不整合になる理由
一般的な原因は次のとおりです。
移行または同期タスクに遅延がある。
デフォルト値を持つ列がソースデータベースに追加され、タスクに遅延がある。
DTS 以外のソースからターゲットデータベースにデータが書き込まれる。
複数テーブルマージ機能が有効になっているタスクのソースデータベースで DDL 操作が実行された。
移行または同期タスクで、データベース、テーブル、および列名のマッピング機能が使用された。
スキーマ検証タスクで isRelHasoids の違いが報告される理由
PostgreSQL 12 より前のバージョンでは、テーブルを作成する際に WITH OIDS を指定することで、グローバルに一意なオブジェクト識別子 (OID) フィールドを追加できます。構造検証タスクのソースに WITH OIDS で作成されたテーブルがあり、かつ送信先が WITH OIDS をサポートしない PostgreSQL の以降のバージョンである場合、`isRelHasoids` の差異が検出されます。
スキーマ検証タスクによって報告された isRelHasoids の違いに注意する必要がありますか。
いいえ、必要ありません。
DTS は オブジェクト識別子 (OID) フィールドを同期または移行しますか。
オブジェクト識別子 (OID) フィールドは、WITH OIDS を指定することで自動的に生成されます。ターゲットがこのフィールドをサポートしているかどうかに関係なく、DTS はこのデータを同期または移行しません。
テーブルに オブジェクト識別子 (OID) フィールドがあるかどうかを確認する方法
コマンドで、<table_name> をクエリするテーブルの名前に置き換えます。
SQL コマンド：
SELECT relname AS table_name, relhasoids AS has_oids FROM pg_class WHERE relname = '<table_name>' AND relkind = 'r';クライアントコマンド：
\d+ <table_name>
その他の問題
データ同期または移行タスクの実行中にターゲットデータベースのデータを変更した場合の影響
ターゲットデータベースのデータを変更すると、DTS タスクが失敗する可能性があります。データ移行または同期中に、ターゲットデータベースで移行または同期するオブジェクトに対して操作を実行すると、プライマリキー競合、更新レコードなし、またはその他の状況が発生し、最終的に DTS タスクが失敗する可能性があります。ただし、ターゲットインスタンスにテーブルを作成して書き込むなど、DTS タスクを中断しない操作は実行できます。このテーブルは移行または同期オブジェクトテーブルにないため、DTS タスクが失敗することはありません。
DTS はソースインスタンスのデータベース情報を読み取り、その完全データ、スキーマデータ、および増分データをターゲットインスタンスに移行または同期するため、タスク中にターゲットデータベースで変更されたデータは、ソースデータベースから移行または同期されたデータによって上書きされる可能性があります。
データ同期または移行タスクの実行中に、ソースデータベースとターゲットデータベースの両方に同時にデータを書き込むことはできますか。
はい、できますが、DTS インスタンスの実行中に DTS 以外の他のデータソースからターゲットデータベースにデータが書き込まれると、ターゲットデータベースのデータまたは DTS インスタンスが異常になる可能性があります。
DTS インスタンスの実行中にソースまたはターゲットデータベースのパスワードを変更するとどうなりますか。
DTS インスタンスはエラーを報告し、中断されます。インスタンス ID をクリックしてインスタンスの詳細を表示し、基本情報 タブでソースまたはターゲットアカウントのパスワードを変更できます。次に、タスク管理 タブに移動し、基本情報 セクションでエラーを報告したモジュールを再起動します。
一部のソースまたはターゲットデータベースにパブリック IP 接続タイプがない理由
これは、ソースまたはターゲットデータベースの接続タイプ、タスクタイプ、およびデータベースタイプに関連しています。たとえば、MySQL データベースタイプのソースの場合、移行および追跡タスクはパブリック IP アドレスを使用して接続することを選択できますが、同期タスクはパブリック IP 接続をサポートしていません。
クロスアカウントのデータ移行またはデータ同期はサポートされていますか。
はい、サポートされています。設定方法については、「クロス Alibaba Cloud アカウントタスクの設定」をご参照ください。
ソースデータベースとターゲットデータベースは同じデータベースインスタンスにできますか。
はい、できます。ソースデータベースとターゲットデータベースが同じデータベースインスタンスである場合は、マッピング機能を使用してデータを分離および区別することを推奨します。そうしないと、DTS インスタンスが失敗したり、データが失われたりする可能性があります。詳細については、「データベース、テーブル、列のマッピング」をご参照ください。
Redis をターゲットとするタスクで「OOM command not allowed when used memory > 'maxmemory'」エラーが報告される理由
これは、ターゲット Redis インスタンスのストレージ容量が不足しているため可能性があります。ターゲット Redis インスタンスのアーキテクチャタイプがクラスターの場合、シャードがメモリ制限に達している可能性もあります。ターゲットインスタンスの仕様をスペックアップする必要があります。
AliyunDTSRolePolicy アクセスポリシーとは何ですか。また、何に使用されますか。
AliyunDTSRolePolicy ポリシーは、現在のアカウントまたはクロスアカウント配下の RDS や ECS などのクラウドリソースにアクセスするために使用されます。データ移行、同期、または追跡タスクを設定する際に、関連するクラウドリソース情報を呼び出すことができます。詳細については、「DTS にクラウドリソースへのアクセス権限を付与する」をご参照ください。
RAM ロール認可の実行方法
初めてコンソールにログインすると、DTS は AliyunDTSDefaultRole ロールを認可するように求めます。コンソールのプロンプトに従って RAM 認可ページに移動して認可を実行できます。詳細については、「DTS にクラウドリソースへのアクセス権限を付与する」をご参照ください。
操作を実行するには、Alibaba Cloud アカウントでコンソールにログインする必要があります。
DTS タスクに入力したアカウントパスワードは変更できますか。
DTS タスクのデータベースアカウントのパスワードを変更できます。インスタンス ID をクリックしてインスタンス詳細ページを開きます。基本情報 タブで、パスワードの変更 をクリックして、ソースまたはターゲットデータベースのパスワードを変更します。
DTS タスクのシステムアカウントのパスワードは変更できません。
MaxCompute テーブルに「_base」サフィックスが付く理由
初期スキーマ同期。
DTS は、ソースデータベースのテーブルのスキーマ定義を MaxCompute に同期します。初期化中に、DTS はテーブル名に
_baseサフィックスを追加します。たとえば、ソーステーブルがcustomerの場合、MaxCompute のテーブルはcustomer_baseになります。初期完全データ同期。
DTS は、ソーステーブルのすべての既存データを MaxCompute の
_baseテーブルに同期します。たとえば、customerテーブルのデータはcustomer_baseテーブルに同期されます。このデータは、後続の増分データ同期のベースラインとして機能します。説明このテーブルは、全量ベースラインテーブルとも呼ばれます。
増分データ同期。
DTS は、MaxCompute に
_logサフィックスを持つ増分データテーブル (customer_logなど) を作成します。次に、ソースデータベースからこのテーブルに増分データをリアルタイムで同期します。説明増分データテーブルのスキーマの詳細については、「増分ログテーブルスキーマ」をご参照ください。
Kafka トピックを取得できない場合の対処方法
現在設定されている Kafka ブローカーにトピック情報がない可能性があります。次のコマンドを実行して、トピックのブローカーディストリビューションを確認できます。
./bin/kafka-topics.sh --describe --zookeeper zk01:2181/kafka --topic topic_nameローカルに MySQL インスタンスを構築して、RDS インスタンスのセカンダリデータベースとして使用できますか。
はい、できます。Data Transmission Service (DTS) のデータ移行機能を使用して、RDS からローカルの自己管理 MySQL インスタンスへのリアルタイムデータ同期を設定し、プライマリ/セカンダリ アーキテクチャを実現できます。
RDS インスタンスから新しく作成した RDS インスタンスにデータをコピーする方法
DTS データ移行機能を使用し、移行タスクの移行タイプとしてスキーマ移行、完全移行、および増分移行を選択できます。設定方法については、「ApsaraDB RDS インスタンス間のデータ移行」をご参照ください。
DTS は、RDS インスタンス内のデータベースをコピーして、データベース名以外は同一の新しいデータベースを作成することをサポートしていますか。
はい、サポートしています。DTS が提供するオブジェクト名マッピング機能を使用して、RDS インスタンス内のデータベースをコピーし、データベース名以外は同一の新しいデータベースを作成できます。
DTS インスタンスが常に遅延を示す場合の対処方法
考えられる原因は次のとおりです。
異なるアカウントを使用してソースデータベースインスタンスに対して複数の DTS タスクが作成されたため、インスタンスの負荷が高くなりました。同じアカウントを使用してタスクを作成する必要があります。
ターゲットデータベースインスタンスのメモリが不足しています。ビジネスを整理し、ターゲットデータベースインスタンスを再起動できます。問題が解決しない場合は、ターゲットインスタンスの仕様をスペックアップするか、プライマリ/セカンダリ スイッチオーバーを実行してください。
説明プライマリ/セカンダリ スイッチオーバーにより、瞬断が発生する可能性があります。アプリケーションに自動再接続メカニズムがあることを確認してください。
以前のコンソールでターゲットデータベースに同期または移行した後、フィールドがすべて小文字になる場合の対処方法
新しいコンソールを使用してタスクを設定し、ターゲットデータベースオブジェクト名の大文字小文字ポリシー機能を使用できます。詳細については、「ターゲットデータベースオブジェクト名の大文字小文字ポリシー」をご参照ください。
一時停止した DTS タスクを再開できますか。
一般的に、24 時間以内に一時停止された DTS タスクは正常に再開できます。データ量が少ない場合、7 日以内に一時停止された DTS タスクは正常に再開できます。タスクを 6 時間以上一時停止しないことを推奨します。
タスクを一時停止して再起動すると、進捗が 0 から始まる理由
タスクが再起動されると、DTS は完了したデータを再クエリし、残りのデータの処理を続行します。このプロセス中に、遅延によりタスクの進捗が実際の進捗と異なる場合があります。
DDL ロックレス変更の原則
DDL ロックレス変更の主な原則については、「主な原則」をご参照ください。
DTS は特定のテーブルの同期または移行の一時停止をサポートしていますか。
いいえ、サポートしていません。
タスクが失敗した場合、再購入する必要がありますか。
いいえ、必要ありません。元のタスクを再設定できます。
複数のタスクが同じターゲットにデータを書き込むとどうなりますか。
これにより、データの不整合が発生する可能性があります。
更新後もインスタンスがロックされている理由
ロックされた DTS インスタンスを更新した後、インスタンスのロックが解除されるまでに時間がかかります。お待ちください。
DTS インスタンスのリソースグループを変更できますか。
はい、できます。インスタンスの 基本情報 ページで、基本情報 エリアの リソースグループ名 の横にある 変更 をクリックします。
DTS にはバイナリログ分析ツールがありますか。
いいえ、DTS にはバイナリログ分析ツールはありません。
増分タスクが常に 95% を表示するのは正常ですか。
はい、正常です。増分タスクは継続的であり、完了しません。進捗は 100% には達しません。
DTS タスクが 7 日以上リリースされていない理由
フリーズしたタスクが 7 日以上保存されることがあります。
作成したタスクのポートを変更できますか。
これはサポートされていません。
DTS タスクの PolarDB-X 1.0 配下にマウントされた RDS for MySQL インスタンスをスペックダウンできますか。
スペックダウンは推奨されません。スペックダウンはプライマリ/セカンダリ スイッチオーバーをトリガーし、データ損失を引き起こす可能性があります。
DTS タスクの実行中にソースまたはターゲットインスタンスをスペックアップまたはスペックダウンできますか。
DTS タスクの実行中にソースまたはターゲットインスタンスをスペックアップまたはスペックダウンすると、タスクの遅延やデータ損失が発生する可能性があります。ソースまたはターゲットインスタンスの仕様を変更することは推奨しません。
DTS タスクがソースおよびターゲットインスタンスに与える影響
初期の完全データ同期は、ソースおよびターゲットデータベースの読み取りおよび書き込みリソースの一部を占有し、データベースの負荷を増加させる可能性があります。オフピーク時に完全タスクを実行することを推奨します。
DTS タスクのおおよその遅延
DTS タスクの遅延は、ソースインスタンスの実行負荷、伝送ネットワークの帯域幅、ネットワーク遅延、ターゲットインスタンスの書き込みパフォーマンスなど、多くの要因によって制限されるため、見積もることはできません。
Data Transmission Service コンソールが Data Management DMS コンソールに自動的にジャンプする場合、以前の Data Transmission Service コンソールに戻る方法
DMS コンソールで、右下隅の 
アイコンをクリックし、
をクリックして、以前のバージョンの Data Transmission Service コンソールに戻ります。
DTS はデータ暗号化をサポートしていますか。
DTS は、SSL 暗号化を介してソースまたはターゲットデータベースに安全にアクセスし、ソースデータベースからデータを読み取ったり、ターゲットデータベースにデータを書き込んだりすることをサポートしていますが、データ転送中の転送中のデータの暗号化はサポートしていません。
DTS は ClickHouse をソースまたはターゲットとしてサポートしていますか。
いいえ、サポートしていません。
DTS は AnalyticDB for MySQL 2.0 をソースまたはターゲットとしてサポートしていますか。
AnalyticDB for MySQL 2.0 はターゲットとしてのみサポートされており、AnalyticDB for MySQL 2.0 をターゲットとするソリューションは、新しいコンソールではまだ利用できません。以前のコンソールでのみ設定できます。
コンソールで新しく作成したタスクが表示されない理由
間違ったタスクリストを選択したか、タスクをフィルタリングした可能性があります。対応するタスクリストで、正しいリージョンやリソースグループなどの正しいフィルターオプションを選択してください。
作成したタスクのグレー表示された設定項目は変更できますか。
これはサポートされていません。
遅延アラートとしきい値の設定方法
DTS はモニタリングとアラート機能を提供しています。コンソールで重要な監視メトリクスのアラートルールを設定して、実行ステータスを常に把握できます。設定方法については、「モニタリングとアラートの設定」をご参照ください。
長時間失敗しているタスクの失敗原因を表示できますか。
いいえ、できません。タスクが長時間 (たとえば 7 日以上) 失敗している場合、関連するログはクリアされ、失敗原因は表示できません。
長時間失敗しているタスクを復元できますか。
いいえ、できません。タスクが長時間 (たとえば 7 日以上) 失敗している場合、関連するログはクリアされ、復元できません。タスクを再設定する必要があります。
rdsdt_dtsacct アカウントとは
rdsdt_dtsacct アカウントを作成していない場合、DTS によって作成された可能性があります。DTS は、一部のデータベースインスタンスに組み込みアカウント rdsdt_dtsacct を作成して、ソースおよびターゲットデータベースインスタンスに接続します。
SQL Server のヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブル、スパース列のあるテーブルに関する情報の表示方法
次の SQL ステートメントを実行して、ソースデータベースにこれらのシナリオのテーブルがあるかどうかを確認できます。
-
ソースデータベースのヒープテーブルを確認します。
SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id IN (SELECT object_id FROM sys.indexes WHERE index_id = 0); -
プライマリキーのないテーブルを確認します。
SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id NOT IN (SELECT parent_object_id FROM sys.objects WHERE type = 'PK'); -
クラスター化インデックスに含まれていないプライマリキー列を確認します。
SELECT s.name schema_name, t.name table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id WHERE t.type = 'U' AND s.name NOT IN('cdc', 'sys') AND t.name NOT IN('systranschemas') AND t.object_id IN ( SELECT pk_colums_counter.object_id AS object_id FROM (select pk_colums.object_id, sum(pk_colums.column_id) column_id_counter from (select sic.object_id object_id, sic.column_id FROM sys.index_columns sic, sys.indexes sis WHERE sic.object_id = sis.object_id AND sic.index_id = sis.index_id AND sis.is_primary_key = 'true') pk_colums group by object_id) pk_colums_counter inner JOIN ( select cluster_colums.object_id, sum(cluster_colums.column_id) column_id_counter from (SELECT sic.object_id object_id, sic.column_id FROM sys.index_columns sic, sys.indexes sis WHERE sic.object_id = sis.object_id AND sic.index_id = sis.index_id AND sis.index_id = 1) cluster_colums group by object_id ) cluster_colums_counter ON pk_colums_counter.object_id = cluster_colums_counter.object_id and pk_colums_counter.column_id_counter != cluster_colums_counter.column_id_counter); -
ソースデータベースの圧縮テーブルを確認します。
SELECT s.name AS schema_name, t.name AS table_name FROM sys.objects t, sys.schemas s, sys.partitions p WHERE s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id = p.object_id AND p.data_compression != 0; -
計算列を含むテーブルを確認します。
SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id IN (SELECT object_id FROM sys.columns WHERE is_computed = 1); -
スパース列を含むテーブルを確認します。
SELECT s.name AS schema_name, t.name AS table_name FROM sys.schemas s INNER JOIN sys.tables t ON s.schema_id = t.schema_id AND t.type = 'U' AND s.name NOT IN ('cdc', 'sys') AND t.name NOT IN ('systranschemas') AND t.object_id IN (SELECT object_id FROM sys.columns WHERE is_sparse = 1);
ソースとターゲットのスキーマが一致しない場合の対処方法
マッピング機能を使用して、ソースとターゲットの列間にマッピング関係を確立してみてください。詳細については、「データベース、テーブル、列のマッピング」をご参照ください。
列タイプの変更はサポートされていません。
データベース、テーブル、列のマッピングは列タイプの変更をサポートしていますか。
いいえ、サポートしていません。
DTS はソースデータベースの読み取り速度の制限をサポートしていますか。
いいえ、サポートしていません。タスクが実行される前に、ソースデータベースのパフォーマンス (IOPS やネットワーク帯域幅が要件を満たしているかなど) を評価する必要があります。また、オフピーク時にタスクを実行することを推奨します。
MongoDB シャードクラスターインスタンスの孤立ドキュメントをクリーンアップする方法
孤立ドキュメントの確認
mongo シェルを使用して MongoDB シャードクラスターインスタンスに接続します。
ApsaraDB for MongoDB への接続方法については、「mongo シェルを使用してシャードクラスターインスタンスに接続する」をご参照ください。
次のコマンドを実行して、ターゲットデータベースに切り替えます。
use <db_name>次のコマンドを実行して、孤立ドキュメントに関する情報を表示します。
db.<coll_name>.find().explain("executionStats")説明各シャードの
executionStatsを表示します。SHARDING_FILTERステージのchunkSkipsフィールドが 0 でない場合、対応するシャードに孤立ドキュメントが存在することを意味します。次のサンプル出力は、
SHARDING_FILTERステージの前にFETCHステージで 102 個のドキュメント ("nReturned" : 102) が返されることを示しています。次に、SHARDING_FILTERステージで 2 つの孤立ドキュメント ("chunkSkips" : 2) がフィルタリングされます。最後に、100 個のドキュメント ("nReturned" : 100) が返されます。"stage" : "SHARDING_FILTER", "nReturned" : 100, ...... "chunkSkips" : 2, "inputStage" : { "stage" : "FETCH", "nReturned" : 102,SHARDING_FILTERステージの詳細については、MongoDB マニュアルをご参照ください。
孤立ドキュメントのクリーンアップ
複数のデータベースがある場合は、各データベースの孤立ドキュメントをクリーンアップする必要があります。
ApsaraDB for MongoDB インスタンス
メジャーバージョンが 4.2 より前、またはマイナーバージョンが 4.0.6 より前の ApsaraDB for MongoDB インスタンスでクリーンアップスクリプトを実行すると、エラーが発生します。バージョンを確認するには、「MongoDB マイナーバージョンリリースノート」をご参照ください。アップグレードするには、「インスタンスのメジャーバージョンをアップグレードする」および「インスタンスのマイナーバージョンを更新する」をご参照ください。
MongoDB 4.4 以降
-
シャードクラスターインスタンスに接続できるサーバーに
cleanupOrphaned.jsという名前の JavaScript ファイルを作成します。このスクリプトは、複数のシャードにまたがる複数のデータベースのすべてのコレクションから孤立ドキュメントを削除します。特定のコレクションを対象にするには、スクリプトのパラメーターを変更します。
パラメーター 説明 shardNamesクリーンアップするシャードの ID。シャードクラスターインスタンスの [基本情報] ページの [シャードリスト] セクションで確認できます。例： d-bp15a3796d3a****。databasesToProcess孤立ドキュメントを削除するデータベースの名前。 // シャードの名前。 var shardNames = ["shardName1", "shardName2"]; // 孤立ドキュメントを削除するデータベース。 var databasesToProcess = ["database1", "database2", "database3"]; shardNames.forEach(function(shardName) { // 指定されたデータベースを走査します。 databasesToProcess.forEach(function(dbName) { var dbInstance = db.getSiblingDB(dbName); // 指定されたデータベースのすべてのコレクションの名前を取得します。 var collectionNames = dbInstance.getCollectionNames(); // すべてのコレクションを走査します。 collectionNames.forEach(function(collectionName) { // 完全なコレクション名。 var fullCollectionName = dbName + "." + collectionName; // cleanupOrphaned コマンドを構築します。 var command = { runCommandOnShard: shardName, command: { cleanupOrphaned: fullCollectionName } }; // cleanupOrphaned コマンドを実行します。 var result = db.adminCommand(command); if (result.ok) { print("Cleaned up orphaned documents for collection " + fullCollectionName + " on shard " + shardName); printjson(result); } else { print("Failed to clean up orphaned documents for collection " + fullCollectionName + " on shard " + shardName); } }); }); });スクリプトの次のパラメーターを更新します。
-
cleanupOrphaned.jsが保存されているディレクトリで、次を実行します。パラメーター 説明 <Mongoshost>mongos ノードのエンドポイント。形式： s-bp14423a2a51****.mongodb.rds.aliyuncs.com。<Primaryport>mongos ノードのポート番号。デフォルト： 3717。<database>アカウントの認証データベースの名前。 <username>データベースアカウント。 <password>データベースアカウントのパスワード。 output.txt実行結果を保存するファイル。 mongo --host <Mongoshost> --port <Primaryport> --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js > output.txt
MongoDB 4.2 以前
-
シャードクラスターインスタンスに接続できるサーバーに
cleanupOrphaned.jsという名前の JavaScript ファイルを作成します。このスクリプトは、複数のシャードにまたがる特定のコレクションから孤立ドキュメントを削除します。複数のコレクションを処理するには、
fullCollectionNameパラメーターを更新してスクリプトを再実行するか、スクリプトを変更してすべてのコレクションを反復処理します。パラメーター 説明 shardNamesクリーンアップするシャードの ID。シャードクラスターインスタンスの [基本情報] ページの [シャードリスト] セクションで確認できます。例： d-bp15a3796d3a****。fullCollectionNameクリーンアップするコレクションの完全な名前。形式： データベース名.コレクション名。function cleanupOrphanedOnShard(shardName, fullCollectionName) { var nextKey = { }; var result; while ( nextKey != null ) { var command = { runCommandOnShard: shardName, command: { cleanupOrphaned: fullCollectionName, startingFromKey: nextKey } }; result = db.adminCommand(command); printjson(result); if (result.ok != 1 || !(result.results.hasOwnProperty(shardName)) || result.results[shardName].ok != 1 ) { print("Unable to complete at this time: failure or timeout.") break } nextKey = result.results[shardName].stoppedAtKey; } print("cleanupOrphaned done for coll: " + fullCollectionName + " on shard: " + shardName) } var shardNames = ["shardName1", "shardName2", "shardName3"] var fullCollectionName = "database.collection" shardNames.forEach(function(shardName) { cleanupOrphanedOnShard(shardName, fullCollectionName); });スクリプトの次のパラメーターを更新します。
-
cleanupOrphaned.jsが保存されているディレクトリで、次を実行します。パラメーター 説明 <Mongoshost>mongos ノードのエンドポイント。形式： s-bp14423a2a51****.mongodb.rds.aliyuncs.com。<Primaryport>mongos ノードのポート番号。デフォルト： 3717。<database>アカウントの認証データベースの名前。 <username>データベースアカウント。 <password>データベースアカウントのパスワード。 output.txt実行結果を保存するファイル。 mongo --host <Mongoshost> --port <Primaryport> --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js > output.txt
自己管理 MongoDB データベース
-
自己管理 MongoDB データベースに接続できるサーバーに
cleanupOrphaned.jsスクリプトをダウンロードします。wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js" -
cleanupOrphaned.jsファイルで、testを孤立ドキュメントを削除するデータベースの名前に置き換えます。重要複数のデータベースを処理するには、各データベースで手順 2 と 3 を繰り返します。
-
各シャードで、次のコマンドを実行して、指定されたデータベースのすべてのコレクションから孤立ドキュメントを削除します。
パラメーター 説明 <Shardhost>シャードの IP アドレス。 <Primaryport>シャードのプライマリノードのサービスポート。 <database>アカウントの認証データベースの名前。 <username>自己管理 MongoDB データベースにログインするために使用するアカウント。 <password>自己管理 MongoDB データベースにログインするために使用するパスワード。 mongo --host <Shardhost> --port <Primaryport> --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js例：3 つのシャードを持つ自己管理 MongoDB データベースの場合、シャードごとにコマンドを 1 回実行します。
mongo --host 172.16.1.10 --port 27018 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js mongo --host 172.16.1.12 --port 27024 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
トラブルシューティング
孤立ドキュメントの名前空間にアイドルカーソルが存在する場合、クリーンアッププロセスが完了せず、mongod ログに次の情報が含まれることがあります。
Deletion of DATABASE.COLLECTION range [{ KEY: VALUE1 }, { KEY: VALUE2 }) will be scheduled after all possibly dependent queries finishmongo シェルを使用して mongod インスタンスに接続し、次のコマンドを実行して現在のシャードにアイドルカーソルがあるかどうかを確認できます。アイドルカーソルが存在する場合は、restart mongod または killCursors コマンドを使用してクリアする必要があります。その後、孤立ドキュメントのクリーンアップを再試行できます。詳細については、JIRA チケットをご参照ください。
db.getSiblingDB("admin").aggregate( [{ $currentOp : { allUsers: true, idleCursors: true } },{ $match : { type: "idleCursor" } }] )シャード化された MongoDB クラスターの不均一なデータ分布の処理方法
バランサー機能を有効にし、事前シャーディングを使用してデータスキューを解決できます。データスキューは、ほとんどのデータが単一のシャードに書き込まれる場合に発生します。
バランサーの有効化
バランサーが無効になっているか、バランサーウィンドウのアクティブ期間が開始されていない場合は、バランサーを有効にするか、バランサーウィンドウを一時的にキャンセルして、すぐにデータバランシングを開始できます。
MongoDB シャードクラスターインスタンスに接続します。
mongos ノードのコマンドウィンドウで、config データベースに切り替えます。
use config必要に応じて次のコマンドを実行します。
バランサー機能を有効にする
sh.setBalancerState(true)バランサーウィンドウを一時的にキャンセルする
db.settings.updateOne( { _id : "balancer" }, { $unset : { activeWindow : true } } )
事前シャーディング
MongoDB は、範囲シャーディングとハッシュシャーディングの 2 つのシャーディング方法をサポートしています。事前シャーディングは、チャンクを複数のシャードノードに均等に分散します。これにより、DTS データ同期または移行中に最適な負荷分散を実現できます。
ハッシュシャーディング
numInitialChunks パラメーターを使用して、事前シャーディングを実装できます。このパラメーターの値はデフォルトで シャード数 × 2 であり、最大 シャード数 × 8192 まで設定できます。詳細については、「sh.shardCollection()」をご参照ください。
sh.shardCollection("phonebook.contacts", { last_name: "hashed" }, false, {numInitialChunks: 16384})範囲シャーディング
ソース MongoDB がシャードクラスターの場合、
config.chunksのデータを使用して、シャードテーブルのチャンク範囲を取得できます。その後、この範囲を事前シャーディングコマンドの<split_value>の参照として使用できます。ソース MongoDB がレプリカセットの場合、
findコマンドのみを使用してシャーディングキーの範囲を決定し、合理的な分割点を定義できます。# シャーディングキーの最小値を取得 db.<coll>.find().sort({<shardKey>:1}).limit(1) # シャーディングキーの最大値を取得 db.<coll>.find().sort({<shardKey>:-1).limit(1)
コマンド形式
次の例では splitAt コマンドを使用しています。詳細については、「sh.splitAt()」、「sh.splitFind()」、および「シャードクラスターのチャンクを分割する」をご参照ください。
sh.splitAt("<db>.<coll>", {"<shardKey>":<split_value>})サンプル文
sh.splitAt("test.test", {"id":0})
sh.splitAt("test.test", {"id":50000})
sh.splitAt("test.test", {"id":75000})事前シャーディング操作を完了した後、mongos ノードで sh.status() コマンドを実行して、事前シャーディングの結果を確認できます。
コンソールのタスクリストでページごとに表示されるインスタンス数を設定する方法
次の手順では、同期インスタンスを例として使用します。
ターゲットリージョンの同期タスクリストページに移動します。次の 2 つの方法のいずれかを使用できます。
DTS コンソールから
左側のナビゲーションウィンドウで、データ同期 をクリックします。
ページの左上隅で、同期インスタンスが配置されているリージョンを選択します。
DMS コンソールから
説明実際の操作は、DMS コンソールのモードとレイアウトによって異なる場合があります。詳細については、「シンプルモード」および「DMS インターフェイスのレイアウトとスタイルをカスタマイズする」をご参照ください。
Data Management (DMS) にログインします。
トップメニューバーで、 を選択します。
データ同期タスク の右側で、同期インスタンスが配置されているリージョンを選択します。
ページの下部までスクロールします。
ページの右下隅で、[ページあたりの項目数] を選択します。
説明[ページあたりの項目数] は 10、20、または 50 に設定できます。
DTS インスタンスが ZooKeeper 接続タイムアウトを報告した場合の対処方法
インスタンスを再起動して接続を復元してみてください。インスタンスの再起動方法については、「DTS インスタンスの開始」をご参照ください。
CEN で削除された後、DTS CIDR ブロックが自動的に再追加される理由
これは、Cloud Enterprise Network (CEN) の Basic Edition トランジットルーターを使用してデータベースを DTS に接続する場合に発生する可能性があります。このデータベースを使用して DTS インスタンスを作成すると、CEN で DTS CIDR ブロックを削除しても、DTS はサーバーの IP アドレス範囲を対応するルーターに自動的に追加します。
DTS タスクをエクスポートできますか。
サポートされていません。
Java を使用して OpenAPI を呼び出す方法
Java で OpenAPI を呼び出す方法は、Python の場合と似ています。詳細については、「Python SDK 呼び出し例」をご参照ください。Data Transmission Service DTS SDK ページに移動し、[すべての言語] から希望のプログラミング言語を選択して、サンプルコードを表示できます。
API を使用して同期または移行タスクの ETL 機能を設定する方法
この機能は、API オペレーションの Reserve パラメーターの etlOperatorCtl や etlOperatorSetting などの共通パラメーターを使用して設定できます。詳細については、「ConfigureDtsJob」および「Reserve パラメーターの説明」をご参照ください。
DTS は Azure SQL Database をサポートしていますか。
はい、サポートしています。Azure SQL Database をソースデータベースとして使用するには、SQL Server 増分同期モード を 増分同期のための CDC インスタンスのポーリングとクエリ に設定します。
DTS の同期または移行が完了した後、ソースデータベースのデータは保持されますか。
はい。DTS はソースデータベースのデータを削除しません。ソースデータベースのデータが不要になった場合は、手動で削除できます。
同期または移行インスタンスの実行後にレートを調整できますか。
はい、できます。詳細については、「移行レートの調整」をご参照ください。
DTS は期間による同期または移行のデータサンプリングをサポートしていますか。
いいえ。
データを同期または移行する際に、ターゲットデータベースにデータテーブルを手動で作成する必要がありますか。
データベースおよびテーブルスキーマタスクをサポートする DTS インスタンス (スキーマ同期またはスキーマ移行) の場合、同期タイプ で スキーマ同期 が選択されているか、移行タイプ で スキーマ移行 が選択されている場合は、ターゲットデータベースにデータテーブルを手動で作成する必要はありません。
データを同期または移行する際に、ソースデータベースとターゲットデータベースのネットワークを接続する必要がありますか。
いいえ、必要ありません。
パブリックネットワークを使用してクロスアカウント DTS タスクを設定する際に、RAM 認可を設定する必要がありますか。
いいえ、必要ありません。DTS タスクを設定する際に、データベースインスタンスの アクセス方法 を パブリック IP アドレス に設定してから、設定を完了できます。
データ同期タスクは、パブリック IP アドレス メソッドを使用したデータベースインスタンスへの接続をサポートしていません。
DTS を使用してデータを同期または移行すると、ターゲットの既存データは上書きされますか。
データ同期の場合、DTS のデフォルトの動作と関連パラメーターは次のとおりです。
DTS のデフォルトの動作
同期タスクの実行中にプライマリキーまたは一意キーの競合が発生した場合：
テーブルスキーマが同じで、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキーまたは一意キーの値を持つ場合：
完全同期中、DTS はターゲットクラスターのレコードを保持します。ソースデータベースの対応するレコードは同期されません。
増分同期中、ソースデータベースのレコードはターゲットデータベースのレコードを上書きします。
テーブルスキーマが異なる場合、初期データ同期が失敗する可能性があります。これにより、一部の列データのみが同期されるか、完全な同期が失敗する可能性があります。注意して進めてください。
関連パラメーター
タスク設定プロセス中に、競合するテーブルの処理モード パラメーターを使用して、DTS が既存のテーブルをどのように処理するかを制御できます。
エラーの事前チェックと報告：ターゲットデータベースに同じ名前のテーブルが存在するかどうかを確認します。同じ名前のテーブルが存在しない場合、事前チェックは成功します。同じ名前のテーブルが存在する場合、事前チェックは失敗し、データ同期タスクは開始されません。
説明ターゲットデータベースで同じ名前のテーブルを削除または名前変更できない場合は、別のテーブル名にマッピングできます。詳細については、「テーブル名と列名のマッピング」をご参照ください。
エラーを無視して続行：ターゲットデータベースの重複テーブル名のチェックをスキップします。
警告エラーを無視して続行 を選択すると、データの不整合が発生し、ビジネスにリスクが生じる可能性があります。例：
テーブルスキーマが同じで、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキーまたは一意キーの値を持つ場合：
完全同期中、DTS はターゲットクラスターのレコードを保持します。ソースデータベースの対応するレコードは同期されません。
増分同期中、ソースデータベースのレコードはターゲットデータベースのレコードを上書きします。
テーブルスキーマが異なる場合、初期データ同期が失敗する可能性があります。これにより、一部の列データのみが同期されるか、完全な同期が失敗する可能性があります。注意して進めてください。
提案
データ整合性を確保するために、ビジネス運用で許可されている場合は、DTS タスクを設定する前にターゲットテーブルを削除することを推奨します。