自分が運用している365shoes.styleはHerokuを使用しています。 そして、mLabアドオンを使用していました。
mLabアドオンはアナウンスがあったように利用できなくなります。
なので、何かしらの方法で移行する必要がありました。
移行先は一番移行が楽そうな、MongoDB Atlasを選びました。
MongoDB AtlasはmLabからの移行をサポートしています。
https://docs.mlab.com/how-to-migrate-to-atlas/#complete-migration-wizard-for-specific-deployment
ステージング環境の移行
ステージング環境のMongoDBをMongoDB Atlas側でリンクさせて、手順通りに進めました。
クラスタをタイプを指定し、マイグレーションを実行するとmLabのデータをまるっとMongoDB Atlasの環境に移してくれます。
データの内容を確認した後に、アプリケーションの環境変数を変えて、新しい方のMongoDBのデータベースをアクセスしているか確認します。
接続できるかはマイグレーションのステップで、接続確認をするステップがあるので、そこで接続できれば特に問題ないような気がします。
本番環境の移行
ステージング環境の移行が済んだので、次は本番環境なのですが、ちょっと手順が代わります。
MongoDB Atlasからは一つのDBしかリンクできないようで、一旦ステージングとのリンクを切って、本番用の方にリンクし直す必要があります。
「Disconnect from mLab」というのがあるので、それをクリックすればOKです。
そのあとは、ステージング環境と同じように移行するだけなのですが、下記の2つの問題がありました。
- ステージング環境と同じプロジェクトにしたら、ユーザー名がステージング環境のユーザー名になって、データが正常にインポートできなかった。
- 移行後のユーザーの権限がreadだけになってしまった。
1に関してはユーザー名が本番環境のやつと違うけど、大丈夫なのかなと思いつつ、データインポートの処理を実行したら、データがインポートされないので、試しに別の新しいプロジェクトを作成して、試したところ正常に完了しました。
2に関しては、マイグレーションのステップを途中までやっていて、最後まで完了させなかったのが問題のようです。
データ移行まで終わって、安心したのか最後らへんの1、2ステップを見落としていたような気がします。
途中でタブ閉じちゃったのがよくなかったと思います。
ステップとしては移行元の書き込みを停止させるためにユーザーの権限を読み取り権限だけにするようなプロセスになっているようです。
https://docs.mlab.com/how-to-migrate-to-atlas/#importing-from-source-to-target
移行作業のまとめ
ウィザード形式で移行が進むので手順は楽でとてもよかったです。
その代わり、現状どういう状態なのかを確認して、各ステップでどうならなければならないといけないかを意識して作業しないと見落としがでそうです。
通常では移行作業自体は、手順を整理してこういう細かいことをやるのですが、あらかじめ手順が誰かに用意されている場合、意識することは少ないので気をつけたいです。