Go to Qiita Advent Calendar 2024 Top
LoginSignup
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@jnitin株式会社BeeX

AWS DMSでMySQLからRedshiftへのマイグレーションを試してみる

Last updated at Posted at 2022-10-12

はじめに

  • MySQLのデータをRedshiftへマイグレーションしたいというニーズがあり、手順について検証してみました。
    要件としてはマイナーなのか、あまり情報がなかったので書き起こしておきます。

  • なお、テストは小さなテーブルで実施しましたので、負荷テストの参考にはなりません。
    また、他の方への参考のために「エラーのトラブルシュート履歴」を意識的に記載しているため、途中の設定値は正しいものではないことをご了承ください。

image.png

DMSの特徴

  • 様々なデータソース（移行元DB）、データターゲット（移行先DB）に対応したマイグレーションサービスです。

  • 一度きりの移行だけでなく、継続的にデータを転送することができます。

  • 移行元と移行先の間に、「レプリケーションインスタンス」という専用のインスタンスを起動しておく必要があります。

    • レプリケーションインスタンスはインスタンスの一時停止ができないためコスト面で注意が必要です。

  • DMSの新機能の一つに[Fleet Advisor]というものがあります。[Fleet Advisor]は今回のように移行元DBが定まっている場合には役立ちませんので、今回は利用しません。以下に調査記事のリンクを貼り付けておきます。

  • DMSの連携対象

  • DMSのサポートDBエンジンは以下の情報源を参照ください。

今回の構成

対象 DB Engine DB Version Location spec
移行元DB MySQL on EC2 5.7.38 AWS VPCのEC2 t3.small
レプリケーションインスタンス - 3.4.7 AWS VPC dms.t3.micro, 50GB
移行先DB Redshift 1.0.41881 AWS VPC dc2.large

image.png

諸条件

  • ソースがMySQLの場合、Redshiftへの変換にSCTが利用できない

    • DMSにはSCT(SchemaConversionTool)という、ローカルPCにインストールしてスキーマやストアドプロシージャ等を自動変換・診断してくれるツールがあります。このSCTはソースDBとターゲットDBの組み合わせごとに使用可否が決まっている点に注意が必要です。
    • 以下のURLの通り、ソースがMySQLの場合、ターゲットにRedshiftを選択することができません。
    • ためしにSCTでソースをMySQLにしてみたところ、ターゲットにはRedshiftが表示されませんでした。仕様通りですね。
      image.png
    • DMSでのマイグレーションは、SCTが必須ということではなく、SCTを使わない場合は必要に応じて自力の対応が必要になります。 今回は変換元がシンプルなテーブル構造であるという想定のもと、DMSのみで検証をしてみます。

  • MySQLをソースとした場合の留意点

  • Redshiftをターゲットとした場合の留意点

    • Redshiftは基本的にバルクロードでデータを取得する設計になっているため、ターゲットをRedshiftに設定した場合、DMSはいったんS3にcsvデータを吐き、自動でそれをRedshiftにCOPYします。それ用のリソースが自動で作成されます。
      • S3バケット：dms-(乱数)
      • IAMロール：dms-access-for-endpoint

      • Amazon Redshift ターゲットエンドポイントにデータを移行する際、AWS DMS はデフォルトの Amazon S3 バケットを中間タスクストレージとして使用し、その後移行されたデータを Amazon Redshift にコピーします

      • AWS DMS は Amazon S3 バケットを使用してデータを Amazon Redshift データベースに転送します。AWS DMS がバケットを作成できるようにするため、コンソールは IAM ロール dms-access-for-endpoint を使用します。

    • そのほか、ターゲットがRedshiftの場合、後述する 「移行前評価」が対応していない などの制限もあります。その他の諸条件は以下のページに記載されています。

検証環境の構築

今回は何もないところから検証を行いますので、ソースDBとターゲットDBを作成し、ソースDBにはサンプルデータを入れていきます。

【ソースDB】MySQL on EC2

Amazon Linux2に、ちょっと古いバージョンのMySQL 5.7系をインストールします。
このへんは本題ではないのでさらっと書いておきます。

MySQLインストール

古いバージョンのリポジトリは以下です。
https://dev.mysql.com/downloads/repo/yum/

対象のバージョン選択後、ログインせずに以下のリンク右クリックでURLを取得できます。

