Mover um site Discourse para outro VPS usando rsync

Wiki da comunidade Administradores de sistemas
,
21

Olá!

Estou tentando seguir os passos de @scottfsmith. Consigo fazer o rsync. Não é importante para mim obter as alterações mais recentes via rsync, pois estou apenas testando uma nova versão do Linux com meu site existente para ver se todos os meus plugins funcionam. Portanto, não estou fazendo a segunda execução do rsync. Tentar executar ./launcher rebuild app produz erros.

2022-12-13 14:43:01.974 UTC [59] LOG:  o sistema de banco de dados foi interrompido; última interrupção conhecida em 2022-12-13 10:23:29 UTC
2022-12-13 14:43:02.075 UTC [59] LOG:  registro de checkpoint primário inválido
2022-12-13 14:43:02.075 UTC [59] PANIC:  não foi possível localizar um registro de checkpoint válido
2022-12-13 14:43:03.137 UTC [56] LOG:  processo de inicialização (PID 59) foi terminado pelo sinal 6: Abortado
2022-12-13 14:43:03.137 UTC [56] LOG:  abortando inicialização devido a falha no processo de inicialização
2022-12-13 14:43:03.231 UTC [56] LOG:  sistema de banco de dados está desligado
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: erro: não foi possível conectar ao banco de dados template1: não foi possível conectar ao servidor: Arquivo ou diretório inexistente
	O servidor está em execução localmente e aceitando
	conexões no soquete de domínio 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: erro: não foi possível conectar ao servidor: Arquivo ou diretório inexistente
	O servidor está em execução localmente e aceitando
	conexões no soquete de domínio 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: erro: não foi possível conectar ao servidor: Arquivo ou diretório inexistente
	O servidor está em execução localmente e aceitando
	conexões no soquete de domínio 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: erro: não foi possível conectar ao servidor: Arquivo ou diretório inexistente
	O servidor está em execução localmente e aceitando
	conexões no soquete de domínio 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 -- : Terminando processos assíncronos

Não consigo entender o suficiente disso para encontrar uma solução. Algumas pesquisas sugerem que o contêiner precisa ser parado, mas ele não está iniciado. Alguma ideia?

Obrigado
David

22

Eu configuraria um servidor de staging para resolver seu problema específico.

A partir desses erros, parece que o banco de dados está quebrado. Você precisa parar o banco de dados para conseguir um conjunto de dados válido para que ele funcione. O segundo rsync não é opcional.

1 curtida
23

Uau!

Um tópico de quatro anos e uma resposta em 3 minutos! :slight_smile:

De qualquer forma, é basicamente um servidor de staging que estou visando e usando este método rsync. Mas você recomenda não fazer isso dessa forma com rsync, mas usar um backup? Lembro-me de não ter obtido todas as configurações de Personalização de um servidor de staging anterior que configurei, mas talvez eu esteja enganado.

Obrigado

1 curtida
24

É isso que esse link descreve.

Tudo, exceto os plugins (que estão em seu app.yml), está no backup; o banco de dados e os uploads são tudo o que há.

1 curtida
25

Pelo meu teste deste método, parece ser suficiente executar ./launcher stop app antes do rsync inicial. Claro, uma das razões para usar este método parece ser manter o fórum rodando no servidor antigo o máximo possível, caso em que é obviamente necessário executar o segundo rsync para manter a consistência. Mas para o processo relativamente comum de mover um fórum para um servidor e/ou host diferente, onde uma breve inatividade é aceitável, eu realmente gosto da simplicidade e portabilidade deste método.

1 curtida
26

Certo.

Certo.

Meu método preferido é fazer o rsync das coisas do let’s encrypt e ssl, colocar o servidor antigo em modo somente leitura, fazer backup, restaurar no novo servidor e, em seguida, trocar o DNS (ou melhor, um IP estático quando o novo servidor estiver pronto).

Mas se você não se importa com um pouco de tempo de inatividade, o seu jeito é ótimo.

2 curtidas
27

