Sposta un sito Discourse su un altro VPS con rsync

Wiki della community Amministratori di sistema
,
21

Ciao!

Sto cercando di seguire i passaggi di @scottfsmith. Riesco a completare rsync. Non mi interessa ottenere le modifiche più recenti tramite rsync poiché sto solo testando una nuova versione di Linux con il mio sito esistente per vedere se tutti i miei plugin funzionano. Quindi non eseguo la seconda esecuzione di rsync. Tentare di eseguire ./launcher rebuild app produce errori.

2022-12-13 14:43:01.974 UTC [59] LOG:  il sistema del database è stato interrotto; ultimo avvio noto alle 2022-12-13 10:23:29 UTC
2022-12-13 14:43:02.075 UTC [59] LOG:  record di checkpoint primario non valido
2022-12-13 14:43:02.075 UTC [59] PANIC:  impossibile individuare un record di checkpoint valido
2022-12-13 14:43:03.137 UTC [56] LOG:  processo di avvio (PID 59) è stato terminato dal segnale 6: Abortito
2022-12-13 14:43:03.137 UTC [56] LOG:  avvio interrotto a causa di errore del processo di avvio
2022-12-13 14:43:03.231 UTC [56] LOG:  il sistema del database è spento
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: errore: impossibile connettersi al database template1: impossibile connettersi al server: Nessun file o directory
	Il server è in esecuzione localmente e accetta
	connessioni sul socket di dominio 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: errore: impossibile connettersi al server: Nessun file o directory
	Il server è in esecuzione localmente e accetta
	connessioni sul socket di dominio 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: errore: impossibile connettersi al server: Nessun file o directory
	Il server è in esecuzione localmente e accetta
	connessioni sul socket di dominio 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: errore: impossibile connettersi al server: Nessun file o directory
	Il server è in esecuzione localmente e accetta
	connessioni sul socket di dominio 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 -- : Terminazione processi asincroni

Non riesco a capire abbastanza da trovare una soluzione. Alcune ricerche suggeriscono che il container debba essere fermato ma non è avviato. Qualche idea?

Grazie
David

22

Vorrei impostare un server di staging per risolvere il tuo problema specifico.

Da quegli errori, sembra che il database sia danneggiato. Devi arrestare il database per poter ottenere un set di dati valido affinché funzioni. Il secondo rsync non è facoltativo.

1 Mi Piace
23

Wow!

Un thread di quattro anni e una risposta in 3 minuti! :slight_smile:

Comunque, fondamentalmente sto puntando a un server di staging e sto usando questo metodo rsync. Ma mi consigli di non farlo in questo modo con rsync ma di usare un backup? Ricordo di non aver ottenuto tutte le impostazioni di personalizzazione da un precedente server di staging che avevo configurato, ma forse mi sbaglio.

Grazie

1 Mi Piace
24

Questo è ciò che descrive quel link.

Tutto, tranne i plugin (che sono nel tuo app.yml), è nel backup; il database e i caricamenti sono tutto ciò che c’è.

1 Mi Piace
25

Dai miei test di questo metodo sembra sufficiente eseguire ./launcher stop app prima dell’rsync iniziale. Naturalmente, uno dei motivi per utilizzare questo metodo sembra essere quello di mantenere il forum in esecuzione sul vecchio server il più a lungo possibile, nel qual caso è ovviamente necessario eseguire il secondo rsync per mantenere la coerenza. Ma per il processo relativamente comune di spostare un forum su un server e/o host diverso dove un breve downtime è accettabile, mi piace molto la semplicità e la portabilità di questo metodo.

1 Mi Piace
26

Giusto.

Giusto.

Il mio metodo preferito è fare l’rsync delle cose di Let’s Encrypt e SSL, mettere il vecchio server in modalità di sola lettura, eseguire il backup, ripristinare sul nuovo server e quindi cambiare il DNS (o meglio, un IP statico quando il nuovo server è pronto).

Ma se non ti dispiace un po’ di downtime, il tuo modo è ottimo.

2 Mi Piace
27

Sto pianificando la migrazione a un nuovo VPS a gennaio dopo alcuni recenti problemi nell’aggiornamento di Discourse sulla mia vecchia Ubuntu.

