Error al migrar a una instancia externa de postgres

Configuré mis foros usando discourse-docker con la configuración predeterminada autocontenida. Necesito cambiar a usar un servidor postgres separado.

Ejecuté una copia de seguridad, luego modifiqué app.yml, reconstruí e intenté restaurar desde la copia de seguridad a través de la CLI. La restauración falla y parece que la restauración estaba usando el host correcto para acceder a postgres, pero estaba usando el puerto predeterminado (5432) en lugar del que configuré (9432).

Error:

psql: error: connection to server at "[REDACTED HOST]" ([REDACTED IP]), port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
EXCEPTION: psql failed: 	Is the server running on that host and accepting TCP/IP connections?
/var/www/discourse/lib/backup_restore/database_restorer.rb:92: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'
script/discourse:149:in `restore'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.0/lib/thor.rb:527:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.0/lib/thor/base.rb:584:in `start'
script/discourse:290:in `<top (required)>'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/cli/exec.rb:58:in `load'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/cli/exec.rb:58:in `kernel_load'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/cli/exec.rb:23:in `run'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/cli.rb:451:in `exec'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/vendor/thor/lib/thor.rb:527:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/cli.rb:34:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/cli.rb:28:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/exe/bundle:28:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.5.3/exe/bundle:20:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Trying to rollback...
Rolling back...
Cleaning stuff up...
Dropping functions from the discourse_functions schema...
Removing tmp '/var/www/discourse/tmp/restores/default/2024-01-17-201724' directory...
Unpausing sidekiq...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]

Configuración:
En app.yml, bajo templates:, comenté - "templates/postgres.template.yml"

También agregué lo siguiente bajo env:

  DISCOURSE_DB_USERNAME: [REDACTED]
  DISCOURSE_DB_PASSWORD: [REDACTED]
  DISCOURSE_DB_HOST:  [REDACTED]
  DISCOURSE_DB_PORT: 9432
  DISCOURSE_DB_NAME: [REDACTED]

Cuando reconstruiste, ¿generó un nuevo sitio en blanco? Si no es así, entonces tienes algún problema ahí.

¿Puedes acceder a la base de datos desde dentro del contenedor con psql \u003calgunos interruptores para apuntar a la base de datos\u003e)?

Dentro del contenedor, si haces un set|grep DB, ¿ves tus variables de entorno?

Sí a las tres. Genera un sitio nuevo y en blanco, conectado a la base de datos correcta. Las variables de entorno se establecen cuando las busco con grep, y puedo conectarme manualmente a la base de datos desde dentro del contenedor.

Existe una remota posibilidad de que, de alguna manera, el script de restauración no respete las variables de entorno (¿pero todo lo demás sí lo hace?). Las formas de comprobarlo son mirar el código y tratar de hacer una restauración desde la UX. Si puedes restaurar desde la UX, creo que podrías mover esto a Bug.

También he intentado una restauración a través de la UX y he obtenido el mismo error.

Entonces supongo que lo siguiente que haría sería revisar el código.

Es especialmente extraño que funcione para todo lo demás.

Puedes acceder a la consola de Rails y luego mostrarnos los siguientes valores:

BackupRestore.database_configuration
BackupRestore::DatabaseRestorer.psql_command

por ejemplo:

→ rails c
Loading development environment (Rails 7.0.8)
[1] pry(main)> BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration
   host=nil,
   port=nil,
   username="michael",
   password=nil,
   database="discourse_development">

[2] pry(main)> BackupRestore::DatabaseRestorer.psql_command
=> "psql --dbname='discourse_development' --single-transaction --variable=ON_ERROR_STOP=1 --username=michael"
1 me gusta

¡Aquí tienes! Todo lo que redacté es correcto. El puerto es lo único que está mal.

[1] pry(main)> BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration
   host="[REDACTED[",
   port=5432,
   username="[REDACTED]",
   password="[REDACTED]",
   database="[REDACTED]">
[2] pry(main)> BackupRestore::DatabaseRestorer.psql_command
=> "PGPASSWORD='[REDACTED]' psql --dbname='[REDACTED]' --single-transaction --variable=ON_ERROR_STOP=1 --host=[REDCATED] --port=5432 --username=[REDACTED]"

También reitero que la instancia en blanco puede conectarse a la base de datos para todo excepto para restaurar desde la copia de seguridad.

¿Qué es

ActiveRecord::Base.connection_pool.db_config.configuration_hash
1 me gusta
[3] pry(main)> ActiveRecord::Base.connection_pool.db_config.configuration_hash
=> {:adapter=>"postgresql",
 :pool=>8,
 :connect_timeout=>5,
 :socket=>"/var/run/postgresql",
 :host=>"[REDACTED]",
 :port=>9432,
 :backup_port=>5432,
 :username=>"[REDACTED]",
 :password=>"[REDACTED]",
 :host_names=>["[REDACTED]"],
 :database=>"[REDACTED]",
 :prepared_statements=>false,
 :idle_timeout=>30,
 :reaping_frequency=>30,
 :advisory_locks=>true}

Ah! También necesitarás configurar

DISCOURSE_DB_BACKUP_PORT: 9432

y entonces las cosas deberían funcionar.

EDITAR: este valor predeterminado ha estado vigente durante un tiempo pero parece haber causado más dificultades que beneficios.

FIX: clear db_backup_port default value by Supermathie · Pull Request #25316 · discourse/discourse · GitHub también debería resolver esto y evitar esta confusión para futuros viajeros.

2 Me gusta

¡Muy apreciado! ¡Gracias!

1 me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.