Estou planejando migrar para um novo VPS em janeiro, após alguns problemas recentes na atualização do Discourse no meu antigo Ubuntu.

Minhas perguntas sobre a migração de um antigo droplet da Digital Ocean para um novo droplet da Digital Ocean são:

  • Planejo diminuir o TTL do registro DNS A no dia anterior à minha migração para algo pequeno, como 5 minutos. Isso parece razoável?

  • O primeiro post neste tópico foi editado pela última vez em junho de 2016. Ele ainda é válido e correto?

  • Este método rsync também copiará todo o banco de dados do VPS antigo para o novo VPS?
    – Estamos em uma instalação padrão

  • O certificado SSL Let’s Encrypt existente também será copiado? O certificado SSL está vinculado ou associado a um endereço IP de alguma forma? Ele continuará a se renovar automaticamente? Algum problema aqui?

  • Em que ponto devo alterar o registro DNS A público para apontar para o novo VPS?
    – E também alterar o TTL de volta para algo maior novamente

28

Está tudo correto.

Se você estiver usando algo que permita ter um IP permanente que possa ser atribuído a várias VMs, então você pode fazer isso para não depender do DNS para fazer a troca.

A única cautela que eu adicionaria é desligar o site antigo para o rsync final e, em seguida, reiniciá-lo em modo somente leitura enquanto o novo é reconstruído.

29

A primeira postagem ainda mostra o caminho incorreto /var/discourse/:

Você poderia editar/atualizar, por favor?

30

@Richie, @JammyDodger agora transformou isso em uma wiki :+1:

2 curtidas
31

Migrei para um novo VPS hoje e pensei em compartilhar minhas experiências, já que parece que muitas pessoas estão encontrando o bloqueador de sistema operacional de versão antiga em suas atualizações ultimamente :blush:

Estou no Digital Ocean, então criei um novo droplet.

VPS antigo = Ubuntu Server 18.04.6 LTS

Novo VPS = Ubuntu Server 23.10

Fiz a manutenção usual no novo VPS - por favor, edite para seu próprio uso:

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

Em seguida, criei um novo diretório vazio para o Discourse:

sudo mkdir -p /var/discourse

Então instalei o Docker:

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

Em seguida, alterei o TTL do meu DNS de 30 minutos para 10 minutos (o mínimo que o GoDaddy permite).

No meu servidor antigo, baixei uma cópia local do backup do banco de dados do Discourse da noite passada (você nunca pode ter backups locais suficientes). Também baixei uma cópia do app.yml para o meu PC local.

Como sugerido por algumas pessoas acima, fiz um rsync “root-to-root”. Usei o endereço IP em vez do nome do host, para evitar qualquer confusão de DNS. Também, como sugerido acima, usei as opções -avz:

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

Para referência, minha pasta do discourse tem 25 GB.

Levou ~25 minutos para fazer o rsync do servidor antigo para o novo servidor. Isso foi simplesmente entre dois droplets do Digital Ocean na mesma região LON1. Suas experiências podem variar.

Após o rsync e tentar uma reconstrução, encontrei o mesmo erro que o @piratdavid encontrou sobre o postgres database system is shut down.

Então parei o aplicativo no VPS antigo:

./launcher stop app

E fiz outro rsync, apenas para as alterações desta vez:

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

Em seguida, iniciei o aplicativo Discourse antigo novamente e muito rapidamente o coloquei em Modo de Manutenção - isso é para que as pessoas ainda possam acessá-lo e verão a mensagem de aviso de manutenção usual.

Isso também me dá tempo para trabalhar no novo VPS :blush:

Atualizei meu arquivo HOSTS no meu PC local para que eu pudesse acessar o discourse no novo VPS sem avisos/problemas no navegador.

No novo VPS, executei:

./discourse-setup

Isso foi para que ele pudesse atualizar as configurações de RAM e CPU no arquivo app.yml automaticamente.

Em seguida, fiz uma reconstrução do aplicativo no novo VPS:

./launcher rebuild app

Fiz alguns testes de fumaça, tudo bem.

DNS atualizado - trabalho feito.