Le mie domande sulla migrazione da un vecchio droplet Digital Ocean a un nuovo droplet Digital Ocean sono:

  • Ho intenzione di abbassare il TTL del record DNS A il giorno prima della migrazione a qualcosa di piccolo, come 5 minuti. Sembra ragionevole?

  • Il primo post in questo thread è stato modificato l’ultima volta nel giugno 2016. È ancora valido e corretto?

  • Questo metodo rsync copierà anche l’intero database dal vecchio VPS al nuovo VPS?
    – Siamo su un’installazione standard

  • Verrà copiato anche il certificato SSL Let’s Encrypt esistente? Il certificato SSL è legato o collegato a un indirizzo IP? Continuerà a rinnovarsi automaticamente? Ci sono insidie qui?

  • A che punto dovrei cambiare il record DNS A pubblico per puntare al nuovo VPS?
    – E cambiare anche il TTL di nuovo a qualcosa di più alto

28

È tutto corretto.

Se stai usando qualcosa che consente di avere un IP permanente che può essere assegnato a più VM, allora puoi farlo in modo da non dover fare affidamento sul DNS per effettuare il passaggio.

L’unica avvertenza che aggiungerei è di spegnere il vecchio sito per l’rsync finale e quindi riavviarlo in modalità di sola lettura mentre il nuovo viene ricostruito.

29

Il primo post mostra ancora il percorso errato /var/discourse/:

Potresti modificare/aggiornare per favore?

30

@Richie, @JammyDodger ha ora reso questa una wiki :+1:

2 Mi Piace
31

Ho migrato a un nuovo VPS oggi e ho pensato di condividere le mie esperienze, dato che sembra che parecchie persone stiano riscontrando il blocco del sistema operativo di vecchia versione nei loro aggiornamenti ultimamente :blush:

Sono su Digital Ocean, quindi ho creato un nuovo droplet.

Vecchio vps = Ubuntu Server 18.04.6 LTS

Nuovo vps = Ubuntu Server 23.10

Ho fatto la solita manutenzione sul nuovo vps - per favore, modifica a tuo piacimento:

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

Poi ho creato una nuova directory vuota per Discourse:

sudo mkdir -p /var/discourse

Poi ho installato Docker:

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

Poi ho cambiato il TTL sul mio DNS da 30 minuti a 10 minuti (il minimo consentito da GoDaddy).

Sul mio vecchio server, ho scaricato una copia locale del backup del database di Discourse di ieri sera (non si hanno mai abbastanza backup locali). Ho anche scaricato una copia di app.yml sul mio pc locale.

Come suggerito da alcune persone sopra, ho fatto un rsync “root-to-root”. Ho usato l’indirizzo IP piuttosto che il nome host, in modo da poter evitare qualsiasi confusione DNS. Inoltre, come suggerito sopra, ho usato gli switch -avz:

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

Per riferimento, la mia cartella discourse è di 25 GB.

Ci sono voluti circa 25 minuti per fare il rsync dal vecchio server al nuovo server. Questo è stato semplicemente tra due droplet Digital Ocean nella stessa regione LON1. Le tue esperienze potrebbero differire.

Dopo aver fatto il rsync e aver provato una ricostruzione, ho riscontrato lo stesso errore che @piratdavid ha riscontrato riguardo a postgres database system is shut down.

Quindi ho fermato l’app sul vecchio vps:

./launcher stop app

E ho fatto un altro rsync, solo per le modifiche questa volta:

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

Poi ho riavviato l’app Discourse sul vecchio server e molto rapidamente l’ho messa in Modalità Manutenzione - questo è in modo che le persone possano ancora accedervi e vedranno il consueto messaggio di avviso di manutenzione.

Questo mi dà anche un po’ di tempo per lavorare sul nuovo vps :blush:

Ho aggiornato il mio file HOSTS sul mio pc locale in modo da poter accedere a discourse sul nuovo vps senza avvisi / problemi del browser.

Sul nuovo vps ho quindi eseguito:

./discourse-setup

Questo è stato fatto in modo che potesse aggiornare automaticamente le impostazioni di RAM e CPU nel file app.yml.

Poi ho fatto una ricostruzione dell’app sul nuovo vps:

./launcher rebuild app

Ho fatto alcuni test preliminari, tutto bene.

DNS aggiornato - lavoro fatto.

Grazie per l’argomento dettagliato, a tutti :smiley:

4 Mi Piace
32

Grazie ragazzi, il primo post è stato aggiornato per quanto riguarda i percorsi /var/discourse.

1 Mi Piace
33

Se qualcuno sta avendo problemi a fare rsync da root a root perché magari ha disabilitato il login di root sul vecchio server, o semplicemente vuoi farlo come utente non root, ho trovato questo post utile per capire come usare sudo sul server remoto: https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

Supponiamo che tu abbia un utente, discourse, su entrambi i lati che ha privilegi sudo. Sulla macchina remota, modificherai il file /etc/sudoers con sudo visudo. Aggiungerai la riga:

discours TUTTI=NOPASSWD:/usr/bin/rsync

Quindi sulla nuova macchina, eseguirai (come tuo utente non root):

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

Questo ti permetterà di eseguire tutto ciò che è descritto qui come utenti non root. Se stai mantenendo il vecchio server, tornerei nel file /etc/sudoers e cancellerei la riga che hai appena inserito.

1 Mi Piace
34

Se ho capito bene, questo permette che la maggior parte del trasferimento avvenga mentre Discourse è in esecuzione. La strategia di ripristino dal backup richiede almeno la modalità di sola lettura per il backup e lo spostamento del backup sul nuovo server (o il trasferimento tramite bucket S3). Per siti di grandi dimensioni, questo può comportare un considerevole tempo di sola lettura che la strategia rsync evita abilmente.

Potrebbe essere possibile ridurre un po’ i tempi di inattività evitando di arrestare PostgreSQL sul vecchio sistema e "risolvendo" il problema sul nuovo sistema con pg_resetwal. NB: Non ho provato questo e lasciare che il database si arresti normalmente è quasi certamente un’idea migliore.

Mi chiedo se ci sia un modo per avviare Discourse in modalità di sola lettura? Sospetto che il modo più veloce sia tramite la riga di comando dopo che il container è in esecuzione.

In ogni caso, grazie per aver condiviso la tua esperienza! Sembra un processo utile da avere a portata di mano. :slight_smile:

35

Molto.

Così utile, infatti, che sono tentato di rifare tutto da capo per creare un ambiente di staging (su un VPS con specifiche inferiori), solo per testare e prevenire eventuali problemi prima di implementare qualsiasi modifica in produzione.

1 Mi Piace
37

Ciao,

Sto cercando di eseguire questo processo su un’istanza Discourse più vecchia di cui ora sono responsabile della manutenzione, migrando da un Ubuntu EOL a qualcosa di più recente perché qualsiasi aggiornamento fallisce se provo a farlo in loco, e sebbene rsync sia andato a buon fine, postgres non si avvia citando problemi di proprietà dei file. Eseguire rsync come root con le opzioni di preservazione della proprietà non ha corretto questo problema (la proprietà e i permessi dei file ora corrispondono alla sorgente, ho controllato) e poiché bootstrap è fallito e non ho container in esecuzione, non posso tentare di risolvere questo problema come descritto in Update failed (postgresql) - #7 by noezDE.

Qual è il modo migliore per normalizzare ciò che postgres si aspetta?

38

È possibile chown i file all’esterno del container? Dovrebbe essere possibile se si dispone delle autorizzazioni di root/sudo.

39

Certo, ma a cosa? Dall’esterno del container, i permessi sono sia corretti che un nonsense totale.

Sorgente (funzionante):

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

Destinazione (rotto):

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

Presumo che questi ID abbiano più senso all’interno del container, forse?

40

Sì, ho provato a fare il bruteforce degli ID numerici da ls -aln e ottengo ancora lo stesso errore.

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

Non so cosa voglia.

41

Penso di aver avuto un errore simile di recente.

Un’ipotesi è che il vecchio container e quello nuovo abbiano voci /etc/passwd diverse. Potresti confrontare quei file, immagino.

Penso che la cosa migliore sia ripristinare dal backup. Non ricordo se l’ho fatto io o se v ha reso qualcosa 777.