Mastodonマイグレーションガイド日本語訳（意訳）

意訳につき、細部の正確性についてはご勘弁ください。

翻訳元はこちら：
https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Migration-guide.md

マイグレーションガイド

さまざまな理由で、あるサーバーから別のサーバーに Mastodon インスタンスを移行することがあります。
幸運にも移行作業はそれ程難解な手順を踏みませんが、幾許かのダウンタイムが発生する可能性があります。

注意： このガイドは Ubuntu Server 16.04 を前提に書かれています。 他の設定環境では労力が異なる場合があります。

基本手順

1. Production Guide を参照して新たなMastodonをセットアップします（ただし、db:setup は行わないでください）
2. 移行元のサーバ上の Mastodon を停止してください（例えば、systemctl stop 'mastodon-*.service'　とか）
3. 詳細手順に記す方法で PostgreSQL データベースをダンプしてリストアします
4. 同様に、詳細手順に記す方法で system/ 以下のファイルをコピーします
5. 各ユーザのホームのタイムラインを再構築するために、 RAILS_ENV=production bundle exec rails mastodon:feeds:build を実行します
6. 移行先のサーバ上で Mastodon を開始します
7. 移行先のサーバを参照するように、DNSを更新します
8. nginx の設定を更新ないしは複製し、必要に応じて Let's Encrypt から証明書を再取得します
9. 移行先で楽しむべし！

詳細手順

移行に必要なデータ

重要な部分として、あなたは以下のものをコピーする必要があります：

• ~/live/public/system ディレクトリ：ここにはユーザがアップロードした画像や動画が含まれています
• Postgres データベース（pg_dumpを使います）
• ~/live/.env.productionファイル：これにはサーバの設定や秘密鍵が含まれます

あまり重要ではありませんが、便宜上以下のものもコピーしたいでしょう：

• nginx の設定ファイル（/etc/nginx/sites-available/default 以下）
• systemd の設定ファイル（/etc/systemd/system/mastodon-*.service 以下）：これはサーバ毎に微調整やカスタマイズが含まれている可能性があります
• （使っているならば） /etc/pgbouncer 以下にある pgbouncer の設定

Postgres のダンプとリストア

db:setup を実行する代わりに、template0 データベースを使用して空のPostgresデータベースを作成します。（これは pg_dump のドキュメントで説明されているように、Postgresのダンプをリストアするときに便利です）

移行先のシステム上で mastodon ユーザで以下を実行してください：

createdb -T template0 mastodon_production

次に、移行元のシステム上で Postgres のダンプを作成します（引き続き mastodon ユーザで行います）：

pg_dump mastodon_production > dump.sql

上で作成した dump.sql を scp なり rsync なりでコピーしてください。次に、移行元のシステム上で以下を実行します：

psql mastodon_production < dump.sql

この作業は、Postgres上のデータベースを移行元システムから移行先システムにコピーします。 作業中に「"public" の特権を取り消すことができません」という旨の警告が表示されることがありますが、無視しても問題ありません。

（データベースが稼働中などで）ダンプした後に移行元のデータベースが更新された場合は、この作業を再度行う必要が有ることに留意してください。

system/ 以下のファイルコピー

この作業はおそらく時間がかかります。無駄な再コピーを避けるためにも、rsync を使用することをお勧めします。移行元上にて mastodon ユーザーで以下を実行します：

rsync -avz ~/live/public/system/ [e-mail]:~/live/public/system/

転送中に移行元上でファイルが変更された場合はこの作業を再度行う必要が有ります。

この作業で .env.production や nginx や systemd 、 pgbouncer の設定ファイルなど、他の重要なファイルをコピーすることもできます。

移行中

既存ユーザに移行中であることを知らせるナイスなエラーメッセージを表示したい場合、移行元の ~/live/public/500.html ページを編集できます。

前日にあらかじめ DNS の TTL を約30分から60分と小さくしておけば、新しいIPアドレスを指定するとすぐに DNS を伝播させることもできます。

移行後

whatsmydns.net　をチェックすると、DNSの「浸透」の進行状況を確認できます。この処理を開始するには、自身の /etc/hosts ファイルを編集して新しいサーバーを指すようにしてください。

自分用メモ

• マイグレーションを行う時は同一リリース間が望ましい
• 移行先で新たなリリースバージョンを運用する場合は、空のセットアップを行った後で Postgresの内容をいじって db:migrate するべき？　
• このタイミングで .env.production を修正するのもアリ（S3/Swift化などをするとか）だが、まずは同一リリース同一設定でマイグレーションした後に修正したほうが望ましい