Accéder à la base de données

I am trying to access my database via a GUI (Psequel).

I forwarded the port setting from my container as such:

app.yml:

expose:
  <standard definitions>
  - "15432:5432" # PostgreSQL

Also changed my password as such:

./launcher enter app
su - postgres
psql
ALTER ROLE postgres WITH PASSWORD '<your password>';

And I am unable to access the database. Any suggestions?
1 « J'aime »

If you only need a static snap shot of the database then from https://<site>/admin/backups download a backup. It should be a *.tar.gz file and when uncompressed will be a *.sql file. Create a PostgreSQL database on another machine, which could even be your laptop, and then import the *.sql file.

Now you should be able to access the data all you want with any means that can connect to a PostgreSQL database.

I use the above but access the Discourse database in PostgreSQL via ODBC.

HTH

2 « J'aime »

ok good idea.
Actually I figured it out. It runs on port 5432 also in the container.
it should read:
expose:

  • “5432:5432” # PostgreSQL

thanks

6 « J'aime »

Salut tout le monde,

Je peux accéder à ma base de données postgres via pgadmin en suivant ces étapes :

  • Supprimez le code d’exposition du port de votre fichier app.yml et reconstruisez l’application.
  • Accédez à votre portail de gestion de serveur (par exemple, Digital Ocean, AWS, etc.). Créez une règle de pare-feu qui ouvre le port 5432.
  • En utilisant l’onglet SSH de pgadmin : connectez-vous à votre serveur en utilisant l’adresse et les informations d’identification du serveur.

Faites-moi savoir si cela fonctionne pour vous.

Cordialement,
Kimberly

@EricGT jamais pensé à ça ! Merci !! :slight_smile:

1 « J'aime »

Salut !

Je voulais vérifier avec vous s’il vous plaît. Lorsque j’exporte le dump.sql vers une base de données postgresql, je me retrouve avec des tables vides. On ne sait pas pourquoi. Voici les étapes que je suis après avoir téléchargé le fichier de sauvegarde :

  1. Ouvrir pgAdmin
  2. Créer une nouvelle base de données
  3. Ouvrir l’outil de requête
  4. Utiliser ‘Ouvrir’ dans l’outil de requête et sélectionner le fichier dump.sql
  5. Exécuter le script de vidage

Il est indiqué que tout a réussi, mais lorsque je ‘visualise les données’ dans les tables, elles sont vides.

De plus, c’est probablement la façon dont l’instance est gérée, mais il semble que la table des utilisateurs ne soit pas incluse non plus, mais j’ai besoin de cette table pour savoir qui a fait quoi.

Ai-je manqué quelque chose ici ? Merci !

Quelle est la taille de dump.sql ? Elle devrait être conséquente (quelques Mo au minimum). Pouvez-vous jeter un œil à l’intérieur du fichier ? par exemple :

$ zgrep -i "CREATE TABLE public.users" dump.sql.gz
# la sortie devrait être
> CREATE TABLE public.users (

Si vous ne voyez pas cela, le dump semble incorrect.

De plus, si vous partagez les étapes que vous suivez pour exporter le dump ou si vous collez votre sortie de console ici, nous pourrons mieux comprendre votre problème.

1 « J'aime »

Merci beaucoup ! :slight_smile:

6,34 Go !

L'image montre une ligne de code SQL sur un terminal, tentant d'utiliser un fichier nommé "dump.sql" pour exprimer une instruction CREATE TABLE. (Légendé par l'IA)

Pour télécharger le dump, j’ai suivi les étapes suggérées ci-dessus par @EricGT :

Après cela, j’ai suivi ces étapes :

Et ensuite, quand je veux voir les données, cela affiche :

Je viens de refaire ceci pour vérifier.

  1. En utilisant la page d’administration https:///admin/backup, j’ai demandé un téléchargement et suivi les étapes, il y a eu plusieurs étapes qui comprenaient une vérification par e-mail et le téléchargement d’un fichier.
  2. Le fichier téléchargé était un fichier gz, par exemple abc-2025-01-23-095947-v20250122131007.sql.gz. Sous Windows, j’ai décompressé le fichier en utilisant 7-zip ce qui a créé un répertoire du même nom moins l’extension .gz.
C:\Users\Groot\Downloads>dir *.sql.gz
23/01/2025  05:04               407 231 170 abc-2025-01-23-095947-v20250122131007.sql.gz

C:\Users\Groot\Downloads>dir *.sql

<DIR>          abc-2025-01-23-095947-v20250122131007.sql
  1. En utilisant une invite de commande Windows ouverte dans le répertoire contenant le fichier sql pour vérifier l’existence du fichier sql.
C:\Users\Groot\Downloads\abc-2025-01-23-095947-v20250122131007.sql>dir

01/23/2025  05:04     1 572 346 154 abc-2025-01-23-095947-v20250122131007.sql
               1 Fichier(s)     1 572 346 154 octets
  1. En utilisant la même invite de commande Windows, j’ai tapé la commande pour afficher le début du fichier sql.

type /a | more

C:\Users\Groot\Downloads\abc-2025-01-23-095947-v20250122131007.sql>type "abc-2025-01-23-095947-v20250122131007.sql" /a | more

abc-2025-01-23-095947-v20250122131007.sql


--
-- PostgreSQL database dump
--

-- Dumped from database version 15.8 (Debian 15.8-1.pgdg110+1)
-- Dumped by pg_dump version 15.10 (Debian 15.10-1.pgdg120+1)

-- Started on 2025-01-23 09:59:47 UTC

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';

J’espère que cela vous permettra d’utiliser le fichier SQL avec PGAdmin pour importer les données.


NB

Lorsque j’ai posté à ce sujet il y a environ 5 ans, le type de fichier téléchargé était tar.gz, il est maintenant sql.gz. La seule différence est qu’une étape de décompression en moins est nécessaire maintenant.

2 « J'aime »

Salut @EricGT

Merci beaucoup pour votre aide ! J’ai suivi toutes les mêmes étapes (avec une étape supplémentaire car mon fichier est toujours en tar.gz). J’ai obtenu le même résultat avec le fichier sql :

--
-- PostgreSQL database dump
--
.........
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';

Cependant, le problème est que lorsque j’utilise PgAdmin pour récupérer les données, toutes les tables sont vides et la table Users est tout simplement manquante.

Désolé, je ne peux pas vous aider avec PgAdmin. Je n’utilise pas PgAdmin et je devrais l’installer pour essayer. Installer PgAdmin n’est pas une étape que je souhaite franchir.

La seule fois où j’ai accédé à une base de données Discourse exportée, c’était pour installer PostgreSQL, odbc-postgresql et utiliser iusql comme indiqué ici.

1 « J'aime »

Merci beaucoup pour toute votre aide ! J’apprécie vraiment. Il s’avère que j’essayais d’utiliser la dernière version de postgresql alors que dump.sql provenait d’une version précédente. Je l’ai découvert en essayant de suivre le guide que vous avez utilisé. Merci !

1 « J'aime »