Obrigado pelo tópico detalhado, pessoal :smiley:

4 curtidas
32

Obrigado pessoal, primeira postagem atualizada sobre os caminhos /var/discourse.

1 curtida
33

Se alguém estiver tendo problemas para fazer o rsync de root para root porque talvez tenha desabilitado o login de root no servidor antigo, ou você apenas queira fazer isso como um usuário não root, achei esta postagem útil para descobrir como usar o sudo no servidor remoto: https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

Vamos dizer que você tenha um usuário, discourse, em ambos os lados que tenha privilégios de sudo. Na máquina remota, você editará o arquivo /etc/sudoers com sudo visudo. Você adicionará a linha:

discours TODOS=NOPASSWD:/usr/bin/rsync

Então, na nova máquina, você executará (como seu usuário não root):

sudo rsync -avz --delete --rsync-path="sudo rsync" discourse@endereço.ip.antigo.aqui:/var/discourse /var

Isso permitirá que você execute tudo o que é descrito aqui como usuários não root. Se você for manter o servidor antigo, eu voltaria ao arquivo /etc/sudoers e excluiria a linha que você acabou de inserir.

1 curtida
34

Se entendi corretamente, isso permite que a maior parte da transferência ocorra enquanto o Discourse está em execução. A estratégia de restauração a partir de backup requer pelo menos acesso somente leitura para o backup e a movimentação do backup para o novo servidor (ou transferência via bucket S3). Para sites grandes, isso pode resultar em um tempo considerável somente leitura que a estratégia rsync evita perfeitamente.

Pode ser possível otimizar um pouco mais o tempo de atividade evitando o desligamento do PostgreSQL no sistema antigo e “corrigindo” o problema no novo sistema com pg_resetwal. NB: Não tentei isso e deixar o banco de dados desligar graciosamente é quase certamente uma ideia melhor.

Eu me pergunto se há uma maneira de iniciar o Discourse em modo somente leitura? Suspeito que a maneira mais rápida seja via linha de comando após o contêiner estar em execução.

De qualquer forma, obrigado por compartilhar sua experiência! Parece um processo útil para ter em mente. :slight_smile:

35

Muito.

Tão útil, na verdade, que estou tentado a fazer tudo de novo para criar um ambiente de staging (em um VPS de especificações inferiores), apenas para testar e prever quaisquer problemas antes de implementar quaisquer alterações na produção.

1 curtida
37

Olá,

Estou no meio de tentar este processo em uma instância mais antiga do Discourse pela qual sou responsável pela manutenção – migrando do Ubuntu EOL para algo mais recente porque qualquer atualização falha se eu tentar fazer isso no local – e embora o rsync tenha sido bem-sucedido, o postgres está falhando ao iniciar citando problemas de propriedade de arquivos. Executar o rsync como root com as opções de preservação de propriedade não corrigiu isso (a propriedade e as permissões dos arquivos agora correspondem à origem, verifiquei), e como o bootstrap falhou e não tenho um contêiner em execução, não posso tentar corrigir isso como Update failed (postgresql) - #7 by noezDE descreve.

Qual é a melhor maneira de normalizar o que quer que o postgres esteja esperando?

38

Você pode chown os arquivos fora do contêiner? Deve ser possível se você tiver permissões de root/sudo.

39

Sim, mas para quê? Fora do contêiner, as permissões estão corretas e também são um absurdo.

Fonte (funcionando):

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

Destino (quebrado):

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

Estou assumindo que esses IDs podem fazer mais sentido dentro do contêiner, talvez?

40

Sim, tentei a força bruta dos IDs numéricos de ls -aln e ainda recebo a mesma falha.

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

Eu não sei o que ele quer.

41

Acho que tive um erro semelhante recentemente.

Uma suposição é que o contêiner antigo e o novo tenham entradas /etc/passwd diferentes. Você poderia comparar esses arquivos, eu acho.

Acho que sua melhor opção pode ser restaurar a partir do backup. Não me lembro se fiz isso ou se o v fez algo 777.