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

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

最終更新日:Aug 20, 2024

このトピックでは、AnalyticDB for MySQL V3.0クラスターにデータをアーカイブする方法について説明します。

前提条件

  • データをアーカイブするソースデータベースは、次のいずれかのタイプです。

    • MySQL: ApsaraDB RDS for MySQLPolarDB for MySQL、およびAnalyticDB for MySQL V3.0

    • PostgreSQL: ApsaraDB RDS for PostgreSQLおよびPolarDB for PostgreSQL

    • PolarDB-X

    説明

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

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

  • データをアーカイブするソーステーブルには、主キーまたは一意のキーがあります。

    説明

    ソーステーブルの各データ変更操作の時間を示すフィールドを指定することをお勧めします。 ソーステーブルからデータをアーカイブするときに、このフィールドをフィルター条件として使用できます。

使用上の注意

  • データアーカイブチケットを設定するときに、Post-behaviorパラメーターを元のテーブルのアーカイブデータのクリーンアップ (delete-No Lock) に設定した場合、ソースデータベースに十分なストレージ容量があることを確認します。 これにより、データアーカイブ中のストレージ容量不足による例外を防ぎます。

    たとえば、390 GBのテーブルデータをアーカイブする必要がある場合は、ソースデータベースに少なくとも390 GBのストレージスペースが確保されていることを確認してください。

  • Data Management (DMS) は、ソースデータベースとターゲットデータベースの両方がSecurity CollaborationまたはStable Changeモードで管理されている場合にのみ、データアーカイブタスクを定期的に実行します。 データアーカイブタスクを1回だけ実行する必要がある場合は、ソースデータベースとターゲットデータベースを任意のモードで管理できます。

    説明

    定期的なデータアーカイブタスクを設定し、ソースデータベースインスタンスとターゲットデータベースインスタンスを安定した変更モードで管理する場合は、データベースインスタンスのセキュリティホスティングを有効にするか、データベースインスタンスの制御モードをsecurity Collaborationに変更することを推奨します。 そうしないと、インスタンスのログインの有効期限が切れてデータアーカイブタスクが失敗する可能性があります。 詳細については、「セキュリティホスティング」トピックのセキュリティホスティングの有効化セクションとインスタンスの制御モードの変更をご参照ください。

  • AnalyticDB for MySQL data Lakehouse Edition V3.0クラスターにデータをアーカイブする場合は、クラスターにコンピューティングリソースが予約されていることを確認してください。 それ以外の場合、データアーカイブタスクは失敗します。 Data Lakehouse Editionクラスターのスケールアップまたはスケールダウンの詳細については、「Data Lakehouse Editionクラスターのスケール」をご参照ください。

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

課金

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

