質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.64%

新規データベースでシステムのコピーを作りたい

受付中

回答 1

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 660
退会済みユーザー

退会済みユーザー

 前提・実現したいこと

現在1つのデータセットで Rails システムが動いているのですが
別環境で新たに同じシステムを追加することになりました

なのでテーブル構造でデータセットは別にして新規にデータベースを作成したい

 発生している問題

既存のマイグレーションは途中で手動で変更されたせいなのか一部マイグレーションに失敗します

試したいこと

新規にこれまでの履歴を無視したデータベース構成を作成するファイル
CREATE TABLE 'users' ...
みたいなのと
最低限の管理用初期データを挿入するファイル
INSERT INTO 'users' ...
というファイルを作って新規環境でのみ実行されるようにしたいです
(既存環境でデータが初期化されたら大惨事になる)

マイグレーションは db/migrate 以下の SQL コマンドリストをファイル単位でどこまで実行したか記憶して
未実行の差分だけを実行するものという認識なんですがあってますでしょうか

もしその認識で正しいのであれば
db/migrate 以下これまでの履歴と同じ名前で空のファイルに置き換えた状態で
1度新規サーバーにデプロイしてマイグレーション履歴を作ってしまう
今度は初期化用マイグレーションファイル 20181001....sql を中身を空にした状態で
既存のstaging, productionにデプロイして履歴を登録する
そのあと履歴ファイルを戻して 20181001....sql に初期化用の中身を描いて新規サーバーにデプロイする

という手順をとれば schema の中身はおなじになって別のDBの状態にできそうな気がするんですけどあってますか?

もしもっと簡単に実現する方法があれば教えていただきたいです

マイグレーションやデプロイ関連は先人が設定してくれた内容を使っていただけで全く知識がないので
見当外れな話をしていたらすいません

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • dice142

    2018/10/01 20:05

    「新しく空のテーブル構成」とは既存のテーブルと同名で何も入っていない状態ということでしょうか?イメージがつかないのでダミーでいいので例があると把握しやすいです。

    キャンセル

  • 退会済みユーザー

    退会済みユーザー

    2018/10/02 10:16

    そうです テーブル自体はユーザ情報やロール情報ぐらいですがカラムをどんどん追加してきた感じです

    キャンセル

  • dice142

    2018/10/02 10:58

    イメージが掴めないので現在どういう状態で、移行後はどういう感じになるのか追記していただけると助かります。

    キャンセル

回答 1

0

回答通りに行って問題が起こったとしても責任は持てません。 あくまでも一参考程度に収め、何かあった時に復旧ができるように 準備を欠かさないようにしてください。 大きな損失が出るのであればその手のプロフェッショナルを雇うべきです。

追記された情報を見ていたら案外単純なことなんじゃないかと思ったのですが、
もし解釈が間違っていたらご指摘ください。

そもそも異なる環境でマイグレーションすると既存のデータベースのデータは新しい環境に入りません。
(seedsとかmigrate時に挿入してるなら話は別ですが。)

マンションの設計図(migrateファイル)があり、それを建築(db:migrate)して
運用中に住人(データ)が入っていたとして、
新たに同じマンションを建築するときに、同じマンションの設計図から建築すると
見た目上は同じものができますが、そこの住人がコピーされることはないですよね?

初期レコードを挿入したいのであればdb:seedを使えばよいでしょう。


[用語について追記]

用語による齟齬が発生しそうなのでそのあたりを踏まえて追記します。

 RailsにおけるDB操作について

DBの作成や構造など、テーブル操作含めDBにおける操作は基本的にmigrationファイルで行うべきです。
ある処理はmigrationファイルでやってある処理はSQLコマンドでやって、のように複数の実行形式があると
どれか実行し忘れるだけでバグの原因になります。
Railsではrails db:migrateでファイルにある処理を一括して行ってくれるので
実行し忘れるというリスクは低いです。

また、Railsには他に初期化データを格納するseedsファイルがあるので、
最初のDB構築時に初期化データをrails db:seedで実行することができます。

今新規サーバで新しくDB環境を構築し、migrationファイルではなくSQLコマンドでなにか必要な処理したとします。
いずれ(新規サーバが壊れたとかで)また別な新規サーバで環境構築をするとまたSQLコマンドを打つことになりますが、
そのコマンドは確実に実行されると思いますか?
SQLコマンドを打ったが何を打ったかわからない、メモしたファイルが見つからない、そもそも担当者が変わってわからないとか
そういった面で実行されないリスクが高まります。

 環境によるDB周りについて

一般的にデータベースというとデータベース関連全体を含む広義の言葉を使用していますが、
構造は「レコード∈テーブル∈データベース」というようになっていて
この構造でいうデータベースはデータの集合を意味する狭義の表現となります。
便宜上、この回答内では「DB:広義の意味」、「データベース:狭義の意味」で区別して記載します。

Railsではrails db:createでデータベースの作成が行われ、環境毎に指定された名前の
データベースが作成されます。
そして、rails db:migrateでテーブル関連の処理が記載されたファイルに従って行われます。
このmigrationファイルに記載された内容はどの環境でも同じように実行されますが、
それ以外のもの、たとえば運用中のデータ挿入、削除、更新などは環境によって変わります。

例えばAサーバで作成されたhogeデータベースにhugaというテーブルを作成したとします。
これを運用し、ユーザ登録等でデータがどんどん増えていくとしましょう。
Bサーバに同じ環境を整えようとしたとき、
Bサーバ上にもhogeデータベースが作成され、hugaテーブルがその中に作成されます。
AサーバとBサーバでは名前こそ同じデータベースですが、別々の場所にあるものなので
AサーバのデータがBサーバのDBの中に入るわけではありません。

migrationファイルはあくまでも構築するための手順書で、
rails db:migrateは手順書を元に作り上げるだけなのです。

 gemについて

gemはRubyにおけるライブラリです。
複雑な機能を使いやすいようまとめたものだと思ってください。
コメント中に「Gemを作る」という言葉がありますが、意味合いがおかしくなってしまいますね。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/10/05 13:11

    seedの使い方を誤解していらっしゃるようです。
    seedはテーブルの構築ではなく、データの挿入での利用になります。
    migrationファイルと同じものを書くのではなく、migrationでDB構築が終わったあとに初期データを入れる手順としてseedを使います。

    キャンセル

  • 2018/10/05 13:18

    つまりスキーマの構築には既存のマイグレーションを使う
    ということでしょうか

    そうなると
    >発生している問題
    既存のマイグレーションは途中で手動で変更されたせいなのか一部マイグレーションに失敗します

    の問題があり既存のマイグレーションを流用できない事情があるのです
    なので既存のスキーマないしはMySQL自体から同じスキーマを構築することが必要になるのです><
    これも固有事情になるのですよね…  申しわけありません

    キャンセル

  • 2018/10/05 18:09

    あー、そうですね。
    途中でマイグレーションが失敗する場合は
    ファイル自体を直すか、質問者様の仰るようにダンプして復旧になりそうですね。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.64%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る