Вчера вечером у меня возникла серьёзная проблема на форуме, и мне пришлось всё восстановить заново. Однако в процессе восстановления возникла ошибка, и процесс не удался. Вот текст ошибки:
ERROR: could not create unique index "index_users_on_username_lower"
DETAIL: Key (username_lower)=(lea) is duplicated.
EXCEPTION: psql failed: DETAIL: Key (username_lower)=(lea) is duplicated.
Думаю, это может быть связано с входом через Twitter, но может ли процесс восстановления изменить значение username_lower, если оно дублируется? Я не думаю, что смогу изменить это в SQL-файле (он довольно большой) и затем снова загрузить его.
Это была другая проблема: сервер не мог получить доступ к pups.git, ошибка «Не удалось разрешить хост: github.com». Я попробовал решения, найденные вчера вечером, но они не помогли.
С восстановлением, похоже, проблема касается только одного имени пользователя (возможно, связанного с созданием аккаунта в один клик через Twitter или чего-то подобного). Я пытаюсь исправить это вручную, но работа с SQL-файлом размером 1 ГБ — не самый удобный вариант.
Редактирование: с помощью редактора vim я смог отредактировать SQL-файл и найти нужные строки. Восстановление прошло успешно. Мне осталось только пересобрать всё, и всё будет готово.
Существовали учётные записи с именем “Lea” и “lea”. Странно, что Discourse позволил такое. Это довольно старый форум (июнь 2014 года), и я часто его обновлял, так что, возможно, это было связано с конкретной версией.
День был безумным, но я попробую объяснить, как я всё исправил, на случай, если у кого-то, как у меня, будет действительно невероятное невезение.
Скачайте резервную копию. Распакуйте её несколько раз, пока у вас не появится файл dump.sql.
Отредактируйте файл dump.sql с помощью программы, например, vim download : vim online.
Я ужасно разбираюсь в SQL. Чтобы найти нужную таблицу, я искал username_lower,. Это указало мне на таблицу users, затем я искал «lea». Я отредактировал две записи с именем Lea. Вероятно, это можно было сделать гораздо проще. Но помните, я плохо знаю SQL, особенно когда файлы размером 1,5 ГБ. Сохраните файл.
Сожмите файл dump.sql с помощью 7zip. У вас должен появиться новый файл с именем: dump.sql.gz.
Создайте новую папку в /var/discourse/shared/standalone/backups/default/. Я использовал название test.
Если у вас хорошее интернет-соединение, загрузите папку uploads, которую вы получили при распаковке файла резервной копии, и поместите её в /var/discourse/shared/standalone/backups/default/test/.
6.1 Если у вас нет хорошего соединения, как у меня, вам нужно использовать ваш сервер. Запомните имя вашего файла резервной копии и выполните эту команду: tar xvzf /var/discourse/shared/standalone/backups/default/yourbackupfile.tar.gz -C /var/discourse/shared/standalone/backups/default/test.
6.2 В папке test у вас будут файлы dump.sql.gz и папка uploads. Всё в порядке.
Загрузите файл dump.sql.gz из вашей папки test, чтобы заменить повреждённый dump.sql.gz.
На вашем сервере перейдите в директорию: cd /var/discourse/shared/standalone/backups/default/test.
Вам нужно создать новый файл резервной копии. Используйте точное имя старого файла резервной копии: tar -czvf yourbackupfile.tar.gz uploads/ dump.sql.gz.
Через FTP перейдите в /var/discourse/shared/standalone/backups/default/, удалите повреждённую резервную копию или переместите её в другую папку.
Переместите новый файл резервной копии в /var/discourse/shared/standalone/backups/default/.
Восстановите резервную копию. Я предпочитаю этот метод, и если вы добрались до этого шага, у вас должно получиться использовать его без проблем: Restore a backup from the command line.
невероятное невезение.