手順

  1. DMSコンソールV5.0 にログインします。

  2. 上部のナビゲーションバーで、解決策 > データアーカイブ を選択します。

    説明

    DMSコンソールをシンプルモードで使用する場合は、左上隅の2023-01-28_15-57-17.pngアイコンの上にポインターを移動し、[すべての機能] > [ソリューション] > [データアーカイブ] を選択します。

  3. [データアーカイブチケット] ページの右上隅にある [データアーカイブ] をクリックします。

  4. [チケットアプリケーション] ページで、データアーカイブチケットを作成するためのパラメーターを設定します。 下表にパラメーターを示します。

    パラメーター

    必須

    説明

    タスク名

    必須

    データアーカイブタスクの名前。 タスクを簡単に識別できるように、わかりやすい名前を指定することをお勧めします。 これにより、不要な通信を減らすことができます。

    アーカイブ先

    必須

    データをアーカイブする宛先。 AnalyticDB for MySQL を選択します。

    分析エンジン

    必須

    データのアーカイブ先のAnalyticDB for MySQL V3.0クラスター。

    ソースデータベース

    必須

    データをアーカイブするソースデータベース。

    アーカイブ設定

    必須

    • オプションです。 指定したテーブルにアーカイブするデータを照会するためのフィルター条件を1つ以上指定します。 例: gmt_modified<='${6_month_ago}'

      説明

      6か月前に生成されたデータのアーカイブなどのシナリオで時間変数を使用する場合は、アーカイブ設定セクションでパラメーターを設定する前に、[変数設定] セクションで変数を設定できます。

    • オプション[追加] をクリックして、ソーステーブルを追加します。

    アーカイブテーブルのマッピング

    任意

    ターゲットデータベースで使用されるテーブル設定。 ソーステーブルの [操作] 列で [編集] をクリックし、ターゲットデータベースの対応するアーカイブテーブルの名前、列、データベースシャードキー、およびパーティションキーを指定できます。

    変数設定

    任意

    アーカイブデータのフィルター条件を設定するときに使用される変数。 たとえば、6_month_agoという名前の時間変数をyyyy-MM-dd形式で作成し、オフセットを-6 Monthに設定したとします。 この場合、現在の日付が2021年8月12日である場合、変数 ${6_month_ago} の値は、2021年2月11日を示す2021-02-11です。 時間変数の設定方法の詳細については、「変数」トピックの「時間変数の設定」セクションをご参照ください。

    事後行動

    任意

    • ソーステーブルからアーカイブデータを削除するかどうかを指定します。 元のテーブルのアーカイブデータのクリーンアップ (削除-ロックなし) を選択した場合、アーカイブデータはソーステーブルから自動的に削除されます。 DELETE文を実行して、一時バックアップテーブルを削除できます。 一時バックアップテーブルは、ソーステーブルが削除されたときにアーカイブされたデータを格納するためにソースデータベースに生成されます。 ソースデータベースに十分なストレージスペースがあることを確認して、ストレージスペース不足によるインスタンスの使用不能を防ぎます。

      データがアーカイブされ、アーカイブされたデータが正しいことを確認したら、通常のデータ変更チケットを作成して、ソースデータベースから一時バックアップテーブルを消去できます。

    • 元のテーブルのアーカイブデータのクリーンアップ (削除-ロックなし) を選択しない場合、アーカイブデータはソーステーブルから削除されません。 この場合、ソーステーブルからデータを手動で削除し、ストレージ使用量を最適化する必要があります。

      1. ソーステーブルからアーカイブデータを削除するには、通常のデータ変更チケットを作成します。 詳細については、「定期的なデータ変更の実行」をご参照ください。

      2. ソーステーブルのストレージ使用量を最適化するには、ロックフリーの変更チケットを作成します。 詳細については、「ロックフリーDDL操作の実行」をご参照ください。

    操作モード

    必須

    データアーカイブタスクの実行に使用するメソッド。 有効な値:

    • シングル実行: データアーカイビングチケットが承認された後、DMSはデータアーカイビングタスクを1回だけ実行します。

    • 周期的なスケジューリング: データアーカイブチケットが承認されると、DMSは指定したスケジュールに基づいてデータアーカイブタスクを実行します。 詳細については、「Lindormインスタンスへのデータのアーカイブ」トピックの「周期的スケジューリング」セクションをご参照ください。

  5. 送信クリックします。

  6. データアーカイビングチケットが承認されると、DMSはデータアーカイビングタスクを自動的に実行します。 データアーカイブタスクが完了するまで待ちます。

    データアーカイブタスクの実行に失敗した場合は、[実行] ステップの [操作] 列の [詳細] をクリックして、データアーカイブタスクのログを表示し、タスクの失敗の原因を特定できます。 ネットワークまたはデータベース接続の障害が原因で問題が発生した場合は、[再試行] をクリックしてタスクを再起動します。

    アーカイブされたデータは、テーブルの形式でデータベースに保存されます。

  7. アーカイブデータを照会します。 詳細については、このトピックの「アーカイブデータの照会」をご参照ください。

アーカイブデータの照会

方法1: DMSを使用してアーカイブデータを照会する

  1. [チケットの詳細] ページの [基本情報] セクションで、[ターゲットデータベース] の横にある [表示] をクリックして、[SQLコンソール] タブに移動します。

  2. [SQLコンソール] タブの左側の [テーブル] タブで、管理するテーブルを見つけ、テーブル名をダブルクリックし、[実行] をクリックしてアーカイブデータを表示します。

    説明

    DMSは、ソースデータベースとテーブルの名前に基づいて、ターゲットインスタンスにデータベースとテーブルを自動的に作成します。 したがって、移行先データベースの名前は移行元データベースの名前と同じになります。

    次の4列のデータがアーカイブテーブルに追加されます。 これは、テーブル内の元のアーカイブデータの使用には影響しません。

    • チケット番号とデータがアーカイブされた時刻を含むデータアーカイブ情報

    • データベース名

    • テーブル名

    • インスタンスID。インスタンスをDMSに登録するときに指定されるIDで、インスタンスの実際のIDに対応します。

方法2: AnalyticDB for MySQLを使用してアーカイブデータを照会する

詳細については、「データのインポートとクエリ」をご参照ください。