Data Management (DMS) を使用すると、フィルター条件に一致する行をソースデータベースから ApsaraDB RDS for MySQL インスタンスに、1 回限りのジョブまたは定期的なスケジュールで移動できます。これにより、監査や分析のために履歴データを保持しながら、本番テーブルをスリムに保つことができます。
データアーカイブ機能は、シンガポールおよびインドネシア (ジャカルタ) リージョンでのみ利用可能です。
前提条件
開始する前に、以下が準備できていることを確認してください。
サポートされているいずれかのタイプのソースデータベース：
MySQL：ApsaraDB RDS for MySQL、PolarDB for MySQL、または AnalyticDB for MySQL V3.0
PostgreSQL：ApsaraDB RDS for PostgreSQL または PolarDB for PostgreSQL
PolarDB-X
MySQL データベースアカウントに
REPLICATION CLIENT権限が付与されていることアーカイブ送信先としての ApsaraDB RDS for MySQL インスタンス。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。
ソーステーブルにプライマリキーまたは一意キーがあること
(推奨) 各ソーステーブルに、時間ベースのアーカイブのフィルター条件として使用するタイムスタンプ列があること
課金
課金対象は、宛先となる ApsaraDB RDS for MySQL インスタンスです。詳細については、「課金項目」をご参照ください。
注意事項
ストレージ領域：アーカイブ後にソースデータを削除するようにジョブを設定した場合、DMS は行を削除する前に、まずソースデータベース内の一時バックアップテーブルに行を書き込みます。ソースデータベースに、一時バックアップテーブルを保持するのに十分なストレージ領域があることを確認してください。領域が不足すると、ソースインスタンスが利用できなくなる可能性があります。
スケジュールモードおよびコントロールモード: DMS は、ソースおよびターゲットデータベースの両方が [セキュリティコラボレーション] モードで管理されている場合にのみ、定期スケジュールでアーカイブジョブを実行します。ワンタイムジョブの場合、データベースは任意のコントロールモードで構いません。コントロールモードを変更するには、「インスタンスのコントロールモードを変更する」をご参照ください。
仕組み
アーカイブジョブが実行されると、DMS は指定されたソーステーブルからフィルター条件に一致する行を読み取り、宛先の ApsaraDB RDS for MySQL インスタンスに書き込みます。DMS は、ソースデータベースとソーステーブルと同じ名前を使用して、宛先インスタンスにデータベースとテーブルを自動的に作成します。アーカイブされた各テーブルには、アーカイブ情報 (チケット番号と時刻)、ソースデータベース名、ソーステーブル名、ソースインスタンス ID の 4 つのメタデータ列が追加されます。既存のデータ列は影響を受けません。
[事後動作] オプションでソースデータの削除を設定した場合、DMS は DELETE 文を実行する前に、一致した行をソースデータベース内の一時バックアップテーブルに移動します。アーカイブされたデータが正しいことを確認した後、通常のデータ変更チケットを申請して、一時バックアップテーブルを削除します。
データのアーカイブ
DMS コンソール V5.0 にログインします。
上部のナビゲーションバーで、[ソリューション] > [データアーカイブ] を選択します。
シンプルモードでは、左上の
アイコンにポインターを合わせ、[すべての機能] > [ソリューション] > [データアーカイブ] を選択します。アーカイブデータチケットページの右上隅にある [アーカイブデータ] をクリックします。
「チケット申請」ページで、次の表で説明されているパラメーターを設定します。
パラメーター 必須 説明 タスク名 はい アーカイブタスクの説明的な名称です。分かりやすい名称を設定することで、後続の確認作業を削減できます。 アーカイブ送信先 はい 送信先のタイプです。RDS MySQL を選択します。 ApsaraDB RDS インスタンス はい アーカイブ先となる ApsaraDB RDS for MySQL インスタンスです。 ソースデータベース はい データをアーカイブする元のデータベースです。 アーカイブ構成 はい アーカイブ対象となる 1 つ以上のソーステーブルです。必要に応じて、特定の行を選択するためのフィルター条件を指定できます。期間（例：6 ヶ月以上前のデータ）を指定してデータをアーカイブする場合は、まず 変数構成 セクションで時間変数を設定し、その後、フィルター条件内でその変数を参照します。追加 をクリックすると、さらにソーステーブルを追加できます。 アーカイブテーブルマッピング いいえ 送信先テーブルに対するカスタム設定です。編集 をクリックして、送信先テーブル名、カラム、シャードキー、パーティションキーを指定します。 変数構成 いいえ フィルター条件で使用する時間変数です。たとえば、 6_month_agoという名前の変数を、フォーマットyyyy-MM-dd、オフセット-6 Monthで定義した場合、現在日付が 2021 年 8 月 12 日であれば、評価結果は2021-02-11となります。フィルター条件内では、${6_month_ago}のように参照します。設定手順については、「時間変数の構成」セクション（「変数」Topic）をご参照ください。実行後の動作 いいえ アーカイブ後にソーステーブルからアーカイブ済みの行を削除するかどうかを指定します。 元のテーブルのアーカイブ済みデータをクリーンアップ（削除・ノンロック） を選択した場合、DMS はロックフリーの DELETE通常データの変更定期データ変更ロックフリーデータ定義言語 (DDL) 操作 文を使用して行を削除します。この処理中、ソースデータベース内に一時バックアップテーブルが作成されます。アーカイブ済みデータの検証が完了したら、一時バックアップテーブルを削除するために、 チケットを起票してください。このオプションを選択しない場合、アーカイブ済みの行はソーステーブルに残り、手動で削除およびストレージ最適化を行う必要があります。具体的には、データ削除用に チケットを起票し、ストレージ使用量の最適化用に チケットを起票します。実行モード はい アーカイブジョブの実行タイミングです。単発実行 は、チケット承認後に 1 回だけジョブを実行します。定期スケジュール実行 は、指定したスケジュールに従って繰り返しジョブを実行します。ただし、両方のデータベースがセキュリティコラボレーションモードである必要があります。スケジューリングのオプションについては、「定期スケジューリング」セクション（「Lindorm インスタンスへのデータアーカイブ」Topic）をご参照ください。 [送信] をクリックします。
チケットが承認されると、DMS は自動的にアーカイブジョブを実行します。アーカイブされたデータは、宛先インスタンスにテーブルとして保存されます。
ジョブが失敗した場合は、「実行」ステップの「操作」列にある [詳細] をクリックしてタスクログを表示し、原因を特定します。ネットワークやデータベース接続の問題でタスクが失敗した場合は、[ブレークポイントから再試行] をクリックして、停止した箇所からジョブを再開できます。
アーカイブ済みデータのクエリ
アーカイブジョブが完了したら、次の手順に従ってアーカイブされたデータを表示します。
「チケット詳細」ページで [基本情報] セクションを見つけ、[ターゲットデータベース] の横にある [表示] をクリックして「SQL コンソール」タブを開きます。
左側の [テーブル] タブで、表示したいテーブルを見つけてダブルクリックし、[実行] をクリックしてデータをロードします。
各アーカイブテーブルには、アーカイブ情報 (チケット番号と時刻)、ソースデータベース名、ソーステーブル名、ソースインスタンス ID の 4 つの追加メタデータ列が含まれています。これらの列は元のデータに影響を与えません。
次のステップ
定期的なアーカイブスケジュールを設定するには、「Lindorm インスタンスへのデータのアーカイブ」トピックの「定期的なスケジューリング」セクションをご参照ください。