Move a Discourse site to another VPS with rsync

[piratdavid]

Привет!

Я пытаюсь следовать инструкциям от @scottfsmith. Мне удалось выполнить rsync. Для меня не критично получить самые последние изменения через rsync, так как я просто тестирую новую версию Linux с моим существующим сайтом, чтобы проверить, работают ли все мои плагины. Поэтому я не выполняю второй запуск rsync. Затем при попытке выполнить ./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: Aborted
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: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	подключения через 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: ошибка: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	подключения через 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: ошибка: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	подключения через 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: ошибка: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	подключения через 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 -- : Завершение асинхронных процессов

Я не могу понять достаточно из этого, чтобы найти решение. Некоторые поисковые запросы предполагают, что контейнер нужно остановить, но он даже не запущен. Есть какие-либо идеи?

Спасибо,
Дэвид

[pfaffman (Jay Pfaffman)]

Я бы настроил тестовый сервер, чтобы решить вашу конкретную проблему.

Судя по этим ошибкам, база данных повреждена. Вам нужно остановить базу данных, чтобы получить корректный набор данных для её работы. Вторая команда rsync не является опциональной.

[piratdavid]

Вау!

Тема четырёхлетней давности, а ответ уже через 3 минуты!

В любом случае, я настраиваю тестовый сервер и использую этот метод с rsync. Но вы бы не рекомендовали делать так с rsync, а лучше использовать резервное копирование? Помню, что при настройке предыдущего тестового сервера не все настройки Customize перенеслись, но, возможно, я ошибаюсь.

Спасибо

[pfaffman (Jay Pfaffman)]

@piratdavid

Но вы рекомендуете не делать это таким образом с помощью rsync, а использовать резервную копию?

Именно это и описано по той ссылке.

@piratdavid

Я помню, что не получил все настройки Customize с предыдущего staging-сервера, который настроил, но, возможно, я ошибаюсь.

Всё, кроме плагинов (которые находятся в вашем app.yml), содержится в резервной копии; база данных и загруженные файлы — это всё, что там есть.

[rahim123]

@Jay Pfaffman

Второй rsync не является опциональным.

По моим тестам этого метода, достаточно выполнить ./launcher stop app перед начальным rsync. Конечно, одна из причин использования этого метода — поддерживать работу форума на старом сервере как можно дольше, в таком случае, очевидно, необходимо выполнить второй rsync для обеспечения согласованности. Но для относительно распространенной задачи переноса форума на другой сервер и/или хостинг, где кратковременный простой допустим, мне очень нравится простота и портативность этого метода.

[pfaffman (Jay Pfaffman)]

@rahim123

Кажется, достаточно выполнить ./launcher stop app перед начальным rsync.

Верно.

@rahim123

Причины использовать этот метод, похоже, заключаются в том, чтобы как можно дольше поддерживать работу форума на старом сервере.

Верно.

Мой предпочтительный способ — сначала выполнить rsync для Let’s Encrypt и SSL-файлов, перевести старый сервер в режим только для чтения, сделать резервную копию, восстановить её на новом сервере, а затем переключить DNS (или, что ещё лучше, использовать статический IP, когда новый сервер будет готов).

Но если вас не беспокоит небольшое время простоя, ваш способ отличный.

[Richie (Richie Rich)]

Я планирую миграцию на новый VPS в январе после некоторых недавних проблем с обновлением Discourse на моём старом Ubuntu.

У меня есть следующие вопросы по миграции со старого Droplet от Digital Ocean на новый:

• Я планирую снизить TTL для DNS A-записи за день до миграции до небольшого значения, например 5 минут. Это разумно?

• Первое сообщение в этой теме было отредактировано в июне 2016 года. Актуальна ли эта информация и верна ли она до сих пор?

• Будет ли метод rsync также копировать всю базу данных со старого VPS на новый?
  – У нас стандартная установка.

• Будет ли перенесён существующий SSL-сертификат Let’s Encrypt? Привязан ли SSL-сертификат к IP-адресу каким-либо образом? Будет ли он автоматически обновляться? Есть ли здесь какие-либо подводные камни?

