Sauvegarde échouée en raison d'erreurs PG/SQL

wincenworks · Décembre 12, 2020, 3:59

Suite à la discussion de Commande de sauvegarde vers S3 ? :

Après avoir tenté une sauvegarde via ./launcher enter, j’ai depuis découvert ce qui semble être la raison pour laquelle les sauvegardes ont cessé de fonctionner.

pg_dump: Échec de l'extraction du contenu de la table "topic_links" : PQgetResult() a échoué.
pg_dump: Message d'erreur du serveur : ERROR: invalid memory alloc request size 18446744073709551613
pg_dump: La commande était : COPY public.topic_links (id, topic_id, post_id, user_id, url, domain, internal, link_topic_id, created_at, updated_at, reflection, clicks, link_post_id, title, crawled_at, quote, extension) TO stdout;
EXCEPTION: pg_dump a échoué
/var/www/discourse/lib/backup_restore/backuper.rb:152:in `dump_public_schema'
/var/www/discourse/lib/backup_restore/backuper.rb:36:in `run'
script/discourse:80:in `backup'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Suppression des anciennes sauvegardes...
Nettoyage...
Suppression des restes '.tar'...
Marquage de la sauvegarde comme terminée...
Actualisation des statistiques du disque...
Notification au 'système' de la fin de la sauvegarde...
Terminé !
[ÉCHOUÉ]

C’est particulièrement frustrant car apparemment, je ne peux pas non plus utiliser les anciennes sauvegardes. Lors de la tentative de restauration, j’obtiens cette erreur.

[2020-12-12 01:53:25] COPY 750 [2020-12-12 01:53:30] ERROR: la valeur nulle dans la colonne "user_id" de la relation "topic_users" viole la contrainte not-null [2020-12-12 01:53:30] DÉTAIL : La ligne échouée contient (null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null). [2020-12-12 01:53:30] CONTEXTE : COPY topic_users, ligne 623983 : "\N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N" [2020-12-12 01:53:30] EXCEPTION: psql a échoué : CONTEXTE : COPY topic_users, ligne 623983 : "\N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N" [2020-12-12 01:53:30] /var/www/discourse/lib/backup_restore/database_restorer.rb:87:in `restore_dump' /var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore' /var/www/discourse/lib/backup_restore/restorer.rb:51:in `run' /var/www/discourse/script/spawn_backup_restore.rb:23:in `restore' /var/www/discourse/script/spawn_backup_restore.rb:36:in `block in <main>' /var/www/discourse/script/spawn_backup_restore.rb:4:in `fork' /var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>' [2020-12-12 01:53:30] Tentative de retour en arrière... [2020-12-12 01:53:30] Retour en arrière en cours... [2020-12-12 01:53:30] Nettoyage...
[2020-12-12 01:53:30] Suppression des fonctions du schéma discourse_functions...
[2020-12-12 01:53:30] Suppression du répertoire tmp '/var/www/discourse/tmp/restores/default/2020-12-12-014753'...
[2020-12-12 01:53:30] Reprendre sidekiq...
[2020-12-12 01:53:30] Marquage de la restauration comme terminée...

Y a-t-il une maintenance que je pourrais effectuer pour revenir à l’état où la sauvegarde/transfert est à nouveau possible ?

pfaffman · Décembre 12, 2020, 4:49

Cela ressemble à un problème.

S’agit-il d’une installation standard ? Quelle version de PostgreSQL est utilisée ?

Vous avez mentionné qu’il y avait un problème avec ce serveur, c’est pourquoi vous essayez de migrer depuis celui-ci ?

wincenworks · Décembre 12, 2020, 5:14

L’installation actuelle est : 2.7.0.beta1

Le serveur a une histoire complexe (il a environ cinq ans) : il a d’abord été installé en auto-hébergement de manière standard, puis transféré vers l’hébergement Discourse, puis transféré à nouveau vers l’auto-hébergement. Nous avons essayé de le maintenir aussi standard que possible.

Je suis presque certain qu’il s’agit de la version actuelle.

Le serveur a connu des interruptions et des ralentissements intermittents qui ont affecté les performances et ont peut-être eu un impact sur la base de données. La dernière fois que j’ai effectué un nettoyage de la base de données, j’ai supprimé une grande quantité de données du fichier PostgreSQL.

Actuellement, le fichier de sauvegarde auquel j’ai accès fait 1,5 Go, ce qui est trop volumineux pour être édité avec les logiciels disponibles sur mon PC.

Il existe d’autres problèmes dont j’ai connaissance, comme l’échec de la migration des images vers S3, etc. Cependant, auparavant, il n’y avait aucun problème avec les sauvegardes, etc.

pfaffman · Décembre 12, 2020, 1:58

Je pense que je copierais l’intégralité du répertoire /var/discourse vers un nouveau serveur pour échapper aux problèmes de celui-ci, puis j’essaierais de remettre de l’ordre.

Vous pourriez avoir un index corrompu, mais je suis sur mon téléphone et je n’arrive pas vraiment à comprendre les erreurs.

wincenworks · Décembre 13, 2020, 5:28

Je viens de l’essayer — cela a nécessité quelques ajustements.

Le nouveau système ne l’accepte pas, il rejette carrément la base de données.

Launcher est à jour
Arrêt de l'ancien conteneur
+ /usr/bin/docker stop -t 60 app
app
cd /pups && git pull && /pups/bin/pups --stdin
Déjà à jour.
I, [2020-12-13T09:23:39.291334 #1]  INFO -- : Chargement de --stdin
I, [2020-12-13T09:23:39.296303 #1]  INFO -- : > DEBIAN_FRONTEND=noninteractive apt-get purge -y postgresql-13 postgresql-client-13 postgresql-contrib-13
I, [2020-12-13T09:23:41.511661 #1]  INFO -- : Lecture des listes de paquets...
Construction de l'arbre de dépendances...
Lecture des informations d'état...
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  libllvm7 pgdg-keyring postgresql-client-common postgresql-common ssl-cert
Utilisez 'apt autoremove' pour les supprimer.
Les paquets suivants seront SUPPRIMÉS :
  postgresql-13* postgresql-client-13*
0 mis à niveau, 0 nouvellement installés, 2 à supprimer et 0 non mis à jour.
Après cette opération, 54,3 Mo d'espace disque seront libérés.
(Lecture de la base de données ... 43863 fichiers et répertoires actuellement installés.)
Suppression de postgresql-13 (13.1-1.pgdg100+1) ...
invoke-rc.d : impossible de déterminer le niveau d'exécution actuel
invoke-rc.d : la politique policy-rc.d a refusé l'exécution de l'arrêt.
Suppression de postgresql-client-13 (13.1-1.pgdg100+1) ...
Traitement des déclencheurs pour postgresql-common (223.pgdg100+1) ...
Construction des dictionnaires PostgreSQL à partir des paquets myspell/hunspell installés...
Suppression des fichiers de dictionnaire obsolètes :
(Lecture de la base de données ... 42050 fichiers et répertoires actuellement installés.)
Nettoyage des fichiers de configuration pour postgresql-13 (13.1-1.pgdg100+1) ...
Suppression du cluster main...

I, [2020-12-13T09:23:41.511861 #1]  INFO -- : > apt-get update && apt-get install -y postgresql-10 postgresql-client-10 postgresql-contrib-10
debconf : report de la configuration des paquets, car apt-utils n'est pas installé
I, [2020-12-13T09:23:51.192217 #1]  INFO -- : Hit:1 http://deb.debian.org/debian buster InRelease
Get:2 http://deb.debian.org/debian buster-updates InRelease [51,9 kB]
Get:3 http://security.debian.org/debian-security buster/updates InRelease [65,4 kB]
Get:4 http://apt.postgresql.org/pub/repos/apt buster-pgdg InRelease [104 kB]
Hit:5 https://deb.nodesource.com/node_10.x buster InRelease
Get:6 http://security.debian.org/debian-security buster/updates/main amd64 Packages [254 kB]
Get:7 http://apt.postgresql.org/pub/repos/apt buster-pgdg/main amd64 Packages [216 kB]
Téléchargement de 690 kB en 1s (525 kB/s)
Lecture des listes de paquets...
Lecture des listes de paquets...
Construction de l'arbre de dépendances...
Lecture des informations d'état...
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  libllvm7
Utilisez 'apt autoremove' pour le supprimer.
Paquets suggérés :
  postgresql-doc-10
Les paquets NOUVEAUX suivants seront installés :
  postgresql-10 postgresql-client-10
0 mis à niveau, 2 nouvellement installés, 0 à supprimer et 5 non mis à jour.
Besoin de télécharger 6 402 ko d'archives.
Après cette opération, 30,6 Mo d'espace disque supplémentaire seront utilisés.
Get:1 http://apt.postgresql.org/pub/repos/apt buster-pgdg/main amd64 postgresql-client-10 amd64 10.15-1.pgdg100+1 [1 436 kB]
Get:2 http://apt.postgresql.org/pub/repos/apt buster-pgdg/main amd64 postgresql-10 amd64 10.15-1.pgdg100+1 [4 966 kB]
Téléchargement de 6 402 ko en 2s (2 809 kB/s)
Sélection du paquet postgresql-client-10 précédemment non sélectionné.
(Lecture de la base de données ... 42050 fichiers et répertoires actuellement installés.)
Préparation du dépaquetage de .../postgresql-client-10_10.15-1.pgdg100+1_amd64.deb ...
Dépaquetage de postgresql-client-10 (10.15-1.pgdg100+1) ...
Sélection du paquet postgresql-10 précédemment non sélectionné.
Préparation du dépaquetage de .../postgresql-10_10.15-1.pgdg100+1_amd64.deb ...
Dépaquetage de postgresql-10 (10.15-1.pgdg100+1) ...
Configuration de postgresql-client-10 (10.15-1.pgdg100+1) ...
update-alternatives : utilisation de /usr/share/postgresql/10/man/man1/psql.1.gz pour fournir /usr/share/man/man1/psql.1.gz (psql.1.gz) en mode automatique
Configuration de postgresql-10 (10.15-1.pgdg100+1) ...
Création du nouveau cluster PostgreSQL 10/main ...
/usr/lib/postgresql/10/bin/initdb -D /var/lib/postgresql/10/main --auth-local peer --auth-host md5
Les fichiers appartenant à ce système de base de données seront détenus par l'utilisateur « postgres ».
Cet utilisateur doit également être propriétaire du processus serveur.

Le cluster de base de données sera initialisé avec la locale « C.UTF-8 ».
Le codage par défaut de la base de données a été défini en conséquence sur « UTF8 ».
La configuration par défaut de la recherche textuelle sera définie sur « english ».

Les sommes de contrôle des pages de données sont désactivées.

Correction des permissions sur le répertoire existant /var/lib/postgresql/10/main ... ok
création des sous-répertoires ... ok
sélection de max_connections par défaut ... 100
sélection de shared_buffers par défaut ... 128Mo
sélection du fuseau horaire par défaut ... Etc/UTC
sélection de l'implémentation de la mémoire partagée dynamique ... posix
création des fichiers de configuration ... ok
exécution du script de bootstrap ... ok
exécution de l'initialisation post-bootstrap ... ok
synchronisation des données sur le disque ... ok

Succès. Vous pouvez maintenant démarrer le serveur de base de données en utilisant :

    pg_ctlcluster 10 main start

Ver Cluster Port Statut Propriétaire Répertoire de données              Fichier journal
10  main    5432 down   postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
update-alternatives : utilisation de /usr/share/postgresql/10/man/man1/postmaster.1.gz pour fournir /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) en mode automatique
invoke-rc.d : impossible de déterminer le niveau d'exécution actuel
invoke-rc.d : la politique policy-rc.d a refusé l'exécution du démarrage.
Traitement des déclencheurs pour postgresql-common (223.pgdg100+1) ...
Construction des dictionnaires PostgreSQL à partir des paquets myspell/hunspell installés...
Suppression des fichiers de dictionnaire obsolètes :

I, [2020-12-13T09:23:51.192964 #1]  INFO -- : > mkdir -p /shared/postgres_run
I, [2020-12-13T09:23:51.195917 #1]  INFO -- :
I, [2020-12-13T09:23:51.196235 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run
I, [2020-12-13T09:23:51.198835 #1]  INFO -- :
I, [2020-12-13T09:23:51.199139 #1]  INFO -- : > chmod 775 /shared/postgres_run
I, [2020-12-13T09:23:51.201681 #1]  INFO -- :
I, [2020-12-13T09:23:51.202025 #1]  INFO -- : > rm -fr /var/run/postgresql
I, [2020-12-13T09:23:51.204199 #1]  INFO -- :
I, [2020-12-13T09:23:51.204549 #1]  INFO -- : > ln -s /shared/postgres_run /var/run/postgresql
I, [2020-12-13T09:23:51.207718 #1]  INFO -- :
I, [2020-12-13T09:23:51.208017 #1]  INFO -- : > socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres déjà en cours d'exécution, arrêter le conteneur ; exit 1
2020/12/13 09:23:51 socat[1567] E connect(6, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36) : Aucun fichier ou répertoire
I, [2020-12-13T09:23:51.217014 #1]  INFO -- :
I, [2020-12-13T09:23:51.217294 #1]  INFO -- : > rm -fr /shared/postgres_run/.s*
I, [2020-12-13T09:23:51.220400 #1]  INFO -- :
I, [2020-12-13T09:23:51.220682 #1]  INFO -- : > rm -fr /shared/postgres_run/*.pid
I, [2020-12-13T09:23:51.223488 #1]  INFO -- :
I, [2020-12-13T09:23:51.223691 #1]  INFO -- : > mkdir -p /shared/postgres_run/10-main.pg_stat_tmp
I, [2020-12-13T09:23:51.225967 #1]  INFO -- :
I, [2020-12-13T09:23:51.226198 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run/10-main.pg_stat_tmp
I, [2020-12-13T09:23:51.228306 #1]  INFO -- :
I, [2020-12-13T09:23:51.233016 #1]  INFO -- : Fichier > /etc/service/postgres/run  chmod: +x  chown:
I, [2020-12-13T09:23:51.237345 #1]  INFO -- : Fichier > /etc/runit/3.d/99-postgres  chmod: +x  chown:
I, [2020-12-13T09:23:51.237662 #1]  INFO -- : > chown -R root /var/lib/postgresql/10/main
I, [2020-12-13T09:23:51.244979 #1]  INFO -- :
I, [2020-12-13T09:23:51.245164 #1]  INFO -- : > [ ! -e /shared/postgres_data ] && install -d -m 0755 -o postgres -g postgres /shared/postgres_data && sudo -E -u postgres /usr/lib/postgresql/10/bin/initdb -D /shared/postgres_data || exit 0
I, [2020-12-13T09:23:51.246982 #1]  INFO -- :
I, [2020-12-13T09:23:51.247152 #1]  INFO -- : > chown -R postgres:postgres /shared/postgres_data
I, [2020-12-13T09:23:51.314470 #1]  INFO -- :
I, [2020-12-13T09:23:51.314888 #1]  INFO -- : > chown -R postgres:postgres /var/run/postgresql
I, [2020-12-13T09:23:51.318075 #1]  INFO -- :
I, [2020-12-13T09:23:51.318499 #1]  INFO -- : Remplacement de data_directory = '/var/lib/postgresql/10/main' par data_directory = '/shared/postgres_data' dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.319171 #1]  INFO -- : Remplacement de (?-mix:#?listen_addresses *=.*) par listen_addresses = '*' dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.319652 #1]  INFO -- : Remplacement de (?-mix:#?synchronous_commit *=.*) par synchronous_commit = $db_synchronous_commit dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.320131 #1]  INFO -- : Remplacement de (?-mix:#?shared_buffers *=.*) par shared_buffers = $db_shared_buffers dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.320672 #1]  INFO -- : Remplacement de (?-mix:#?work_mem *=.*) par work_mem = $db_work_mem dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.321143 #1]  INFO -- : Remplacement de (?-mix:#?default_text_search_config *=.*) par default_text_search_config = '$db_default_text_search_config' dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.321608 #1]  INFO -- : > install -d -m 0755 -o postgres -g postgres /shared/postgres_backup
I, [2020-12-13T09:23:51.324709 #1]  INFO -- :
I, [2020-12-13T09:23:51.325108 #1]  INFO -- : Remplacement de (?-mix:#?checkpoint_segments *=.*) par checkpoint_segments = $db_checkpoint_segments dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.325597 #1]  INFO -- : Remplacement de (?-mix:#?logging_collector *=.*) par logging_collector = $db_logging_collector dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.326097 #1]  INFO -- : Remplacement de (?-mix:#?log_min_duration_statement *=.*) par log_min_duration_statement = $db_log_min_duration_statement dans /etc/postgresql/10/main/postgresql.conf
I, [2020-12-13T09:23:51.326619 #1]  INFO -- : Remplacement de (?-mix:^#local +replication +postgres +peer$) par local replication postgres  peer dans /etc/postgresql/10/main/pg_hba.conf
I, [2020-12-13T09:23:51.327039 #1]  INFO -- : Remplacement de (?-mix:^host.*all.*all.*127.*$) par host all all 0.0.0.0/0 md5 dans /etc/postgresql/10/main/pg_hba.conf
I, [2020-12-13T09:23:51.327456 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main
I, [2020-12-13T09:23:51.329156 #1]  INFO -- : > sleep 5
2020-12-13 09:23:51.347 UTC [1583] LOG:  écoute sur l'adresse IPv4 « 0.0.0.0 », port 5432
2020-12-13 09:23:51.347 UTC [1583] LOG:  écoute sur l'adresse IPv6 « :: », port 5432
2020-12-13 09:23:51.349 UTC [1583] LOG:  écoute sur le socket Unix « /var/run/postgresql/.s.PGSQL.5432 »
2020-12-13 09:23:51.363 UTC [1583] FATAL:  les fichiers de la base de données sont incompatibles avec le serveur
2020-12-13 09:23:51.363 UTC [1583] DETAIL:  Le cluster de base de données a été initialisé avec PG_CONTROL_VERSION 1300, mais le serveur a été compilé avec PG_CONTROL_VERSION 1002.
2020-12-13 09:23:51.363 UTC [1583] HINT:  Il semble que vous deviez exécuter initdb.
2020-12-13 09:23:51.365 UTC [1583] LOG:  le système de base de données est arrêté
I, [2020-12-13T09:23:56.331811 #1]  INFO -- :
I, [2020-12-13T09:23:56.332043 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
createdb : impossible de se connecter à la base de données template1 : impossible de se connecter au serveur : Aucun fichier ou répertoire
        Le serveur est-il en cours d'exécution localement et accepte-t-il
        les connexions sur le socket Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2020-12-13T09:23:56.394383 #1]  INFO -- :
I, [2020-12-13T09:23:56.394680 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql : impossible de se connecter au serveur : Aucun fichier ou répertoire
        Le serveur est-il en cours d'exécution localement et accepte-t-il
        les connexions sur le socket Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2020-12-13T09:23:56.454155 #1]  INFO -- :
I, [2020-12-13T09:23:56.454333 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql : impossible de se connecter au serveur : Aucun fichier ou répertoire
        Le serveur est-il en cours d'exécution localement et accepte-t-il
        les connexions sur le socket Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2020-12-13T09:23:56.508933 #1]  INFO -- :
I, [2020-12-13T09:23:56.509118 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql : impossible de se connecter au serveur : Aucun fichier ou répertoire
        Le serveur est-il en cours d'exécution localement et accepte-t-il
        les connexions sur le socket Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2020-12-13T09:23:56.560843 #1]  INFO -- :
I, [2020-12-13T09:23:56.561176 #1]  INFO -- : Terminaison des processus asynchrones


ÉCHEC
--------------------
Pups::ExecError : su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' a échoué avec le retour #<Process::Status: pid 1609 exit 2>
Emplacement de l'échec : /pups/lib/pups/exec_command.rb:112:in `spawn'
Échec de l'exécution avec les paramètres "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
da620ae9048b2cda99c7a0d24e38c9dfafba5d61fac8c64c2da2362a19338a76
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur antérieurs, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.

