Fippiyのプログラム学習内容アウトプットBlog

日々の学習内容をアウトプットして振り返りを実施する。

Laravel開発、作成したアプリをデプロイして本番環境で動作させる【3】ローカルのデータベースを変更する

デプロイして本番環境でアプリを動作させるシリーズの続きです。

※本番環境設定の記事として書いていますが、本記事は主にローカルDBの設定変更となっています。本番環境のDB設定については次の記事で記載を予定しています。

 

前回の記事にて、DB変更手順を整理していました。 

DBの扱いは下記の通りです。

  1. ローカルDBをSQLiteからMySQLに変更
  2. HerokuDBを設定

ここから実際にDBの設定変更を実施していきます。 

なぜやるか

Laravelで使用するDBは初期設定としてMySQLになっていました。

今回、本番環境で使用するDBをMySQLにしようと思い、まずローカルのDBをMySQLへ変更することとしました。

(結果的に本番環境はPostgreSQLに変更しましたが。)

やりたいこと

ローカルDBをSQLiteからMySQL切り替える

やったこと

database.phpの設定変更

DB作成

テーブルをマイグレーションファイルで作成

 

 

実施内容

ローカルDB変更する

まずはconfig設定をMySQLに変更

#database.php

'default' => env('DB_CONNECTION', 'sqlite'),

'default' => env('DB_CONNECTION', 'mysql'),

あわせて、MySQL設定も修正

# database.php

f:id:Fippiy:20190327205146p:plain

データベース設定

ローカルのデータベースMySQLは.envからデータを読み込む設定とし、デフォルト値は解除しました。

 

DB作成

設定変更後はMySQLのDB作成です。

railsでアプリを作成していた時は、DB作成のcreateコマンドがあったのですが、それに相当するコマンドがみつかりませんでした。

そこで、MySQL上で直接データベースを作成しました。

こちらは、GUIツール「sequelPro」を既に導入していましたので、そちらで作成しました。

 マイグレーションファイルを利用してテーブル作成

新規DB作成完了後、マイグレーションファイルを適用…したかったがされず。

DB設定のMySQL項目について、変更手順を確認しました。

ローカル環境変数が適用されているかどうかも不明な状態でしたので、database.phpファイルに設定を記載して確認することを初めにしました。

railsアプリ作成時に環境変数がうまく読み込まれず、直接設定をファイルに書くことで動作することがありましたので、動作確認の手順として一度直接書き込むを先にしました。

 

設定完了後、改めてマイグレーションをするとエラー表示。

SQLSTATE[HY000] [2002] No such file or directory (SQL: select * from information_schema.tables where table_schema = test and table_name = migrations)

ファイルかディレクトリが存在しない?

 

このエラーに対して調べてみた結果、こちらを参考にさせて頂きました。ありがとうございます。

qiita.com

ソケット設定

ソケット設定が必要なようです。

こちらを追加設定して、再度マイグレーションを実施。

エラー内容が変化。

SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'users' already exists (SQL: create table `users` (`id` bigint unsigned not null auto_increment primary key, `name` varchar(255) not null, `email` varchar(255) not null, `email_verified_at` timestamp null, `password` varchar(255) not null, `remember_token` varchar(100) null, `created_at` timestamp null, `updated_at` timestamp null) default character set utf8mb4 collate 'utf8mb4_unicode_ci')

この時、DBをSeqelProで確認すると、usersテーブルのみが中途半端にできていました。

DBを一端削除して、マイグレーションし直すと解決するような解説も見かけましたので、一度試してみました。

再度マイグレーションを実施、エラー内容が変わりました。

SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

 この問題にはこちらを参照させて頂きました。ありがとうございます。

qiita.com

標準charaset変更による対応

原因は標準charasetが変わっている事による、データサイズ超過によるものでした。

上記サイトの対策3の対処を行うことで、エラー解決することにしました。

f:id:Fippiy:20190327205714p:plain

Schema::defaultStringLength

そして、再度マイグレーションを実施。エラーが変わりました。

SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'users' already exists (SQL: create table `users` (`id` bigint unsigned not null auto_increment primary key, `name` varchar(191) not null, `email` varchar(191) not null, `email_verified_at` timestamp null, `password` varchar(191) not null, `remember_token` varchar(100) null, `created_at` timestamp null, `updated_at` timestamp null) default character set utf8mb4 collate 'utf8mb4_unicode_ci')

これは先程も同じエラーに遭遇しました。

DBを削除して再度実施することでエラーが変化していましたので、同様に一度DBを削除して再度マイグレーションを実施。

ここでようやくマイグレーションに成功しました。

 

DB設定情報の修正

これでローカル環境での設定は終了…といきたかったのですが、今のままだとdatabase.phpに設定情報がそのまま全部残っています。

環境変数へデータを書き換えても動作することを確認する必要もあった為、設定情報を書き換えました。

ここは書き換えるだけですんなり終了しました。

 

設定変更を本番環境へ反映 

今までの内容でローカル上のDB移行は完了したので、設定内容を一度gitでマージまで実施し、本番環境へも反映させました。

ローカル設定変更のみなので、本番環境は特に何の変化もありませんが…。

 

次はいよいよ本番環境のDB設定を変更します。

 

fippiy.hatenablog.jp