oggi ho aggiornato la nostra app Discourse alla versione 3.0.1. L’aggiornamento è fallito tentando di elaborare la migrazione di postgres.
Nello specifico qui:
2023-01-27 04:50:48.628 UTC [483] discourse@discourse ERROR: duplicate key value violates unique constraint "index_tags_on_name"
2023-01-27 04:50:48.628 UTC [483] discourse@discourse DETAIL: Key (name)=(e-mail) already exists.
2023-01-27 04:50:48.628 UTC [483] discourse@discourse STATEMENT: UPDATE tags t
SET public_topic_count = x.topic_count
FROM (
SELECT
COUNT(topics.id) AS topic_count,
tags.id AS tag_id
FROM tags
INNER JOIN topic_tags ON tags.id = topic_tags.tag_id
INNER JOIN topics ON topics.id = topic_tags.topic_id AND topics.deleted_at IS NULL AND topics.archetype != 'private_message'
INNER JOIN categories ON categories.id = topics.category_id AND NOT categories.read_restricted
GROUP BY tags.id
) x
WHERE x.tag_id = t.id
AND x.topic_count <> t.public_topic_count;
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
Sembra che alcuni tag avessero dei duplicati. Mi sono collegato a postgres e ho corretto i tag. La migrazione e l’aggiornamento sono poi andati a buon fine.
La mia domanda è: ho gestito correttamente il mio intervento nel DB? Ho solo cambiato il nome dei tag duplicati.
Non posso dire come siano stati creati i tag duplicati. Sono stati inseriti negli ultimi 2-3 anni.
Non sono sicuro se questa situazione possa ripresentarsi.
Sì. È anche a causa di tag duplicati / index_tags_on_name.
Nel mio caso il tag ha solo un nome diverso.
Attualmente sto cercando di capire:
come aggiornare ruby a 3.0.0 perché si lamenta che web-push è a 2.6.7, quindi non posso nemmeno accedere a rails c, per eseguire comandi avanzati per correggere i tag
come eliminare il tag in modo sicuro dal database postgres ma non ho ancora idea
I, [2023-01-27T07:46:34.317438 #1] INFO -- : \u003e cd /var/www/discourse \u0026\u0026 su discourse -c 'bundle exec rake db:migrate'
2023-01-27 07:46:45.663 UTC [584] discourse@discourse ERROR: duplicate key value violates unique constraint "index_tags_on_name"
2023-01-27 07:46:45.663 UTC [584] discourse@discourse DETAIL: Key (name)=(hws-connect) already exists.
2023-01-27 07:46:45.663 UTC [584] discourse@discourse STATEMENT: UPDATE tags t
SET public_topic_count = x.topic_count
FROM (
SELECT
COUNT(topics.id) AS topic_count,
tags.id AS tag_id
FROM tags
INNER JOIN topic_tags ON tags.id = topic_tags.tag_id
INNER JOIN topics ON topics.id = topic_tags.topic_id AND topics.deleted_at IS NULL AND topics.archetype != 'private_message'
INNER JOIN categories ON categories.id = topics.category_id AND NOT categories.read_restricted
GROUP BY tags.id
) x
WHERE x.tag_id = t.id
AND x.topic_count <> t.public_topic_count;
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "index_tags_on_name"
DETAIL: Key (name)=(hws-connect) already exists.
Questo errore si verifica 3 volte, perché il tag sembra essere presente in 3 argomenti.
Mi pento di aver abilitato i tag se avessi saputo che sarebbe successo e perché non c’era già un avviso sul frontend.
Voglio solo eliminarli e riavere finalmente il mio forum funzionante
La mia domanda è se posso rinominare il tag “hws-connect” nel database senza corrompere l’infrastruttura di discourse?
E… come posso rinominarlo tramite postgres?
dovrai accettare qualche strano glitch quando esegui la tua installazione di software multimilionario (supportato da una community super disponibile) che hai ottenuto (quasi) gratuitamente
Ho recentemente aggiornato due siti che fanno un uso piuttosto intensivo dei tag e non ho avuto problemi.
Nei miei oltre 5 anni di gestione di più istanze di Discourse, penso di aver avuto un problema come questo una volta?
Comunque, sembra un problema molto simile a questo, forse puoi usare una strategia simile per risolverlo?:
Sembra che tu fossi già sulla buona strada, devi solo seguirla…
Lo so e non è nulla contro discourse o l’aggiornamento stesso. Succede e va bene.
Vorrei solo non trovarmi in uno scenario bloccato in cui devo combattere contro così tanti argomenti (docker, ruby, postgres, discourse). Non è il mio lavoro quotidiano e richiede un investimento di tempo.
Aggiornamento: il miglior spunto dal tuo argomento @merefield è stato
Immagino che dovrei essere coraggioso
Armeggiare in un database è sempre spaventoso per me, ma in questo caso ha funzionato.
Per chiunque abbia lo stesso problema (tag duplicati / index_tags_on_name):
schiocca le dita e inizia la Fase 1 di Inception: cd /var/discourse sudo ./launcher enter app
Se questo fallisce perché ottieni qualcosa come “nessun container docker in esecuzione” o simile, digita sudo docker ps -a --no-trunc
Questo elencherà i tuoi container docker disponibili e il loro ID. Con quello, riavvia il container. sudo docker restart <container ID>
Quindi sudo ./launcher enter app dovrebbe funzionare.
accedi al tuo database postgres e inizia la Fase 2 di Inception: su discourse psql
Il log di errore della ricostruzione dovrebbe averti fornito il nome del tag colpevole. Nel mio caso era
ERROR: duplicate key value violates unique constraint "index_tags_on_name"
2023-01-27 07:46:45.663 UTC [584] discourse@discourse DETAIL: Key (name)=(hws-connect) already exists.
Quindi prima cerca il tuo tag con
select * from tags where name='hws-connect';
Questo ti dà la tabella che puoi vedere sopra nei miei post.
Ho semplicemente rinominato il tag hws-connect in hws-connect1 con
UPDATE tags SET name = 'hws-connect1' WHERE name='hws-connect';
Esci da Inception con qualche calcio all’indietro: \q per uscire da postgres exit per uscire dal container docker
Esegui di nuovo la ricostruzione con sudo ./launcher rebuild app
Sii felice che funzioni e verifica sul frontend ciò che hai fatto:
Vai alla tua pagina dei tag https://your-forum/tags
Non ho idea di come sia successo e perché questo aggiornamento sia fallito così male - tutti quelli precedenti hanno funzionato, tramite web o terminale.
Ora pulirò i miei tag.
Bonus:
Fai clic sul tag rinominato.
Rimuovilo da tutti gli argomenti. Nel mio caso 3.
Torna alla pagina dei tag e usa la funzione in alto a destra:
Anch’io sono stato colpito da questo. Grazie per aver condiviso le tue soluzioni manuali, le ho appena usate per correggere circa 20 di questi casi.
Il mio forum utilizzava molti tag in qualsiasi tipo di MixEdCaSe e questo non è mai stato un problema fino all’aggiornamento. Sembra che ci sia/ci sia stato un bug che ha creato voci duplicate, indipendentemente dal case.
id | name | created_at
-------+------------------------+----------------------------
707 | ParkRide | 2019-05-21 21:36:53.213993
18982 | ParkRide | 2020-06-05 18:43:09.409895
(Sì, c’è una differenza negli spazi bianchi attorno a questi)
Ora sono bloccato con un ultimo duplicato che non può essere corretto:
discourse=> select name from tags group by name having count(*) > 1;
name
------------
Bike--Ride
(1 row)
discourse=> UPDATE tags SET name = 'Bike--Ride_2' WHERE name = 'Bike--Ride';
ERROR: duplicate key value violates unique constraint "index_tags_on_name"
DETAIL: Key (name)=(Bike--Ride_2) already exists.
discourse=> UPDATE tags SET name = 'Bike--Ride_3' WHERE name = 'Bike--Ride';
ERROR: duplicate key value violates unique constraint "index_tags_on_name"
DETAIL: Key (name)=(Bike--Ride_3) already exists.
discourse=> UPDATE tags SET name = 'something is broken here' WHERE name = 'Bike--Ride';
ERROR: duplicate key value violates unique constraint "index_tags_on_name"
DETAIL: Key (name)=(something is broken here) already exists.
mentre l’aggiornamento fallisce su
2023-02-01 18:56:58.610 UTC [475] discourse@discourse ERROR: duplicate key value violates unique constraint "index_tags_on_name"
2023-02-01 18:56:58.610 UTC [475] discourse@discourse DETAIL: Key (name)=(Bike--Ride) already exists.
Ho riscontrato lo stesso errore: non importa quale nuovo nome di tag utilizzassi, veniva segnalato che esisteva già. Ho risolto aggiornando il tag utilizzando l’ID invece della colonna del nome:
