データドリブン経営の前提として考えるMVV：ミッション・ビジョン・バリューと戦略・戦術・戦法
AWSのデータ移行、今回はMySQL編です。
MySQLでのデータ移行は、mysqldumpコマンドを使用します。
| C:>mysqldump --database {databse} --user={username} --password={password} >dump.txt |
割と簡単ですが、投入してみると一向に終わる気配がありません。
Ctrl+Cキーで中断してtxtの中身を見たらびっくり！
DROP、CREATEはわかりますが、データがINSERT文で延々書き出されています。
こりゃあ、時間がかかるはずです。
全テーブルだと不要なものも出てしまいますし、どこまで行ったかわからないので、今回もバッチ力を駆使して、テーブルごとにテキストに吐き出してゆきます。
そしてAWSに圧縮転送して、インポート。案の定、ものすごく時間がかかりました。
このような場合は、CSVにエクスポートして、MySQL LOADコマンドで読むのが高速でよいでしょう。しかし、今回はテスト用のイリーガルデータを多く含むため、CSVにした時に正しくデータが読めるか保証がなかったのと、サーバーがWindowsで、RDSがLinuxであり、文字コード問題に引っかかりたくなかった理由で、SQL文でのIMPORTを選択しました。
AWSのガイドには、オンプレミスの本番機と非同期レプリケーションでデータ移行する手法が載っています。
これは、本番の切れ目を少なくする効果がありますが、そもそもMySQLのデータロードが異常に遅いことに起因しているのではないかと思います。OracleのDIRECT PATHやDB2のLOADと比較すると、MySQLやPostgreSQLのデータロードはかなり遅いです。
まぁとりあえず移行ができたので、テスターにDBを明け渡すと、「テーブルが存在しないと言われるんですが」とクレームが。
MySQLコマンドでSQLを投入すると確かにテーブルもあるしデータも入っています。ただ、問題は、テーブル名を小文字で入れないとだめだったということ。
LinuxのMySQLはデフォルトでテーブル名の大文字小文字を区別するのです。これには参りました。カラム名は大文字小文字無視なのに。
先ほどのdump.txtを見ると、確かにテーブル名だけ小文字でCREATE TABLEが記載されています。
my.iniでパラメータ「lower_case_table_names」を「1」に修正すればいいそうなんですが、はて？RDSでmy.iniはどうやって直すのでしょう？
RDSには「パラメータグループ」という設定項目があって、ここでMySQLのパラメータ設定を指定できます。
これができるのはMySQLだけなので注意が必要です。
そうそう、RDSのコンソールが、ちょうど今日から日本語化されましたね。まだ翻訳は詳しく見ていませんが、やはり母国語だと素直に意味が入ってきて作業がしやすいです。
次回は、PostgreSQL編をお送りします。
Amazon Relational Database Service（Amazon RDS）へのデータ移行（１）SQL Server編
Amazon RDSへのデータ移行（３）番外：PostgreSQL編＋Oracle情報
20年以上の実績に裏打ちされた信頼のデータ連携ツール「Waha! Transformer」で、自社に眠るデータを有効活用。まずは無料のハンズオンセミナーや体験版で効果を実感していただけます。
Rankingランキング
New arrival新着
Keywordキーワード