image.png

- MySQL7系のリポジトリをインストール
# yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-6.noarch.rpm

- MySQL 8.0をインストールしないように設定
# yum-config-manager --disable mysql80-community

- MySQL 5.7系をインストール対象に設定
# yum-config-manager --enable mysql57-community

- AmazonLinux2にデフォルトでインストールされているMariaDBライブラリの削除
# yum remove mariadb-libs

- MySQLのインストール
# yum install mysql-community-server --nogpgcheck

OS周りの設定

MySQLのタイムゾーンはシステム環境変数によって表示が制御されます。
とりあえずOSレベルでJSTに設定しておきます。

- タイムゾーンを日本時間に設定
# vi /etc/sysconfig/clock
# cat /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=true
# ln -sf  /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

MySQLの設定

MySQlのDMSの利用条件として、[binlog_format=row]にしておく必要があります。
また、バイナリログを有効化するには、[server-id]パラメータなどの設定も必要なので最低限の設定だけしておきます。

# cp -p /etc/my.cnf{,.org}
# vi /etc/my.cnf
# diff  /etc/my.cnf{,.org}
28,32d27
<
< server-id=1
< log-bin=mysql-bin
< binlog_format=row
< binlog_checksum=none

# service mysqld restart

上記のようにバイナリログを設定しておかないと、後述のデータベース移行タスクにおいて、タスク実行時に以下のようなエラーが出ます。
Binary Logging must be enabled for MySQL server

初期パスワードの確認と変更

- 出力されるログから初期パスワードを確認する
# grep -e 'A temporary password is generated for root@localhost' /var/log/mysqld.log

- rootユーザでログインする。パスワードは先程確認したものを入力。
# mysql -u root -p

- ログイン後、パスワードを変更する
mysql> set password = '**********';

ダミーデータを作成しMySQLに挿入

以下のサイトからダミーデータを生成します。

スキーマはサンプルのものを利用します。
[Test Sample Database Schema]をクリックします。

image.png

とりあえずプルダウンから[authors]テーブルを選択します。

image.png

データ入力規則はとくに変えずに、件数として 1000 を入力して[Generate data]を押します。
image.png

生成されたデータを、[Export authors]ボタンからダウンロードします。これでsql文のファイルがローカルにダウンロードされます。
image.png

同じようにpostsテーブルの行を、こちらは10000件で作成します。
それぞれの.sqlファイルをSSHセッションにアップし、sourceコマンドで読み込ませます。
※私の場合、エラーが起きたのでコピペで実行しました。

件数は正しく入っているようです。

mysql> select count(*) from authors;
+----------+
| count(*) |
+----------+
|     1000 |
+----------+
1 row in set (0.01 sec)

mysql> select count(*) from posts;
+----------+
| count(*) |
+----------+
|    10000 |
+----------+
1 row in set (0.02 sec)

なお、後述しますがDMS専用のMySQLユーザも作っておいたほうがよいです。ここでは作っていない体で進めます。

【ターゲットDB】Redshift

EC2と同じVPC内に最小サイズのdc2.largeで作成します。
IAMロールは、とりあえず無しで作成します。
それ以外は特筆すべきものがないので割愛します。

なお、後述しますがIAMロールは付与する必要があります。ここでは付与していない体で進めます。

移行の手順検証

ソースDBとターゲットDBが作成できたので、DMSを触って移行手順を検証していきます。
以下のような順番で進めます。

  • レプリケーションインスタンスの作成
  • エンドポイントの作成
  • データベース移行タスクの作成

DMS

レプリケーションインスタンスの作成

レプリケーションインスタンスを作成します。
検証用ですので最小サイズのインスタンス、ストレージとし、パブリックアクセスはよくわかりませんが検証データなのでとりあえず有りにしておきます。

項目 設定値 備考
インスタンスクラス dms.t3.micro 小さいテーブルなので最小サイズ
ストレージ 50GB （デフォルト）
VPC Redshiftと同じVPC
マルチAZ シングル
パブリックアクセス可能 チェックあり 検証なのであまり気にせず
セキュリティとネットワークの詳細設定 デフォルト
メンテナンス デフォルト
  • 移行に適したスペックについては以下のページを参照してください。
    • https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Types.html
      • 以下のようなちょっとした助言がかいてあります。

      • AWS DMS は、特に Oracle から PostgreSQL への移行など、異種の移行やレプリケーションを実行する場合に、CPU を集中的に使用する可能性があります。C4 インスタンスは、このような状況に適しています。

エンドポイントの作成

  • ソースエンドポイント
    • MySQL on EC2用のエンドポイントを作成
    • ソースエンジン：MySQL
    • エンドポイントデータベースへのアクセス：アクセス情報を手動で提供する
    • 接続情報のユーザー名を、最初MySQLのrootユーザにしていましたが、接続テストにおいて以下のようなfailedエラーが出ました。
    • Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider ODBC general error., Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HY000 NativeError: 1130 Message: [unixODBC][MySQL][ODBC 8.0(w) Driver]Host 'ip-10-0-1-125.ap-northeast-1.compute.internal' is not allowed to connect to this MySQL server
      image.png
    • おそらくMySQLのデフォルト設定だとリモートからのrootユーザアクセスが不可になっていると思われます。
    • そこでDMS専用のMySQLユーザを以下のように作成し、ソースエンドポイントのユーザに指定したところ接続テストが成功しました。
      • 以下は全テーブルへの管理者権限かつ、%で全てのIPからのアクセスを許可していますのでご注意ください。
CREATE USER 'dms-admin'@'%' IDENTIFIED BY '*********';
show grants for 'dms-admin'@'%';
grant all on *.* to 'dms-admin'@'%';
  • ターゲットエンドポイント
    • Redshift用のエンドポイントを作成
    • ターゲットエンジン：Amazon Redshift
    • エンドポイントデータベースへのアクセス：アクセス情報を手動で提供する
    • サーバ名、ポート、データベース名はRedshiftのエンドポイントから切り出したものを指定

上記のような感じで作り、Redshiftは接続テストも問題なくクリアしました。

データベース移行タスクの作成

データベース移行タスクを作っていきます。
何回か失敗しているので、同じような方向けに、失敗内容も記載しておきます。

トライ1

  • データ移行タスク
    • タスクの設定
      • (名前、ソース、ターゲット、等は割愛)
      • 移行タイプ
        • 既存のデータを移行して、継続的な変更をレプリケートする
    • タスク設定
      • (全てデフォルトのまま)
    • 移行前評価
      • 移行前評価の実行の有効化：チェックあり※
        • 評価レポートのストレージ：(新規作成したバケットを指定)
        • IAM ロール：(S3フルアクセスを持つIAMロールを新規作成し指定)
    • 移行タスクのスタートアップ設定
      • 後で手動で行う

※移行前評価にチェックを入れると、評価用のS3バケットやIAMロールの作成が必要になります。

以上のような設定でタスクを作成しようとしたところ、以下のようなエラーが出てタスク作成に失敗しました。
システムエラーメッセージ:VALIDATION_REDSHIFT feature is not available
image.png

どうやら「移行前評価の実行の有効化」でチェックをつけたことで動く「DMSのデータ検証機能」がRedshiftターゲットをサポートしていないようです。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Validating.html

データ検証は、AWS DMS がソースとターゲットのエンドポイントでサポートしている次のデータベースで動作します。
Oracle
PostgreSQL 互換データベース（PostgreSQL または Aurora PostgreSQL、Aurora Serverless for PostgreSQL）
MySQL 互換データベース (MySQL または MariaDB、Aurora MySQL、Aurora Serverless for MySQL)
Microsoft SQL Server
IBM Db2 LUW

Redshiftターゲットは何かとDMSの制約が多いですね。移行前評価が使えないのであればどうにもしようがないので、チェックをオフにします。
先程作成した移行評価用のS3バケットやIAMロールは、ターゲットRedshiftの場合はすなわち不要ということになります。
気を取り直して、「移行前評価の実行の有効化：チェックなし」で再作成してみます。

トライ2

  • データ移行タスク
    • タスクの設定
      • (名前、ソース、ターゲット、等は割愛)
      • 移行タイプ
        • 既存のデータを移行して、継続的な変更をレプリケートする
    • タスク設定
      • (全てデフォルトのまま)
    • テーブルマッピング
      • (全てデフォルトのまま)
    • 移行前評価
      • 移行前評価の実行の有効化：チェックなし
    • 移行タスクのスタートアップ設定
      • 後で手動で行う

