@schleifer Привет, не могли бы вы дать нам рекомендации после этого?
Хорошо, с этим мы можем работать. Сначала переместите все файлы из /default/* в /original/1X/*.
Это известно нам, но не базе данных. Следующий шаг скорректирует пути для всех загруженных файлов в БД. Однако прежде чем что-либо менять, давайте проверим корректность данных.
Запустите консоль базы данных:
cd /var/discourse
./launcher enter
rails db
Выполните этот запрос, чтобы посмотреть результаты:
select id,url from uploads where id > 0 and url not like '//PREFIX/original/%'
Вам нужно заменить PREFIX на BUCKET + ‘.s3.dualstack.’ + REGION + ‘.amazonaws.com’, что даст что-то вроде //pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/%.
Это должно вывести (0 rows). Если нет, то у нас будут дополнительные шаги.
Для вашего запроса найдено 7 загрузок, и ни одна из них не относится к S3.
Значит, все ссылки S3 ведут только на оригиналы, верно? Эти 7 загрузок были сделаны до того, как мы начали использовать S3 для загрузок (октябрь 2018 года).
Из ссылок S3 (2614):
2368 используют //pesioforum.s3.dualstack.ap-south-1.amazonaws.com
246 используют //pesioforum.s3.ap-south-1.amazonaws.com
Обе ссылки работают, просто упоминаю это здесь, так как это может повлиять на любые регулярные выражения, которые мы можем использовать.
@schleifer, пожалуйста, помоги нам завершить это. ![]()
Отлично, значит, вы можете перемещать файлы из /default/ в /original/1X.
Вы можете перенести их в S3, выполнив команду rake s3:upload_assets
Конечная точка dualstack работает как для IPv6, так и для IPv4. Остальная — только для IPv4.
В образе есть скрипт для замены строк в базе данных. Перед его запуском ВСЕГДА СДЕЛАЙТЕ РЕЗЕРВНУЮ КОПИЮ через /admin/backups (Меню «гамбургер» → Admin → Backups).
Это должно исправить 246 ссылок:
discourse remap '//pesioforum.s3.ap-south-1.amazonaws.com/original/' '//pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/'
После перемещения всего из /default/ в /original/1X/ мы можем перенастроить эти файлы в БД. Но перед этим нужно убедиться, что всё, что находится в /original/2X, действительно там есть.
Возвращает ли этот запрос то же количество строк, что и количество фактических объектов по этому пути в бакете?:
select url from uploads where url like '//pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/2X/%'
Привет, @schleifer
Вы можете перенести их в S3, выполнив команду
rake s3:upload_assets
Я запустил эту команду, и она загрузила ресурсы (js, css и т. д.) для сайта. Однако 7 файлов не были загружены.
Я обнаружил задачу rake uploads:migrate_to_s3, но хотел убедиться, что это именно та задача, которая нужна.
В образе есть скрипт для перемаппинга строк в базе данных
Это сработало отлично, и в таблице uploads больше нет старых ссылок, не поддерживающих dualstack.
Но перед этим мы должны убедиться, что всё, что находится в
/original/2X, действительно там есть.
К сожалению, это не так. В бакете S3 находится 521 файл, но в таблице uploads записей — 2186.
Я проверил несколько файлов, которых нет в /original/2X/, как ожидалось, и все они оказались в /default/.
Пример: из таблицы uploads
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/2X/8/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg не существует, но тот же файл находится по адресу
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/default/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg
На данном этапе, как разовое решение, нас устраивает просто переместить все файлы из /original/2X/{}/ в /original/1X/ и обновить ссылки в постах и т. д. Новые загрузки и так корректно помещаются в 2X.
Ага, да, это именно та, которую я имел в виду. Она должна перенести последние семь загрузок.
Действительно, это лучший вариант на текущий момент. Скопируйте все файлы из их подпрефикса /2X/ и переместите всё в /1X/.
После того как всё будет на месте, выполните следующую команду для обновления всех записей в базе данных:
discourse remap --regex "//pesioforum\.doublestack\.s3\.ap-south-1\.amazonaws\.com/original/[1234]X/([0-9a-f]/){0,}" "//pesioforum.doublestack.s3.ap-south-1.amazonaws.com/original/1X/"
(Не забудьте о предыдущем предупреждении о необходимости создания резервной копии.)
После этого некоторым постам может потребоваться пересборка HTML-версии через меню с гаечным ключом. Если таких постов больше нескольких, можно пересобрать все с помощью rake posts:rebake.
@schleifer, сработало! С изменённым регулярным выражением и повторной обработкой всех сообщений большинство изображений и файлов загружаются корректно.
Есть несколько изображений (не из сообщений), которые всё ещё ссылаются на /optimized/, но мы можем исправить это вручную. Например, логотипы в разных темах и т. д.
Огромное спасибо за помощь!
Здравствуйте, у нас в среде возникла похожая проблема, и мы надеемся получить помощь в её решении.
Наша проблема во многом схожа с описанной:
- У нас указано одно и то же значение в настройках
s3 upload bucketиs3 backup bucket. - Мы столкнулись с этой проблемой после обновления Discourse:
Старая версия: v2.3.0.beta3
Новая версия: v2.5.0.beta6
- Я выполнил вход в контейнер Discourse и запросил данные из базы данных:
SELECT id,url FROM uploads where id > 0 and url not like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/%';
id | url
----+----------------------------------------------------------------------------------------------------
1 | /uploads/default/original/1X/eb17xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxc33.png
2 | /uploads/default/original/1X/b87fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv21.png
78 | //acme-forum.s3-us-west-2.amazonaws.com/original/1X/1205xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv045.png
(3 строки)
- Я выполнил вход в контейнер Discourse и запросил данные из базы данных:
select url from uploads where url like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/%';
//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/2/6267xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxf607c.jpeg
(7953 строки)
- Я проверил количество элементов в ./original/3X/, ответ —
251элемент.
Вопросы:
- Мы используем
dualstack, и я не хочу перенастраивать наши URL так, чтобы они не использовали его. - Структура наших папок отличается: у нас есть элементы вроде
3X/X/Y(например,3X/7/a). Как переместить всё изdefaultв3X/*, если это всё равно не будет корректно сопоставлено?
Моя текущая идея — написать скрипт, который будет использовать вывод из шага 4, чтобы определить, куда вернуть файлы в папку ./original/3X/X/Y.
Проблема в том, что когда я это сделал, dualstack ещё не обслуживал этот файл. Что я имею в виду: когда я заменил файл в папке original/3X/X/Y, я мог видеть его по адресу:
Не работает https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png
Обновление: оказалось, что конечная точка dualstack никогда не была нерабочей, как я думал. Я ошибся, изначально копируя файл изображения в ./original/3X/6/b, забыв разрешить чтение всем.
Итак, мой вопрос:
Является ли жизнеспособным вариантом перемещение файлов изображений из ./default обратно в ./original/3X/x/y без каких-либо изменений в базе данных?
Хорошо, у меня есть обновление.
Похоже, я могу предсказать, куда должны помещаться изображения ./original, но не знаю, как исправить изображения ./optimized.
На нашем форуме, если перейти к одному из наших сообщений, оно пытается отобразить изображение ./optimized.
Есть ли способ узнать, является ли изображение optimized?
Я думаю, что оптимизированные изображения заканчиваются на _2_10x10.png. Было бы это разумным предположением? Если да, то будет ли жизнеспособным решением использовать скрипт для копирования всего, что содержит что-то вроде _2_10x10.png, в папку optimized, а всё остальное — напрямую в папку ./original?
Пример:
GET https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/optimized/3X/c/c/ccaxxxxxxxxxxxxxxxxxxxxxxxxxxxx85_2_690x268.png
[HTTP/1.1 403 Forbidden 0ms]
Спасибо!
@41821 Если URL в таблице uploads верные и рабочие, но посты всё ещё пытаются загрузить оптимизированные изображения, то очистка таблицы optimized_images и повторная обработка всех постов должно помочь: discourse=> delete from optimized_images;
Спасибо большое за обратную связь. На самом деле я в итоге решил (если это можно так назвать) проблему, написав скрипт, который перемещает изображение из директории /default обратно в /optimized на основе имени файла. Это, кажется, сработало, и у меня больше нет никаких проблем.
Если в будущем это повторится, я сделаю так, как вы предложили: удалю всё из optimized_images и пересоздам (rebake) их.
Спасибо!