Ce point semble me préoccuper :

L’utilisation de Discourse Doctor sur les deux ne semble pas fournir de solutions.

pfaffman · Décembre 13, 2020, 5:49

Il essaie de mettre à niveau PostgreSQL. Une grande partie de cela est attendue.

Peut-être qu’il recommencera et passera au modèle pg 10 comme décrit dans Mise à jour PostgreSQL 13

wincenworks · Décembre 17, 2020, 7:58

La ligne empêchant la mise à niveau est toujours présente dans le fichier YML.

Je peux accéder à l’application et consulter le SQL sur l’ancien serveur, mais lorsque j’essaie sur le nouveau, cela renvoie :

psql: erreur : impossible de se connecter au serveur : Aucun fichier ou répertoire de ce type
        Le serveur est-il en cours d'exécution localement et accepte-t-il
        les connexions sur le socket de domaine Unix "/var/run/postgresql/.s.PGSQL.5432" ?

neounix · Décembre 17, 2020, 8:06

La ligne ci-dessus semble être le problème racine @wincenworks

Je ne peux pas vous dire quoi faire, mais si j’étais vous @wincenworks, j’installerais Discourse à partir de zéro ; et avant de construire le conteneur, je configurerais mon(s) modèle(s) pour utiliser PG10.

Ensuite, une fois que cette nouvelle instance sera opérationnelle, vous pourrez essayer de restaurer votre instance Discourse à partir de votre sauvegarde PG10 actuelle, en ligne de commande (et non via l’interface) à l’intérieur de votre conteneur.