今度は以下のようなエラーが出て作成に失敗しました。

システムエラーメッセージ:Error in mapping rules. At least one selection rule is required.
image.png

テーブルマッピングの[selection rule]設定を少なくとも１つ入れておかないとだめなようです。

トライ3

私にとっては「テーブルマッピングって何ぞ？」という状態なので、とりあえずワイルドカードの%をいれて、全てのテーブルを移行対象に設定してみました。

image.png

  • テーブルマッピング
    • ウィザード
    • 選択ルール
      • スキーマ名：%
      • テーブル名：%
      • アクション：含む
    • 変換ルール
      • (なし)

ウィザードで上記のような設定をすると、裏では以下のようなJSON設定が生成されます。

{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "803082689",
            "rule-name": "803082689",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}

※[rule-id]や[rule-name]は環境によって異なるのでご注意ください。

上記のようにマッピングを設定したところ、データベース移行タスクの作成ができ、移行タスクの作成中に遷移しました。
image.png

少し待つとステータスが「準備完了」になるので、「アクション」から「開始/再開」を選択して移行をスタートさせます。
image.png

で、ちょっと待っていると、うーん、失敗しましたね。
image.png

タスクをクリックして詳細画面を見てみると、FATALエラーが6個以上でたので停止したようです。
Last Error Task 'OZM2Z6R4N6WQUYGJGHP2POIOI5EO27SAFWHJFRY' was suspended due to 6 successive unexpected failures Stop Reason FATAL_ERROR Error Level FATAL
image.png

CloudWatchログも出力するようにしていたのですが、ログをみてもさっぱり原因がつかめず。

ちなみにCloudWatchlogsでDMSログからエラー系の行のみに絞るには、以下のような文字列でフィルタすると良いと思います。
"]E"
image.png
※このエラー画像は参考用です。

ログにはめぼしいものがなかったので、Redshiftのクエリエディタを見たところ、postsテーブルやauthorsテーブルはRedshiftにマイグレーションされていました。

image.png

  • DBのスキーマ構造やCloudWatchLogsなどを眺めていて、ふと、MySQLのシステムスキーマのことを思い出しました。
    • 以下はソースDBの「db01」が今回の検証用スキーマであり、「awsdms_control」はDMSが作成したもの。それ以外はシステム系スキーマです。これらを全て移行対象としてしまったようです。 
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| awsdms_control     |
| db01               |
| innodb             |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
7 rows in set (0.01 sec)
  • たとえばsysスキーマは、多くのストアドプロシージャが含まれているはずです。DMSではストアドプロシージャが移行できないのでエラーになりそうなものです。

トライ4

  • ということで、Redshiftに移行されたデータを全てドロップしたうえで、移行タスクを編集してテーブルマッピングの「選択ルール」より、スキーマ名を検証用DBの「db01」だけにフィルタリングしてみます。

image.png

  • テーブルマッピング
    • ウィザード
    • 選択ルール
      • スキーマ名：%
      • テーブル名：db01
      • アクション：含む
    • 変換ルール
      • (なし)

上記の選択ルールで生成されるjsonは以下の通りです。

{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "803082689",
            "rule-name": "803082689",
            "object-locator": {
                "schema-name": "db01",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}

マッピングルールを編集後、移行タスクを再開してみると、今度はマイグレーションが動きはしたものの、以下のように「エラーを伴って実行中」となっていました。

image.png

CloudWatchLogsを見てみると、以下のようにクラスタにDMSが自動作成したIAMロールが付与されていない、というエラーと、それに続くS3バケットのcsvファイルが読み取れないというエラーが出ていました。
dms-access-for-endpoint is not associated to cluster

image.png

最初に記載したとおりDMSは自動生成したIAMロールを使って、一度S3に吐き出したCSVをRedshiftにコピーさせる仕様です。DMSがそのIAMロールを使うものだと思っていましたが、このエラー文字列の「クラスタ」という言葉はRedshiftを指しているように見えます（DMSのレプリケーションインスタンスは「クラスタ」とは呼ばない気がします）。

「dms-access-for-endpoint」というIAMロールの名称から考えると、DMSの「ターゲットエンドポイント」に付与すべきロールのように思えるのですが、マネジメントコンソール上「ターゲットエンドポイント」でIAMロールを指定できる箇所がありませんでした。

参考までに、IAMロール「dms-access-for-endpoint」にくっついているIAMポリシー「AmazonDMSRedshiftS3Role」は以下の通りです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:ListBucket",
                "s3:DeleteBucket",
                "s3:GetBucketLocation",
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:GetObjectVersion",
                "s3:GetBucketPolicy",
                "s3:PutBucketPolicy",
                "s3:GetBucketAcl",
                "s3:PutBucketVersioning",
                "s3:GetBucketVersioning",
                "s3:PutLifecycleConfiguration",
                "s3:GetLifecycleConfiguration",
                "s3:DeleteBucketPolicy"
            ],
            "Resource": "arn:aws:s3:::dms-*"
        }
    ]
}

このポリシーは単純に考えると、「dms-*」という名前のバケットにたいする読み書き権限です。
Redshiftがロードの際にS3バケットにアクセスできればいいだけなので、上記のIAMポリシー/IAMロールではなくカスタマイズしたものでもよいかと思いますが、エラー文言に従って、RedshiftクラスタにIAMロール「dms-access-for-endpoint」を付与してみました。

image.png

Redshiftなので設定反映は数分かかります。

トライ5

上記の通りRedshiftにS3バケットへのアクセス用IAMロールを付与し、移行タスクを再開してみると、正常に動いているようです！

image.png

  • 所要時間

    • 今回のようなデータ量(テーブル合計で11,000件)だと、1分程度で移行処理が完了しました。

  • ログについて

    • CloudWatchlogsで以下のような文字列で検索すると、各テーブルのロード完了時間と件数が確認できます。
      Loading finished for table
      各行に出力されているTime takenは、DMS全体の所要時間ではないことをご注意ください。
2022-10-11T07:22:07 [TASK_MANAGER    ]I:  Loading finished for table 'db01'.'authors' (Id = 1) by subtask 1. 1000 records transferred. Time taken: 6669 micro seconds  (replicationtask.c:2447)
2022-10-11T07:22:25 [TASK_MANAGER    ]I:  Loading finished for table 'db01'.'posts' (Id = 2) by subtask 2. 10000 records transferred. Time taken: 112368 micro seconds  (replicationtask.c:2447)

継続的なレプリケーション状態になると、以下のログが10秒ごとで出力されるようです。
Task is running
image.png

データベース移行タスクのトライまとめ

  • ターゲットをRedshiftとした場合のこれまでのトライをまとめてみます
    • [トライ1]：「移行前評価の実行の有効化」はRedshiftでは利用できないためチェックを外す
    • [トライ2]：テーブルマッピングの選択ルールを少なくとも１つ設定しておく必要がある
    • [トライ3]：テーブルマッピングの選択ルールで、必要なテーブルのみに絞る必要がある
    • [トライ4]：RedshiftにはDMS用のS3バケットへのアクセス用IAMロールを付与する必要がある
    • [トライ5]：移行成功！

移行データの中身の検証

移行手順は確立できたので、今度はデータの中身などを見て行こうと思います。

データ型の変遷について

基礎知識

  • DMSを利用したマイグレーションで意識すべきポイントとして、ソースとターゲットのDBエンジンが異なる場合、データ型がそれぞれのDBエンジンに適した形に変換されるという点です。
    • このとき中間にDMSを挟む形になります。DMS自体にもデータ型が存在します。

image.png

MySQL DMS Redshift
BLOB(最大65535) BYTES(65535) VARCHAR (最大 LOB サイズ ※)

※ 最大 LOB サイズが 31 KB を超えることはできません。Amazon Redshift は 64 KB より大きい VARCHAR をサポートしていません。

  • 上記のように、とくにLOB(ラージバイナリオブジェクト)については異なるDBエンジン間では移行が困難なことが多いためか、「移行タスク」の作成時においてもLOBの扱いが設定できるようになっています。

  • それぞれ以下のようなオプションになっているようです。

「LOB 設定を含めない」を選択した場合、最大 LOB サイズが無視されます。
「完全 LOB モード」を選択した場合、AWS DMS は各 LOB を最大 LOB よりも小さなサイズに分割します。
「制限付き LOB モード」を選択した場合、AWS DMS は各 LOB が最大 LOB のサイズよりも大きくならないように切り捨てます。

