Closed7

MySQL -> Postgres への移行調査

Teruhisa - T6ADEVTeruhisa - T6ADEV

config.loadファイルを作って以下のものを用意

load database
  from mysql://xxxxxxx:pscale_pw_xxxxxxx@aws.connect.psdb.cloud/mydb?sslmode=require
  into postgresql://xxxx:endpoint=ep-patient-xxxx;xxxx@ep-patient-xxxx.ap-southeast-1.aws.neon.tech/mydb?sslmode=require
  with quote identifiers
  alter schema 'mydb' rename to 'public';

以下を実行(事前にbrew install postgresql, brew install pgloader

pgloader config.load

quote identifiers

MySQLのテーブルやカラム名に大文字を使っている場合、このquote identifiersがないと移行後全て小文字になる。

alter schema 'mydb' rename to 'public'

これがないと移行後のschemaがpublicではなくmydbとして作られてしまう。

Teruhisa - T6ADEVTeruhisa - T6ADEV

試しにこれをするきっかけとなったプロジェクトのDB先を移行後のNeonにしてみた。
アプリ画面を開いてみただけだけど、動いた。動いた・・・(逆に不安)

Prismaでschema定義してて細々Postgres用に変更する必要もあるだろうと思っていたけど。

Teruhisa - T6ADEVTeruhisa - T6ADEV

pgloader後、prisma migrate dev してみた所、差分が出てきてAll data will be lost.がでちゃった。

Teruhisa - T6ADEVTeruhisa - T6ADEV

prismaコマンドだけでゴニョゴニョするのは無理がありそう。
素直にデータだけコピーするほうがいいか・・・

Teruhisa - T6ADEVTeruhisa - T6ADEV

背景:PlanetScale(MySQL)からNeon(Postgres)への変更。DBはprismaで管理。サービスは動かして数名のユーザーが利用中。移行すべきテーブルのデータは”少ない”(実験的なプロダクトなので重要なもの以外は消えても問題ない)。ダウンタイムはあっても問題ない。

案:

  1. pgloaderでNeon(Postgres)へデータをコピー(これは正式な移行としてではない)(pgloaderでmysqlからの変換を任せる)
  2. Neonに対してpg_dumpで必要なデータのみをSQL文でバックアップ
  3. 1.でNeonにDBが出来たが、DBごと全て削除
  4. schema.prismaをNeon用に変更(provider = "postgresql"へ変更, relationMode = "prisma"削除, planetscaleで必要だった@@index()は不要なので削除)
  5. npx prisma migrate dev --name init
  6. 2.のSQL文を使ってデータを流し込む (例psql "postgresql://xxx:xxx@ep-patient-xxx.ap-southeast-1.aws.neon.tech/xxx?sslmode=require" -f ./backup.sql)
    ※2で得られたbackup.sqlの中身は必要なsql文を精査する。外部キーとの兼ね合いも考えて主キーとなるinsert文を先に実行させる
pg_dump --column-inserts -Fp YOUR_DBNAME > backup.sql

--column-inserts :列名指定のINSERTコマンドでデータをダンプ
-F, --format=c|d|t|p : 出力ファイルの形式(custom, directory, tar, plain text(デフォルト))

このスクラップは2024/03/13にクローズされました