• В какой момент мне следует изменить публичную DNS A-запись, чтобы она указывала на новый VPS?
  – А также снова увеличить TTL до большего значения.

[pfaffman (Jay Pfaffman)]

Всё верно.

Если вы используете решение, позволяющее назначить постоянный IP-адрес нескольким виртуальным машинам, то можете сделать именно так, чтобы не полагаться на DNS при переключении.

Единственное, о чём я бы хотел предупредить: перед финальной синхронизацией rsync остановите старый сайт, а затем запустите его в режиме только для чтения, пока новый сайт восстанавливает данные.

[Richie (Richie Rich)]

@mrjn

На самом деле это должно быть:
rsync -rvz example.com:/var/discourse /var

@SystemZ

Да, моя ошибка, забыл добавить слеши.
Отредактировал и исправил

В первом посте всё ещё отображается неверный путь /var/discourse/:

@SystemZ

На нашем новом VPS выполним

rsync -rvz example.com:/var/discourse/ /var/discourse/

Не могли бы вы отредактировать или обновить?

[merefield (Robert)]

@Richie, @JammyDodger теперь сделал это вики

[Richie (Richie Rich)]

Сегодня я переехал на новый VPS и решил поделиться своим опытом, так как, похоже, многие сталкиваются с блокировкой обновлений из-за устаревшей версии операционной системы

Я использую Digital Ocean, поэтому создал новый droplet.

Старый 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

Затем я изменил TTL в DNS с 30 минут до 10 минут (минимум, разрешённый GoDaddy).

На старом сервере я загрузил локальную копию резервной копии базы данных Discourse за прошлую ночь (локальных резервных копий никогда не бывает слишком много). Также я скачал копию app.yml на свой локальный ПК.

Как рекомендовали несколько человек выше, я выполнил rsync «root-to-root». Я использовал IP-адрес вместо имени хоста, чтобы избежать путаницы с DNS. Также, как было предложено выше, я использовал флаги -avz:

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

Для справки: размер моей папки discourse составляет 25 ГБ.

Синхронизация через rsync со старого сервера на новый заняла около 25 минут. Это было выполнено между двумя droplets Digital Ocean в одном регионе LON1. Ваш опыт может отличаться.

После rsync и попытки пересборки я столкнулся с той же ошибкой, что и @piratdavid, связанной с postgres: database system is shut down.

Поэтому я остановил приложение на старом VPS:

./launcher stop app

И выполнил ещё одну синхронизацию через rsync, но только для изменений:

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

Затем я снова запустил старое приложение Discourse и очень быстро перевёл его в режим обслуживания — это позволит пользователям получить к нему доступ и увидеть стандартное предупреждение о техническом обслуживании.

Это также даёт мне немного времени для работы на новом VPS

Я обновил файл HOSTS на своём локальном ПК, чтобы получить доступ к Discourse на новом VPS без предупреждений или проблем в браузере.

На новом VPS я затем выполнил:

./discourse-setup

Это необходимо, чтобы автоматически обновить настройки оперативной памяти и процессора в файле app.yml.

Затем я выполнил пересборку приложения на новом VPS:

./launcher rebuild app

Провёл несколько тестов, всё в порядке.

DNS обновлён — работа завершена.

Спасибо всем за подробную тему

[Richie (Richie Rich)]

@merefield

@Richie, @JammyDodger теперь сделал это вики

Спасибо, ребята, первый пост обновлён относительно путей /var/discourse.

[pcorsaro (Peter Corsaro)]

Если у вас возникли проблемы с выполнением rsync от root к root, возможно, потому что вы отключили вход под root на старом сервере, или вы просто хотите выполнить это как обычный пользователь, я нашел этот пост полезным для понимания того, как использовать sudo на удаленном сервере: https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

Допустим, у вас есть пользователь discourse на обеих сторонах, имеющий права sudo. На удаленной машине вы отредактируете файл /etc/sudoers с помощью sudo visudo. Добавьте строку:

discourse ALL=NOPASSWD:/usr/bin/rsync

Затем на новой машине вы запустите (как обычный пользователь, не root):

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

Это позволит вам выполнять все описанные здесь действия как обычный пользователь. Если вы планируете оставить старый сервер, вернитесь в файл /etc/sudoers и удалите только что добавленную строку.

[jericson (Jon Ericson)]

@Richie

Синхронизация через rsync со старого сервера на новый заняла около 25 минут. Это было сделано просто между двумя инстансами Digital Ocean в одном регионе LON1. Ваш опыт может отличаться.

Если я правильно понимаю, это позволяет основную часть передачи выполнить, пока Discourse продолжает работать. Стратегия восстановления из резервной копии требует как минимум перевода в режим только для чтения для самой резервной копии и её перемещения на новый сервер (или передачи через бакет S3). Для крупных сайтов это может привести к значительному времени простоя в режиме только для чтения, чего удаётся избежать благодаря стратегии rsync.

@Richie

После rsync и попытки пересборки я столкнулся с той же ошибкой, что и @piratdavid: в PostgreSQL database system is shut down.

Возможно, удастся немного увеличить время доступности, не выключая PostgreSQL на старом сервере и «исправив» проблему на новом сервере с помощью pg_resetwal. Важно: я сам это не пробовал, и корректное завершение работы базы данных, скорее всего, является лучшим решением.

@Richie

Затем я снова запустил старое приложение Discourse и очень быстро перевёл его в режим обслуживания — это нужно, чтобы пользователи всё ещё могли получить доступ к сайту и увидели обычное предупреждение о техническом обслуживании.

Интересно, есть ли способ запустить Discourse в режиме только для чтения? Подозреваю, что самый быстрый способ — через командную строку после запуска контейнера.

В любом случае, спасибо за отчёт о вашем опыте! Похоже, это полезный процесс, который стоит иметь под рукой.

[Richie (Richie Rich)]

@jericson

Похоже, это полезный процесс, который стоит иметь под рукой.

Очень полезный.

На самом деле настолько полезный, что я даже склонен повторить всё заново, чтобы создать тестовую среду (на VPS с меньшими характеристиками) исключительно для тестирования и предотвращения любых проблем перед внесением изменений в рабочую среду.

[Asher_Densmore-Lynn]

Здравствуйте,

Я сейчас занимаюсь переносом более старой версии Discourse, за которую теперь отвечаю, с устаревшей Ubuntu на более актуальную, так как любое обновление при попытке выполнить его на месте завершается ошибкой. Хотя rsync прошел успешно, PostgreSQL не запускается, ссылаясь на проблемы с правами владения файлами. Запуск rsync от root с опциями сохранения прав владения не исправил ситуацию (владение файлами и права теперь соответствуют источнику, я проверил), и поскольку загрузка не удалась и у меня нет работающего контейнера, я не могу попытаться исправить это так, как описано здесь: Update failed (postgresql) - #7 by noezDE.

Как лучше всего привести всё в соответствие с тем, что ожидает PostgreSQL?

[jericson (Jon Ericson)]

Можете ли вы изменить владельца (chown) файлов за пределами контейнера? Это должно быть возможно, если у вас есть права root/sudo.

[Asher_Densmore-Lynn]

Конечно, но к чему? Извне контейнера права выглядят одновременно и правильными, и совершенно бессмысленными.

Источник (работающий):

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

Предполагаю, что внутри контейнера эти идентификаторы могут иметь больше смысла, возможно?

[Asher_Densmore-Lynn]

Да, я пытался перебрать числовые идентификаторы из команды ls -aln, но ошибка всё та же.

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

Не понимаю, чего оно хочет.

[pfaffman (Jay Pfaffman)]

Кажется, недавно у меня была похожая ошибка.

Одно предположение: в старом контейнере и в новом записи в файле /etc/passwd различаются. Можно попробовать сравнить эти файлы.

Думаю, лучший вариант — восстановить из резервной копии. Не помню, делал ли я это или просто установил права 777 на что-то.