Data Management:AnalyticDB for MySQL V3.0 クラスターへのデータアーカイブ

仕組み

データアーカイブチケットを送信すると、DMS は次のワークフローを実行します。

1. 指定したフィルター条件に基づいて、ソーステーブルからデータを読み取ります。

2. データをターゲットの AnalyticDB for MySQL V3.0 クラスターに書き込みます。

3. ソースデータのクリーンアップを有効にした場合、ソースデータベースに一時バックアップテーブルを作成し、その後、アーカイブされた行をソーステーブルから削除します。

DMS は、アーカイブされた各テーブルに4つのメタデータ列 (アーカイブチケット番号とタイムスタンプ、ソースデータベース名、ソーステーブル名、ソースインスタンス ID) を追加します。これらの列は元のデータを変更するものではありません。

前提条件

次の前提条件を満たしていることを確認してください。

• 次のいずれかのタイプのソースデータベース：

  • MySQL：ApsaraDB RDS for MySQL、PolarDB for MySQL、または AnalyticDB for MySQL V3.0

  • PostgreSQL：ApsaraDB RDS for PostgreSQL または PolarDB for PostgreSQL

  • PolarDB-X

• AnalyticDB for MySQL V3.0 クラスター。詳細については、「クラスターの作成」をご参照ください。

• プライマリキーまたは一意キーを持つソーステーブル

• (推奨) フィルター条件として使用するために、最終更新日時を記録するタイムスタンプフィールドがソーステーブルにあること

MySQL データベースアカウントには、REPLICATION CLIENT 権限が必要です。

注意事項

• リージョンでの利用可否：データアーカイブ機能は、シンガポールおよびインドネシア (ジャカルタ) リージョンでのみ利用可能です。

• ソースデータクリーンアップ用のストレージ領域: [事後動作] を [元のテーブルのアーカイブ済みデータをクリーンアップする (delete-No Lock)] に設定した場合は、ソースデータベースに十分なストレージ領域があることを確認してください。 これにより、データアーカイブ中のストレージ領域不足による例外の発生を防ぎます。 たとえば、390 GB のデータをアーカイブするには、ソースデータベースに少なくとも 390 GB の空きストレージ領域が必要です。

• 定期タスクのコントロールモード：DMS は、ソースデータベースとターゲットデータベースの両方がセキュリティコラボレーションまたは安定的な変更モードで管理されている場合にのみ、定期データアーカイブタスクを実行します。ワンタイムタスクの場合、どのコントロールモードでも動作します。

  安定的な変更モードのデータベースでの定期タスクについては、ログインの有効期限切れによるタスクの失敗を防ぐため、セキュリティホスティングを有効にするか、セキュリティコラボレーションモードに切り替えてください。 詳細については、「セキュリティホスティング」および「インスタンスのコントロールモードを変更する」をご参照ください。

• Data Lakehouse Edition クラスター：Data Lakehouse Edition V3.0 クラスターにデータをアーカイブする場合、クラスターに予約済みのコンピューティングリソースがあることを確認してください。そうでない場合、タスクは失敗します。詳細については、「Data Lakehouse Edition クラスターのスケーリング」をご参照ください。

課金

AnalyticDB for MySQL V3.0 クラスターに対して課金されます。料金詳細については、「Data Warehouse Edition の料金」および「Data Lakehouse Edition の料金」をご参照ください。

データアーカイブタスクの作成

実行後の動作の設定

[実行後の動作] は、DMS がアーカイブされたデータをソーステーブルから削除するかどうかを制御します。

アーカイブされたデータのクエリ

参考資料

• AnalyticDB for MySQL V3.0 クラスターの作成

• セキュリティホスティング

• インスタンスのコントロールモードを変更する

• 変数