今回移行したデータ型について

  • 今回のテストデータを移行してみたところ、下表のような感じになりました。
    • ソース側がシンプルなデータ型であるため、全体的に問題なくデータが移行できており、データ型も問題ないように見えます。
    • 赤字のところは気になるポイントです。

image.png

  • いくつかポイントを挙げてみます。
    • MySQLのvarcharがRedshiftでは3倍のサイズのVARCHARになっている。
      • UTF8のバイト数を考慮してのことでしょうか。
        • 厳密にいえば日本語のUTF-8は、特殊漢字に4バイトのUTF-8が割り当てられているのですが、対象文字はわずかな数なので、全体として3倍あればなんとかなる気がします。
    • MySQLのAUTO_INCREMENTがRedshiftでは削除されている
    • MySQLのUNIQUE KEYがRedshiftでは消えている
      • Redshiftだと一意制約違反をしてもエラーにならないので、そういうことでしょうか。
    • MySQLの照合順序(collation)がRedshiftでは消えている
      • [COLLATE utf8_unicode_ci]
        • この「ci」はCaseInsensitiveの略で、「大文字小文字を区別しない」という意味です。
        • Redshiftでもテーブル作成時に同様の指定(COLLATE CASE_INSENSITIVE)ができるようですが、「DMSは一部の制約しか移行できない」という仕様どおりということでしょうか。

タイムゾーンについて

今回のテストデータでは日付型・時刻型は以下のように変換されていました。

MySQL DMS Redshift
timestamp DATETIME timestamp
date DATE date

  • DMSのDATETIME型は以下の仕様とのことです。

  • MySQLではタイムゾーンの情報はカラムに持っているのではなく、システム変数で定義されるようです。つまりデータ自体はUTCで持っており、表示のときにシステム変数のタイムゾーンを参照する形のようです。

    • 今回のソースデータでは予めOSレベルでJSTに設定してありました。
mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | JST    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

  • 実際に先程のテーブルのデータをRedshiftに移行してみたところ、以下のようになっていました。

    • ソースのMySQL：JST表示(UTC+9)
    • ターゲットのRedshift：UTC表示 (つまり元のJSTから9時間引いた時間)

  • 基本的にデータベースレイヤーでは、欧米の夏時間などの考慮をしなくてもいいように、UTCで保持するのがベストプラクティスなようですので、DMSとしても適切に扱ってくれている、と理解しました。

ビューのマイグレーションと制約について

  • ビューに関しては最初に書いた通り、以下の制約があります。

    • 移行タスクにおいて「フルロード（既存のデータを移行する）」に設定した場合のみ、ビューをテーブルとして移行できます。

  • ということで簡単なビューを作り、新しくフルロードの移行タスクを作成して検証してみようと思います。

MySQL側

適当なビューを作っておきます。

create view id_title as select id, title from posts;

DMS側

  • フルロードのみの移行タスクをシンプルに作りました。
    • 既存の移行タスクを編集したかったのですが、移行タイプは変更できないようです。

image.png

ということで、以下のように"table-type": "all" を指定してマッピングを作り直し、移行してみました。

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "223438029",
      "rule-name": "223438029",
      "object-locator": {
        "schema-name": "db01",
        "table-name": "%",
        "table-type": "all"★この行を追加
      },
      "rule-action": "include",
      "filters": []
    }
  ]
}

※なお、パラメータ "table-type" はマネジメントコンソール上のウィザードでは選択できないため、直接マネコン上のJSONを編集する必要があります。

Redshift側

結果、フルロードのみ対応ではありますが、Redshift側にテーブルとしてビューの移行ができました。
簡単ですが、Redshift側のテーブル構造だけ記載します。

 dev2
   db01
     tables
       authors
       id_title (MySQL側でビューだったやつ）
       posts
       timetest
     views
       (none)

まとめ

  • 長くなってしまいましたが、MySQLからRedshiftへの、シンプルなテーブルの移行は問題なくできそうだ、という検証結果となりました。
  • 今回はシンプルでかつ小さいデータを利用したため、本番移行では以下のようなポイントで様々な考慮が必要になると思います。
    image.png

以上です。

4
2
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?