J’espère que cela vous aidera.

wincenworks · Décembre 17, 2020, 9:01

J’essaie de lancer une nouvelle instance avec PG10 en ce moment, mais cela plante systématiquement à l’étape finale du processus d’inscription.

Je le ferais volontiers, mais :

Il ne me permet pas de créer une nouvelle sauvegarde
Les sauvegardes précédentes ne peuvent pas être restaurées

D’où ma tentative de les transférer via scp.

neounix · Décembre 17, 2020, 9:07

Oui, cela ne sera pas restauré sur votre configuration actuelle, tel que je l’ai compris.

Avez-vous essayé d’utiliser cette sauvegarde pour restaurer après une installation complète et propre, comme je l’ai mentionné ?

D’abord, installez Discourse à partir de zéro, assurez-vous qu’il est à 100 % opérationnel avec un modèle d’installation PG10.

Ensuite, prenez votre dernière sauvegarde et restaurez cette sauvegarde (depuis la ligne de commande, et non via l’interface utilisateur).

Sujet		Réponses	Vues
Forum crashes after upgrading from 2.4.0 Self-hosting	10	1267	Août 3, 2020
Stuck and lost updating forum, problems with PG migration Self-hosting	15	424	Juin 12, 2025
Backup has failed. pg_dump: server version: 9.6.3; pg_dump version: 9.5.10 Development	8	9131	Décembre 2, 2017
When rebuild, Discourse removes PostGreSQL 10 and reinstalls version 9.5 Self-hosting	6	1047	Mai 8, 2020
Upgrade Failed from 2.7.0.beta1 to 2.7.0.beta3 Self-hosting	13	2031	Février 15, 2021

Sauvegarde échouée en raison d'erreurs PG/SQL

Sujets connexes