RDSに巨大なデータをインポートしたいんだけど色々エラーが出て困った話

# RDSに巨大なデータをインポートしたいんだ

オンプレミスのデータベースサーバーから、RDSにデータ移行したいという案件でのお話。
まずはデータインポートが普通にできてそのまま接続してシステム動かせるんかいな？っておい所の検証をしようとしたときにいっぱいつまづいた記録です＾＾；

ネットでいろいろ探してみたけど、みんなキレイな構成だったり上級者の記録だったりで、グダグダな構成からの脱却記録がなかったので何かの参考になればと、恥を忍んで対応記録を書いてみます。

## 巨大なデータってどれくらい？

データベースのダンプファイルがだいたい 7G くらい。
ビッグデータ云々って言われている昨今では軽い方のデータなのかもしれない。
巨大とか言い過ぎた感があります（反省）。

## やったこと

まず、percona の xtrabackup を使って、「S3 から Aurora DB クラスターを復元」をやってみたんですが、DBクラスターが動き出してるのにRDSのインスタンスが存在しないっていうなんだか中途半端な状態にしかならず、色々やった結論としては「フルバックアップの復元中にエラーになってそのままインスタンスは消滅、クラスタだけが動いてんじゃね？」てことに。
この件はまた詳細調査する時間ができたら記事にします。

ですので、最終的には
[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html "わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート")
ここを参考にダンプファイルからRDSにインポートする作戦を実施します。
今回は検証の目的なので、オンプレミスとのレプリケーション構築は次のステップに譲ることになります。

ひとまずダンプファイルを作りましょう。

```
mysqldump -u <user> -h <host> -p \
 --single-transaction \
 --routines=0 --triggers=0 --events=0 \
 --master-data=2 \
 --order-by-primary \
 --databases mydatabase \
 -r backup-mydatabase.sql
```

リンク先にも書いてありますが、大事なのは
`--routines=0 --triggers=0 --events=0` と `--master-data=2 --order-by-primary` これみたい。

で、いったんmysqlの使えるec2インスタンスを立ててコピーします。
これはやり方省略します。いっかい、素の`t2.micro`インスタンスでやってみたらメモリ足りなくなったので、[swap領域を1G追加](https://qiita.com/IZAKAYA/items/5e31f90797f26eb1b673) して実施してます。

```
[local] % tar cvzf backup-mydatabase.sql.tgz backup-mydatabase.sql
[local] % scp -i <秘密鍵> backup-mydatabase.sql.tgz <ec2のパブリックIP>:/home/ec2-user/
```
次に、RDSインスタンスを作成します。
RDSでmysqlまたはauroraのインスタンスを作成するのは手順省きますが、「パラメータグループ」だけはdefaultではなく、自前で用意した方が良いです。

RDSインスタンスが動き出したらec2からインポートします。

```
[ec2] % tar xvzf backup-mydatabase.sql.tgz
[ec2] % mysql -u <rds-user> -p -h <rds-host> mydatabase
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 4065
Server version: 5.7.12 MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [mydatabase]> source backup-mydatabase.sql
```

なんだか、変なエラーも出てますが、エラーを無視してインポートしていってくれてる風なので、たぶん順調です＾＾；
が。。。。

突然コンソール上に酷い表示が。

```
ERROR 2006 (HY000) at line 1667 in file: 'backup-mydatabase.sql': MySQL server has gone away
　　：
　　：　（あとずっと同じエラー）
```

(。-`ω-)タイムアウトしやがった。。
ググったら
[ナレッジセンター](https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-sql-server-gone-away/ "Amazon RDS MySQL DB インスタンスへの接続時に発生する「MySQL server has gone away」エラーの解決方法を教えてください。")
にビンゴなQ&Aがあったので、これを実施してみます。

まず、RDSのコンパネ開いてパラメータグループを編集します。
defaultのパラメータグループでRDSインスタンスを作った場合は、ここで新しくパラメータグループを作ってRDSインスタンスにattachしなおします。

RDSコンソールのナビゲーションペインから、「パラメータグループ」を選択して「パラメータグループの作成」をクリックします。
![パラメータグループ作成.JPG](https://qiita-image-store.s3.amazonaws.com/0/184209/2d48eefc-7e4b-8215-d6e1-be0620d3eaaf.jpeg)

パラメータグループファミリーの選択肢では、作成したRDSインスタンスのdatabaseタイプ・バージョンと同じものを選んでください。
私は Auroraをmysql5.7互換で作成したので、「aurora-mysql5.7」を選択しました。
あとは適当に入力して作成します。

グループが作成されました。
今回修正したいのは、

* wait_timeout
* interactive_timeout
* max_allowed_packet

の3つです。

![パラメータグループ一覧.JPG](https://qiita-image-store.s3.amazonaws.com/0/184209/a6172804-cfd8-e797-36d4-5a086374ec2f.jpeg)
次に、作成したグループ名をクリックします。
![timeout-filtering.JPG](https://qiita-image-store.s3.amazonaws.com/0/184209/5696677f-49ce-8345-7ada-04c35f043712.jpeg)
パラメータ名のフィルタテキストに "timeout" と入力しましょう。
いくつかパラメータリストが表示されました。
その中から、`wait_timeout`、`interactive_timeout` の二つに適当に数字を設定します。
![wait-timeout.JPG](https://qiita-image-store.s3.amazonaws.com/0/184209/e18e7175-cbba-e146-2a0d-66ced6889c88.jpeg)
![interactive-timeout.JPG](https://qiita-image-store.s3.amazonaws.com/0/184209/e6977e1c-1eb7-f302-9606-33e8fc336544.jpeg)
ここでは、1時間＝3600秒 と設定しました。

同じように、`max_allowed_packet` には書かれている最大値を設定して反映しておきましょう。

本当はここで、`time_zone`、`characterset*` のパラメータも変更した方が良いですが、今は先を急ぐので飛ばします。

パラメータを変更したら反映に少し時間がかかりますので、RDSコンソールのインスタンス一覧で「利用可能」になるまで少し待ちましょう。

```
ERROR 1227 (42000) at line 9673 in file: 'backup-mydatabase.sql': Access denied; you need (at least one of) the SUPER privilege(s) for this operation
```

こんなエラーが多発しましたが、RDSでは使えないセッション変数を変更しようとしたり、VIEWを変な文法で作ろうとするステートメントがあったせいなので、mysqlコンソールに入ってから source コマンドでインポートすると、-fオプション付けた時のようにエラーがあっても無視して次のステートメントを実行してくれるので便利です。

さて、今回はこれでインポートできるようになりましたが、ここまでたどり着くまでにほぼ丸1日潰しました。。。

この次は、本番稼働用にいったんRDSをスレーブにしてオンプレミスとRDSの間でレプリケーションを作成、動かしながら参照先DBを切り替えてからRDS内で完結させる構成に移行するっていう、ミスが許されないミッションが残ってます。

この件は、また後日記事に書きたいと思います。