andy@ubuntu-s-1vcpu-1gb-ams3-01:/var/discourse/shared/standalone/backups/default$ file public-happiness-2023-07-25-033857-v20220628031850.tar.gz
public-happiness-2023-07-25-033857-v20220628031850.tar.gz: gzip compressed data, was "public-happiness-2023-07-25-033857-v20220628031850.tar", last modified: Tue Aug 8 14:53:40 2023, max speed, from FAT filesystem (MS-DOS, OS/2, NT)
Полное содержимое файла выглядит в порядке, хотя трудно сказать точно, так как информации очень много: Hastebin
Я думаю, это связано с путями к файлам. Посмотрите на
Хм. Возможно, это не проблема. Я в основном не доверяю 7zip в создании совместимого tar-архива, но это может быть иррационально.
-h, --dereference
Следовать за символическими ссылками; архивировать и выгружать файлы, на которые они указывают.
Ответ может быть в вышеупомянутом файле. На самом деле, он, скорее всего, находится в другом файле в той же директории.
Спасибо — вроде бы правильные файлы, но под неправильными именами, по-моему. Вот в чём проблема.
У вас
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 public-happiness-2023-07-25-033857-v20220628031850/dump.sql.gz
а в оригинале и в любой неизменённой копии было бы
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 dump.sql.gz
Редактирование: значит, при создании этого tar.gz-архива нужно чуть иначе вызывать 7zip.
Спасибо за всю вашу помощь. Я распаковал файлы, снова отредактировал дублирующийся тег, а затем очень аккуратно запаковал их обратно, уделив особое внимание имени файла, и есть прогресс!
Теперь при восстановлении я вижу это сообщение об ошибке, которое, похоже, встречается гораздо чаще:
[2023-08-25 15:25:21] CREATE INDEX
[2023-08-25 15:25:21] ERROR: could not create unique index "index_tags_on_lower_name"
[2023-08-25 15:25:21] DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
[2023-08-25 15:25:21] EXCEPTION: psql failed: DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
Я предполагаю, что это означает, что я успешно изменил тег, но в базе данных всё ещё есть некоторые вхождения этого тега в постах. Номер tag_id указывает на то, что должен существовать тег с именем socialmedia, но вместо этого находится тег с именем socialmedia2, что вызывает конфликт.
В этом посте и в этом обсуждаются способы исправления, но так как у меня есть доступ к резервной копии только через прямое редактирование кода на моём локальном компьютере, я не могу использовать инструменты MySQL для её очистки.
К счастью, в моей базе данных у меня всего 38 вхождений 'socialmedia' (в отличие от 50 000+ вхождений socialmedia). Предполагая, что я правильно изменил тот, что на строке 395421, как показано на скриншоте выше, я не вижу способа определить, какие из оставшихся вхождений связаны с тегом ‘socialmedia’, а какие — с тегом, который я изменил на ‘socialmedia2’.
Вот пример довольно короткого поста с использованием тега socialmedia:
9488 '/groups/communitybuilders':86 '/groups/socialmedia':84 '/groups/webdev':89 '1st':117 '2022':131 '6':125 'activ':61 'banner':113 'btw':143 'close':169 'comment':21 'communiti':47 'communitybuild':87 'concept':4A 'especi':28 'event':119 'excit':164 'feedback':8B 'final':166 'get':38,133 'github':94 'grow':6A,142 'hack':127 'hard':156 'help':96 'homepag':151 'host':124 'improv':11B 'join':71,106 'launch':41,118,126 'like':128 'link':110 'live':140,175 'lot':27 'love':1A,67 'marvelxi':152 'mean':25 'media':51 'member':62 'mention':93 'move':45 'much':15 'new':150 'one':72,107 'onto':53 'plan':121 'platform':7B,43,139 'pleas':5A 'project':137 'promot':97 're':33,36,56,161 'readi':39,172 'rhorho358':23 'right':63 'see':100,167 'site':176 'slight':76,177,179 'small':58 'smile':77,178,180 'social':50 'socialmedia':85 'stage':31 'suggest':10B 'sure':79 'take':17 'team':59,75,103 'thank':12 'think':147 'time':19 'use':108 'webdev':90 'websit':3A 'whether':80 'work':155 'would':66,82 Thank you so much for taking the time to comment here @R , it means a lot, especially in the st... has been working hard on it and we're all very excited to finally see it close to being ready on the live site :slight_smile: :slight_smile: en_GB 4 f
Однако, возможно, я иду не по тому пути, так как в начале выглядит как будто там больше тегов, чем обычно использует пользователь в посте. Также возможно, что ‘socialmedia’ — это не тег, использованный в вышеприведённом посте, хотя он должен был быть.
Я бы восстановил базу данных вручную и попытался бы добавить индексы и исправить проблемы непосредственно в базе данных, а не в текстовом файле, но это тоже сложно.
Я не думаю, что это тот немедленный вывод, который вы можете или должны делать. Проблема должна быть очевидной:
Причина, по которой индекс не строится, заключается в том, что в таблице tags есть как минимум две записи, которые приводят к одному и тому же результату, если привести их имена к нижнему регистру. Именно об этом говорит сообщение об ошибке.
Поэтому я считаю, что вам всё ещё нужно найти связанные записи в этой единственной таблице, которые конфликтуют при применении этого преобразования.
Перед удалением дубликатов запишите их ID, так как вам также потребуется удалить соответствующие строки из таблицы topic_tags (это можно было бы быстро исправить, если бы вы выполняли всё это обслуживание онлайн, просто перезапустив контейнер, кстати, вместо уничтожения экземпляра!!).
Наш сайт снова работает! Спасибо всем за помощь.
Кажется, я решил эту проблему несколько дней назад, но был невнимателен при чтении сообщения об ошибке. Были два дублирующихся тега: ‘socialmedia’ и ‘social-media’. После исправления первого я не заметил, что сообщение об ошибке изменилось, учитывая, насколько похожи оба дублирующихся тега.
Вот процесс исправления этих двух ошибок:
1. Поиск таблицы тегов и дублирующегося тега
Загрузите резервную копию на вашу операционную систему. Данное руководство предназначено для Windows, но процесс будет примерно таким же на Linux.
Распакуйте все сжатые папки, что должно оставить у вас файл dump.sql и папку uploads.
Откройте файл dump.sql в текстовом редакторе; я использовал Visual Studio Code.
Найдите строку “COPY public.tags”, чтобы locate таблицу тегов. Она должна быть ближе к концу и выглядеть примерно так:
Либо просмотрите её вручную, либо скопируйте таблицу тегов в отдельный документ, где можно использовать функцию поиска для нахождения дублирующегося тега.
Сохраните исправленный файл dump.sql как dump.sql.
2. Порядок и имена файлов и папок должны быть идеальными при повторном сжатии.
После распаковки у вас должен быть файл dump.sql и папка uploads.
Щёлкните правой кнопкой мыши на файле dump.sql, выберите 7zip и «Добавить в архив».
Выберите формат архива gzip, оставив имя файла без изменений.
Выберите новый файл dump.sql.gz и папку uploads, затем щёлкните правой кнопкой мыши > 7zip > Добавить в архив > Формат архива: tar. Убедитесь, что имя файла точно совпадает с именем исходной резервной копии; оно должно выглядеть примерно так: ‘public-happiness-2023-07-25-033857-v20220628031850’.
Выберите ваш новый файл .tar > 7zip > Добавить в архив > Формат архива: gzip. Убедитесь, что имя файла точно совпадает с именем исходной резервной копии; оно должно выглядеть примерно так: ‘public-happiness-2023-07-25-033857-v20220628031850’.
Ваш конечный результат должен быть файлом .tar.gz с тем же именем, что и ваша исходная резервная копия.
Загрузите его в панель администратора и восстановите вашу резервную копию.
Есть ещё одно место, где тег повторяется или может повторяться, — это таблица данных поиска:
COPY public.tag_search_data (tag_id, search_data, raw_data, locale, version) FROM stdin;
Не уверен, нужно ли это тоже исправлять.
Так рада, что вы наконец всё починили!
