Move a Discourse site to another VPS with rsync

コミュニティWiki システム管理者
,
21

こんにちは！

@scottfsmithさんの手順に従おうとしています。rsyncは完了しました。新しいLinuxバージョンで既存のサイトをテストして、すべてのプラグインが機能するかどうかを確認しているだけなので、rsyncで最新の変更を取得することは重要ではありません。そのため、rsyncの2回目の実行は行っていません。その後、./launcher rebuild appを実行しようとするとエラーが発生します。

2022-12-13 14:43:01.974 UTC [59] LOG:  データベースシステムが中断されました。最後に確認された起動時刻は 2022-12-13 10:23:29 UTC です。
2022-12-13 14:43:02.075 UTC [59] LOG:  無効なプライマリチェックポイントレコード
2022-12-13 14:43:02.075 UTC [59] PANIC:  有効なチェックポイントレコードが見つかりませんでした
2022-12-13 14:43:03.137 UTC [56] LOG:  起動プロセス (PID 59) はシグナル 6: 中断 により終了しました。
2022-12-13 14:43:03.137 UTC [56] LOG:  起動プロセスの失敗により起動を中止します。
2022-12-13 14:43:03.231 UTC [56] LOG:  データベースシステムはシャットダウンされています。
I, [2022-12-13T14:43:06.699692 #1]  INFO -- :
I, [2022-12-13T14:43:06.711862 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
createdb: エラー: データベース template1 に接続できませんでした: サーバーに接続できませんでした: No such file or directory
        サーバーがローカルで実行されており、Unix ドメインソケット "/var/run/postgresql/.s.PGSQL.5432" で接続を受け付けていますか？
I, [2022-12-13T14:43:06.917008 #1]  INFO -- :
I, [2022-12-13T14:43:06.917421 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql: エラー: サーバーに接続できませんでした: No such file or directory
        サーバーがローカルで実行されており、Unix ドメインソケット "/var/run/postgresql/.s.PGSQL.5432" で接続を受け付けていますか？
I, [2022-12-13T14:43:07.007654 #1]  INFO -- :
I, [2022-12-13T14:43:07.008155 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql: エラー: サーバーに接続できませんでした: No such file or directory
        サーバーがローカルで実行されており、Unix ドメインソケット "/var/run/postgresql/.s.PGSQL.5432" で接続を受け付けていますか？
I, [2022-12-13T14:43:07.087098 #1]  INFO -- :
I, [2022-12-13T14:43:07.087319 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql: エラー: サーバーに接続できませんでした: No such file or directory
        サーバーがローカルで実行されており、Unix ドメインソケット "/var/run/postgresql/.s.PGSQL.5432" で接続を受け付けていますか？
I, [2022-12-13T14:43:07.167221 #1]  INFO -- :
I, [2022-12-13T14:43:07.168041 #1]  INFO -- : 非同期プロセスを終了します。

これだけでは解決策を見つけるのに十分な情報がありません。検索すると、コンテナを停止する必要があるという提案がありますが、起動していません。何かアイデアはありますか？

よろしくお願いします。
David

22

その特定の問題を解決するために、ステージングサーバーをセットアップすることをお勧めします。

これらのエラーから、データベースが破損しているようです。データベースを停止して、正常に機能するための有効なデータセットを取得する必要があります。2番目のrsyncはオプションではありません。

「いいね！」 1
23

すごい！

4年前のスレッドに3分以内に返信があるなんて！ :slight_smile:

とにかく、これは基本的にステージングサーバーを対象としており、このrsyncメソッドを使用しています。しかし、rsyncでこの方法を使用するのではなく、バックアップを使用することをお勧めしますか？以前設定したステージングサーバーからすべてのカスタマイズ設定を取得できなかったことを思い出しましたが、間違っているかもしれません。

ありがとうございます

「いいね！」 1
24

そのリンクに記載されているのはそれです。

プラグイン（app.ymlにあります）を除き、すべてバックアップに含まれています。データベースとアップロードのみです。

「いいね！」 1
25

この方法のテストから、最初のrsyncの前に./launcher stop appを実行するだけで十分なようです。もちろん、この方法を使用する理由の1つは、古いサーバーでフォーラムをできるだけ長く実行し続けることであるため、一貫性を維持するために2番目のrsyncを実行することが明らかに必要です。しかし、フォーラムを別のサーバーやホストに移動するという比較的一般的なプロセスで、短いダウンタイムが許容される場合、この方法のシンプルさと移植性が本当に気に入っています。

「いいね！」 1
26

その通りです。

その通りです。

私が推奨する方法は、Let’s Encrypt と SSL の同期を行い、古いサーバーを読み取り専用モードにし、バックアップを取得し、新しいサーバーに復元してから、DNS を切り替える（または、新しいサーバーが準備できたら静的 IP を使用する方が良い）というものです。

しかし、多少のダウンタイムを気にしないのであれば、あなたの方法で十分です。

「いいね！」 2
27

1月に、古いUbuntuでDiscourseのアップグレードに失敗したという問題が発生したため、新しいVPSに移行する予定です。

古いDigital Oceanのドロップレットから新しいDigital Oceanのドロップレットへ移行するにあたって、いくつか質問があります。

  • 移行の前日にDNS AレコードのTTLを5分のような短い値に下げる予定ですが、これは妥当でしょうか？

  • このスレッドの最初の投稿は2016年6月に編集されていますが、これはまだ有効で正しいでしょうか？

  • このrsyncの方法で、古いVPSから新しいVPSへデータベース全体をコピーできますか？
    – 標準インストールを使用しています。

  • 既存のLet’s Encrypt SSL証明書もコピーされますか？ SSL証明書はIPアドレスに紐付けられていますか？自動更新は継続されますか？何か注意点があれば教えてください。

  • 公開DNS Aレコードを新しいVPSに向けるのはどのタイミングで行うべきでしょうか？
    – また、TTLを再び高い値に戻すのはいつ行えばよいでしょうか？

28

すべて正しいです。

永続的なIPを複数のVMに割り当てることができるものを使用している場合は、DNSに依存して切り替えを行う必要がないため、それを行うことができます。

追加する唯一の注意点は、最終的なrsyncのために古いサイトをシャットダウンし、新しいサイトが再構築されている間、読み取り専用モードで再起動することです。

29

最初の投稿では、まだ /var/discourse/ のパスが間違って表示されています。

編集/更新をお願いできますか？

30

@Richie、@JammyDodgerがこれをウィキにしました :+1:

「いいね！」 2
31

本日、新しいVPSに移行したのですが、最近多くの人がアップデート時に古いバージョンのオペレーティングシステムでブロックされているようなので、私の経験を共有したいと思います :blush:

Digital Ocean を利用しているので、新しいドロップレットを作成しました。

古いVPS = Ubuntu Server 18.04.6 LTS

新しいVPS = Ubuntu Server 23.10

新しいVPSで通常のメンテナンスを行いました。ご自身で編集してください。

Apt-get update

Apt-get upgrade

Apt-get install fail2ban

ufw default deny incoming

ufw default allow outgoing

ufw allow ssh

ufw allow http

ufw allow https

ufw enable

次に、Discourse 用の新しい空のディレクトリを作成しました。

sudo mkdir -p /var/discourse

次に Docker をインストールしました。

wget -qO- https://get.docker.com/ | sh

次に、DNS の TTL を 30 分から 10 分に変更しました (GoDaddy で許可される最小値)。

古いサーバーでは、昨夜の Discourse データベースバックアップのローカルコピーをダウンロードしました (ローカルバックアップはいくらあっても困りません)。また、app.yml のコピーもローカル PC にダウンロードしました。

上記の数名が提案したように、「root-to-root」rsync を実行しました。ホスト名ではなく IP アドレスを使用したため、DNS の混乱を避けることができました。また、上記で提案されたように -avz スイッチを使用しました。

rsync -avz root@old.ip.address.here:/var/discourse /var

参考までに、私の discourse フォルダーは 25GB です。

rsync は古いサーバーから新しいサーバーへの転送に約 25 分かかりました。これは、同じ LON1 リージョン内の 2 つの Digital Ocean ドロップレット間でのみ行われました。皆様の経験は異なる場合があります。

rsync 後に再構築を試みたところ、@piratdavid が遭遇したのと同じエラー https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/21?u=richie に遭遇しました。postgres の database system is shut down というエラーです。

そこで、古い VPS でアプリを停止しました。

./launcher stop app

そして、変更点のみを対象に再度 rsync を実行しました。

rsync -avz --delete root@old.ip.address.here:/var/discourse /var

その後、古い Discourse アプリを再度起動し、すぐにメンテナンスモードに入れました。これにより、ユーザーはアクセスでき、通常のメンテナンス警告メッセージが表示されます。

これにより、新しい VPS で作業する時間ができました :blush:

ローカル PC の HOSTS ファイルを更新し、ブラウザの警告や問題なしに新しい VPS の discourse にアクセスできるようにしました。

新しい VPS で以下を実行しました。

./discourse-setup

これにより、app.yml ファイルの RAM と CPU 設定が自動的に更新されました。

その後、新しい VPS でアプリの再構築を行いました。

./launcher rebuild app

簡単なテストを実行し、すべて問題ありませんでした。

DNS を更新し、完了です。

詳細なトピックをありがとうございました。皆様 :smiley:

「いいね！」 4
32

ありがとう、最初の投稿を /var/discourse パスについて更新しました。

「いいね！」 1
33

古いサーバーでrootログインを無効にしている場合や、単に非rootユーザーでrsyncを実行したい場合で、rootからrootへのrsyncに問題がある場合は、リモートサーバーでsudoを使用する方法を理解するのに、この投稿が役立つことがわかりました: https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

両方のサーバーにsudo権限を持つdiscourseというユーザーがいるとします。リモートマシンでは、sudo visudoを使用して/etc/sudoersファイルを編集します。次の行を追加します。

discourse ALL=NOPASSWD:/usr/bin/rsync

次に、新しいマシンで（非rootユーザーとして）次を実行します。

sudo rsync -avz --delete --rsync-path="sudo rsync" discourse@old.ip.address.here:/var/discourse /var

これにより、ここに記載されているすべてのアクションを非rootユーザーとして実行できるようになります。古いサーバーを保持する場合は、/etc/sudoersファイルに戻り、追加した行を削除することをお勧めします。

「いいね！」 1
34

理解したところによると、これにより、Discourseが実行されている間に転送の大部分を行うことができます。バックアップからの復元戦略では、バックアップの読み取り専用アクセスと、バックアップを新しいサーバーに移動すること（またはS3バケット経由での転送）が必要です。大規模なサイトの場合、これによりかなりの読み取り専用時間が発生する可能性がありますが、rsync戦略ではこれをうまく回避できます。

古いシステムでPostgreSQLをシャットダウンせずに、新しいシステムで"問題を修正する"ことで、もう少し稼働時間を確保できる可能性があります。注意: これは試していません。データベースを正常にシャットダウンさせる方が、ほぼ間違いなく良い方法です。

Discourseを読み取り専用で起動する方法があるのだろうか？コンテナが実行された後、コマンドライン経由で最も速く行うことができると推測しています。

いずれにせよ、あなたの経験を報告してくれてありがとう！ポケットに入れておくと便利なプロセスのように思えます。 :slight_smile:

35

Very.

So useful in fact, that I’m tempted to do it all again to create a staging environment (on a lower spec’d VPS), just for testing and preempting any issues before implementing any changes on production.

「いいね！」 1
37

こんにちは。

現在担当している古いDiscourseインスタンスでこのプロセスを試していますが、EOLを迎えたUbuntuから新しいものへ移行しようとしています。インプレースアップグレードはすべて失敗するためです。rsyncは成功しましたが、postgresはファイルの所有権の問題を理由に起動に失敗しています。rootとして所有権を保持するオプションを付けてrsyncを実行しても、これは修正されませんでした（ファイルの所有権とパーミッションはソースと一致するようになりました。確認済みです）。また、ブートストラップが失敗し、実行中のコンテナがないため、Update failed (postgresql) - #7 by noezDE に記載されているような修正を試すことができません。

postgresが期待しているものを正規化する最善の方法は何でしょうか？

38

コンテナの外にあるファイルを chown できますか？ルート/sudo 権限があれば可能です。

39

はい、しかし何に対してでしょうか？コンテナの外からは、権限は正しく、かつ全く意味不明です。

ソース（正常）:

root@ip-[...]:/var/discourse/shared/standalone# ls
total 54492
drwxr-xr-x 15 root       root         4096 Oct 22  2021 .
drwxr-xr-x  3 root       root         4096 Feb 28  2017 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Feb 28  2017 backups
-rw-r--r--  1 root       root     55730645 Mar 15  2017 discussion.json
drwx------  7 root       root         4096 Mar  6  2017 letsencrypt
drwxr-xr-x  4 root       root         4096 Feb 28  2017 log
drwxr-xr-x  2 _apt       netdev       4096 Feb 28  2017 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:39 postgres_data
drwx------ 20 _apt       netdev       4096 Oct 22  2021 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Apr  5  2018 postgres_data_older
drwxrwsr-x  5 _apt       netdev       4096 Sep 15 04:39 postgres_run
drwxr-xr-x  2 lxd        lxd          4096 Sep 16 01:03 redis_data
drwxr-xr-x  2 root       root         4096 Mar  6  2017 ssl
drwxr-xr-x  4 root       root         4096 Feb 28  2017 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:39 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Apr 13  2017 uploads

宛先（破損）:

root@ip-[...]:/var/discourse/shared/standalone# ls -al
total 54488
drwxr-xr-x 15 root       root         4096 Sep 15 04:31 .
drwxr-xr-x  3 root       root         4096 Sep 15 04:27 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Sep 15 04:27 backups
-rw-r--r--  1 root       root     55730645 Sep 15 04:27 discussion.json
drwx------  7 root       root         4096 Sep 15 04:27 letsencrypt
drwxr-xr-x  4 root       root         4096 Sep 15 04:27 log
drwxr-xr-x  2 _apt       netdev       4096 Sep 15 04:27 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:27 postgres_data
drwx------ 20 _apt       netdev       4096 Sep 15 04:30 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Sep 15 04:31 postgres_data_older
drwxrwsr-x  5 messagebus tss          4096 Sep 15 04:31 postgres_run
drwxr-xr-x  2 uuidd      _ssh         4096 Sep 15 04:38 redis_data
drwxr-xr-x  2 root       root         4096 Sep 15 04:32 ssl
drwxr-xr-x  4 root       root         4096 Sep 15 04:31 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:31 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Sep 15 04:31 uploads

これらのIDはコンテナ内ではより意味のあるものになるのではないでしょうか？

40

ls -aln から数値 ID を総当たりで試しましたが、同じエラーが発生します。

2024-09-16 01:21:27.237 UTC [36] FATAL:  data directory "/shared/postgres_data" has wrong ownership

一体どうすればいいのか分かりません。

41

最近、同様のエラーが発生したと思います。

1つの推測ですが、古いコンテナと新しいコンテナで /etc/passwd のエントリが異なる可能性があります。それらのファイルを比較できると思います。

最善策はバックアップから復元することだと思います。バックアップから復元したのか、それとも何かを 777 にしたのか、思い出せません。