Q : Si vous avez une ancienne base de données d’une installation Discourse, v2.0 > exporter - importer > 2.9 - échouera-t-elle ou existe-t-il un processus de conversion intégré à l’importation pour permettre une importation réussie ?
Ah merci, cela semble fonctionner, sauf que le démarrage échoue maintenant lors de la reconstruction de l’application.
Il semble y avoir une erreur de type “la base de données discourse existe déjà” ainsi qu’une erreur ruby/gems dans l’avertissement de démarrage.
J’ai lu certaines des erreurs.
Pour le contexte, cette version 2.2b4 (PG10) est la configuration et la construction d’importation d’origine utilisées pour importer depuis une autre plateforme de forum ancienne génération - elle n’a subi aucune mise à jour ni modification depuis, à ma connaissance.
Mon impression est que la solution pourrait être de commenter certaines lignes quelque part utilisées uniquement pour la migration/l’importation d’origine - Où trouveriez-vous normalement de telles personnalisations pour une construction ?
Remarque : J’ai déjà supprimé ou commenté - les plugins, lets’ encrypt et les lignes de la version 2.2b4 de app.yml.
Vous devriez inclure votre fichier pour une aide réelle. Si vous voyez des choses comme
apt get
Ou quelque chose sur la modification de Gemfile, ce serait des choses à supprimer.
Ce que je ferais probablement = étant donné que la mise à niveau de la base de données a fonctionné) = renommer votre app.yml et exécuter discourse-setup (en supposant que votre fichier actuel a ses données dans shared/standalone. Vous pourriez simplement comparer votre fichier avec samples/standalone.yml.
Cool merci pour les conseils. Je vais essayer rm app.yml et voir ce qui se passe.
Quand vous dites fichier, voulez-vous dire des erreurs dans terminal ou dans app.yml ou un autre fichier ?
Informations supplémentaires - Je mets en place une gouttelette pour apprendre et résoudre le problème afin de mieux comprendre comment maintenir avec le bonus de la tranquillité d’esprit en la supprimant. Autrement dit, je n’ai pas exécuté ceci sur/et supprimé un forum en direct ![]()
Quand je suis parti hier, il m’est venu à l’esprit que je devrais évidemment consulter les instructions de l’importateur et comprendre comment il est configuré et voir s’il y a des résidus, mais votre suggestion concernant app.yml contourne probablement de telles embûches. ![]()
Ok, tried all that - spun up new droplet,
updates OS/Docker
stopped container
rm app.yml
discourse-setup = upgraded PG10
rebuild FAILED bootstrap (looks identical to yesterday’s error messages.)
The errors that I can see:
1) ERROR: database “discourse” already exists
2022-05-20 10:35:29.889 UTC [42] LOG: database system is ready to accept connections
I, [2022-05-20T10:35:34.789986 #1] INFO – :
I, [2022-05-20T10:35:34.790259 #1] INFO – : > su postgres -c ‘createdb discourse’ || true
2022-05-20 10:35:34.839 UTC [55] postgres@postgres ERROR: database “discourse” already exists
2022-05-20 10:35:34.839 UTC [55] postgres@postgres STATEMENT: CREATE DATABASE discourse;
createdb: error: database creation failed: ERROR: database “discourse” already exists
2) “index_poll_options_on_poll_id_and_digest”
I, [2022-05-20T10:29:54.464874 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
2022-05-20 10:29:58.275 UTC [664] discourse@discourse ERROR: duplicate key value violates unique constraint **"index_poll_options_on_poll_id_and_digest"**
2022-05-20 10:29:58.275 UTC [664] discourse@discourse DETAIL: Key (poll_id, digest)=(163, 84b9c1be0d88b6592595e6e16827dbc1) already exists.
2022-05-20 10:29:58.275 UTC [664] discourse@discourse STATEMENT: INSERT INTO poll_options
(poll_id, digest, html, anonymous_votes, created_at, updated_at)
VALUES
(163, 'e8b71c653ce9b67fbfdeb23956415a45', '<2%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '19aab1c9ed0e7bf7aff0dc154f3f349a', '3%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, 'ba429f197b4f9f3ce89f4e1fb2e8b009', '4%', 1, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '30eb71c6082b75ca751c3d4e94aa386c', '5%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '7575912ab29a386e8f6797e280aca664', '6%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '17950b1d5d660a2e8a078640be0def0a', '7%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '1c4e675eb7d2d561f16d1afce8330816', '8%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, 'a891f2abb4531189affefe9896df814e', '9%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, 'd7d8f9a60fc4dc25f2e6a986b12e5176', '10%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '3d5e680f80b95ddbf99490991327349a', '11%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '84b9c1be0d88b6592595e6e16827dbc1', '12%', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC'),(163, '84b9c1be0d88b6592595e6e16827dbc1', '<blockquote>
<p>12%</p>
</blockquote>', 0, '2019-03-16 12:37:50 UTC', '2019-03-16 12:37:50 UTC')
RETURNING digest, id
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
ERROR: duplicate key value violates unique constraint "index_poll_options_on_poll_id_and_digest"
DETAIL: Key (poll_id, digest)=(163, 84b9c1be0d88b6592595e6e16827dbc1) already exists.
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:110:in `exec'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:110:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/postgres/connection.rb:209:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `block in run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `block in with_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `with_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/postgres/connection.rb:64:in `query_single'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:131:in `block (2 levels) in up'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:87:in `each'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:87:in `block in up'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:64:in `each'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:64:in `up'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:873:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:873:in `exec_migration'
/var/www/discourse/lib/freedom_patches/schema_migration_details.rb:9:in `block in exec_migration'
/var/www/discourse/lib/freedom_patches/schema_migration_details.rb:8:in `exec_migration'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:854:in `block (2 levels) in migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:853:in `block in migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:852:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1046:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1360:in `block in execute_migration_in_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/transactions.rb:209:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1411:in `ddl_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1359:in `execute_migration_in_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1333:in `each'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1333:in `migrate_without_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1282:in `block in migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1432:in `block in with_advisory_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1447:in `with_advisory_lock_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1428:in `with_advisory_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1282:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1117:in `up'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1092:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/tasks/database_tasks.rb:262:in `migrate'
/var/www/discourse/lib/tasks/db.rake:227:in `block (2 levels) in <main>'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/lib/tasks/db.rake:210:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Caused by:
PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "index_poll_options_on_poll_id_and_digest"
DETAIL: Key (poll_id, digest)=(163, 84b9c1be0d88b6592595e6e16827dbc1) already exists.
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:110:in `exec'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:110:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/postgres/connection.rb:209:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `block in run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `block in with_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `with_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/mini_sql-1.4.0/lib/mini_sql/postgres/connection.rb:64:in `query_single'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:131:in `block (2 levels) in up'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:87:in `each'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:87:in `block in up'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:64:in `each'
/var/www/discourse/plugins/poll/db/migrate/20180820080623_migrate_polls_data.rb:64:in `up'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:873:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:873:in `exec_migration'
/var/www/discourse/lib/freedom_patches/schema_migration_details.rb:9:in `block in exec_migration'
/var/www/discourse/lib/freedom_patches/schema_migration_details.rb:8:in `exec_migration'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:854:in `block (2 levels) in migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:853:in `block in migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:852:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1046:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1360:in `block in execute_migration_in_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/transactions.rb:209:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1411:in `ddl_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1359:in `execute_migration_in_transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1333:in `each'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1333:in `migrate_without_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1282:in `block in migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1432:in `block in with_advisory_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1447:in `with_advisory_lock_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1428:in `with_advisory_lock'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1282:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1117:in `up'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/migration.rb:1092:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3/lib/active_record/tasks/database_tasks.rb:262:in `migrate'
/var/www/discourse/lib/tasks/db.rake:227:in `block (2 levels) in <main>'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/lib/tasks/db.rake:210:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2022-05-20T10:29:58.305849 #1] INFO -- : == 20180820073549 CreatePollsTables: migrating ================================
-- create_table(:polls, {})
-> 0.0172s
-- add_index(:polls, [:post_id, :name], {:unique=>true})
-> 0.0016s
-- create_table(:poll_options, {})
-> 0.0064s
-- add_index(:poll_options, [:poll_id, :digest], {:unique=>true})
-> 0.0018s
-- create_table(:poll_votes, {:id=>false})
-> 0.0067s
-- add_index(:poll_votes, [:poll_id, :poll_option_id, :user_id], {:unique=>true})
-> 0.0013s
== 20180820073549 CreatePollsTables: migrated (0.0376s) =======================
End
I, [2022-05-20T10:29:58.308710 #1] INFO – : Terminating async processes
I, [2022-05-20T10:29:58.308759 #1] INFO – : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 42
I, [2022-05-20T10:29:58.308837 #1] INFO – : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 103
2022-05-20 10:29:58.308 UTC [42] LOG: received fast shutdown request
103:signal-handler (1653042598) Received SIGTERM scheduling shutdown…
103:M 20 May 2022 10:29:58.310 # User requested shutdown…
103:M 20 May 2022 10:29:58.310 * Saving the final RDB snapshot before exiting.
2022-05-20 10:29:58.310 UTC [42] LOG: aborting any active transactions
2022-05-20 10:29:58.312 UTC [42] LOG: background worker “logical replication launcher” (PID 51) exited with exit code 1
2022-05-20 10:29:58.312 UTC [46] LOG: shutting down
2022-05-20 10:29:58.392 UTC [42] LOG: database system is shut down
103:M 20 May 2022 10:29:58.601 * DB saved on disk
103:M 20 May 2022 10:29:58.602 # Redis is now ready to exit, bye bye…
FAILED
Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ failed with return #<Process::Status: pid 650 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn’
exec failed with the params {“cd”=>“$home”, “hook”=>“db_migrate”, “cmd”=>[“su discourse -c ‘bundle exec rake db:migrate’”]}
bootstrap failed with exit code 1
**** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.**
./discourse-doctor may help diagnose the problem.
I’ve run discourse doc many times including this time and it didn’t turn up anything I could see
Dans ce cas, faites simplement une nouvelle installation, sauvegardez l’ancien site et restaurez-le sur le nouveau site.
Ha ha, c’était un peu mon OP qui jouait.
Si c’est aussi simple, alors tous mes problèmes sont résolus.
Voyez-vous, ma préoccupation était que j’allais exporter de PG10 vers le tout nouveau 2.9 qui est PG13, n’est-ce pas, et donc il importera la base de données - mon hypothèse serait non.
Ainsi, dans un scénario de sauvegarde et de restauration, dans ce contexte - L’exportation/importation d’administrateur est-elle suffisante sans d’abord mettre à niveau l’ancienne base de données comme j’ai essayé de le faire ?
Oui, mais vous devrez peut-être corriger un problème avec votre base de données actuelle avant de pouvoir la restaurer sur la version 2.9.
Voici une solution qui pourrait fonctionner, mais vous devrez utiliser %84b9c1be0d88b6592595e6e16827dbc1% comme value car c’est l’ID de sondage qui cause des problèmes dans votre cas.
Il semble donc que vous ayez un index corrompu ? (Je ne l’avais pas remarqué, mais c’est ce que suggère la dernière réponse).
Si c’est le cas, vous pouvez chercher des exemples. La plupart du temps, vous essayez de réindexer et de voir quels index ne peuvent pas être reconstruits, puis vous supprimez (ou réparez si vous êtes astucieux) les enregistrements fautifs.
Merci pour cela, cela semblait prometteur, mais cela s’est arrêté sur un nouvel ID de sondage + VALEUR après avoir appliqué certaines de ces étapes correctives.
Bien que cela puisse être le problème et que cela puisse être la solution, je pense que tous les sondages causeront un arrêt ou trop, pas simplement un, et je me base également sur la déclaration de Falco dans l’autre fil de discussion :
Ce n’est pas un index corrompu.
Entre 2.1 et 2.5, nous avons déplacé les sondages de PluginStore vers des tables appropriées. L’une des raisons de ce déplacement est d’assurer la cohérence des données, ce qui est exactement le problème que vous avez.
Vous avez une valeur en double dans la table
poll_options. Pouvez-vous y aller et supprimer les entrées en double ?
Une enquête plus approfondie est nécessaire.
Salut tout le monde,
Je suis dans la même situation que @agemo, j’obtiens exactement la même erreur et je suis à l’aise pour manipuler directement la base de données.
Voici ce que je ne comprends pas. La solution suggérée est de simplement supprimer les sondages d’ID en double dans la colonne de valeur, mais lorsque j’ai vérifié ma table, il s’avère que ces entrées en double font toutes référence à des post_id différents, appartiennent donc à des publications différentes et ont également des métadonnées différentes telles que le nombre de votes, etc.
Quelqu’un peut-il m’expliquer l’ancienne structure par rapport à la nouvelle structure afin que je puisse comprendre cette erreur. Pour moi, supprimer des sondages ne résout pas le problème car je supprime en fait des données d’utilisateurs.
Merci !
Il me semble qu’il s’agit d’un index corrompu. Pouvez-vous réindexer cette table ?
Ou peut-être que quelque chose a changé et qu’une migration plus complexe est nécessaire. Ou que la migration est défectueuse d’une manière ou d’une autre.
Salut @pfaffman, ravi de vous revoir. J’ai déjà utilisé votre service pour un autre site.
-
Je peux certainement reconstruire l’index sur cette table, mais comment cela aidera-t-il avec des données non uniques ? Pouvez-vous expliquer pourquoi c’est toujours par là que vous commencez ? (je viens de le remarquer dans vos réponses)
-
La migration a été effectuée avec la version 2.2b4, c’était celle où l’importation des sondages fonctionnait réellement.
-
Ai-je bien compris qu’en ancienne table post_custom_fields, la valeur ->poll->options->id fait référence au digest et non à l’id réel du sondage ?
-
Qu’est-ce qu’un digest de sondage de toute façon ?
Merci pour votre réponse, mais supprimer simplement les sondages n’est pas une solution aux enregistrements en double. Je suppose que quelque part au début, l’importation depuis phpbb3 a été incorrecte et a créé ces enregistrements. Ils sont valides, ils ont juste des UUID en double car l’importation d’origine ne vérifiait pas cela.
Quoi qu’il en soit, la solution pour quiconque rencontre ce problème est la suivante :
- Modifiez les enregistrements problématiques dans la table
post_custom_fieldspour les mettre de côté. Il est préférable de procéder ainsi plutôt que d’attendre quelques minutes la reconstruction pour voir une autre erreur.
update post_custom_fields set name = 'polls' where name = 'polls_bak';
update post_custom_fields set name = 'polls-votes' where name = 'polls-votes_bak';
-
Lancez la reconstruction de l’application, la mise à jour ou tout ce que l’utilisateur essaie de faire.
-
Connectez-vous au conteneur en cours d’exécution après que tout soit construit et démarré.
-
Remettez les sondages à leur nom d’origine :
update post_custom_fields set name = 'polls'_bak' where name = 'polls';
update post_custom_fields set name = 'polls-votes_bak'' where name = 'polls-votes';
- Lancez manuellement la migration qui cause le problème depuis l’intérieur du conteneur de l’application. Notez que
VERSIONest le numéro dans le nom de fichier de la migration.
D’abord, annulez la migration, cela ne fera rien car la méthode down n’affecte pas la base de données :
rake db:migrate:down VERSION=20180820080623
Exécutez la migration et recherchez la première erreur :
rake db:migrate:up VERSION=20180820080623
- Recherchez dans la table à l’aide d’une interface graphique de base de données pour faciliter l’édition de l’UUID qui cause le problème :
select from post_custom_fields where value like '%your_UUID%';
-
Maintenant, la partie délicate. L’UUID est l’identifiant de la réponse/option du sondage, vous devez donc modifier cet UUID sur la ligne
poll, disons de731ef6901e968fc3f4e785fcb9e9abe8à731ef6901e968fc3f4e785fcb9e9abe9. Il est très peu probable que vous en trouviez un autre comme celui-ci dans votre système. Mais après cela, vous devez également trouver celui correspondant danspoll-voteset le modifier avec votre nouveau. De cette façon, vous ne perdrez aucun vote ni aucune réponse. -
Exécutez à nouveau la migration et recherchez la prochaine erreur :
rake db:migrate:up VERSION=20180820080623
- Répétez ce processus jusqu’à ce que la migration soit terminée et que tous les sondages soient migrés vers vos nouvelles tables.
Je suis déçu que personne n’ait pris la peine de répondre et d’expliquer ce qu’est cet UUID et à quoi il se réfère. Je sais que c’est open source et je sais que des années se sont écoulées depuis son engagement, je ne me plains pas, mais une aide de la part des personnes qui font des commits sur le dépôt officiel serait très appréciée.
Le problème a été résolu, donc tout va bien.
Merci !
Du beau travail là-bas. ![]()
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.