Обновление с 11.3 на 11.4

Эта инструкция описывает полный процесс обновления iEXExchanger с версии 11.3 до версии 11.4.

Перед началом ознакомьтесь со всеми этапами и выполняйте их последовательно. Не пропускайте резервное копирование, проверку базы данных и финальную проверку после обновления.

Для версии 11.4 проект должен работать с PostgreSQL 18. Если проект всё ещё использует MySQL или MariaDB, сначала выполните миграцию базы данных и только после этого запускайте Product Updates для версии 11.4.

Проверка базы данных перед обновлением

Начиная с версии 11.3 основной базой данных iEXExchanger является PostgreSQL 18.

Перед обновлением определите, какая база данных сейчас используется проектом.

Текущая база	Что делать	Обновление до 11.4
PostgreSQL 18	Дополнительная миграция не требуется	Можно продолжать обновление
MySQL / MariaDB	Сначала выполнить миграцию на PostgreSQL 18	Product Updates пока не запускать

1

Если проект уже работает на PostgreSQL 18

Если миграция была выполнена при обновлении до версии 11.3 и проект уже работает с PostgreSQL 18, повторно переносить данные не требуется.

Продолжайте обновление по этой инструкции.

2

Если проект всё ещё работает на MySQL или MariaDB

Если проект продолжает использовать MySQL или MariaDB, миграция, предусмотренная при переходе на 11.3, не была завершена.

Для переноса используйте инструкцию миграции MySQL/MariaDB на PostgreSQL 18, предусмотренную для обновления до версии 11.3.

Обновление с 11.2 на 11.3

Не запускайте php artisan product-updates:run --to=11.4, пока миграция на PostgreSQL 18 не завершена и перенесённые данные не прошли проверку.

Не запускайте Product Updates для пустой PostgreSQL-базы. Миграция данных и Product Updates — разные этапы.

Исходную MySQL или MariaDB после переноса не удаляйте. Сохраните её для контрольной проверки и возможного возврата до начала записи новых данных в PostgreSQL.

---

Резервное копирование

Перед обновлением обязательно создайте резервную копию файлов Frontend, Backend и используемой базы данных.

Резервная копия потребуется, если во время обновления возникнет ошибка или понадобится вернуть проект в предыдущее состояние.

1

Резервная копия файлов

В FastPanel откройте файловый менеджер и найдите директории Frontend и Backend вашего проекта.

Создайте архивы текущих файлов и сохраните их вне рабочего каталога проекта. По возможности храните копию также вне самого сервера.

Особенно важно сохранить пользовательские файлы и текущую конфигурацию проекта.

2

Резервная копия базы данных

Если проект уже работает на PostgreSQL 18, создайте резервную копию текущей PostgreSQL-базы.

Если проект всё ещё использует MySQL или MariaDB и перед обновлением будет выполняться миграция, сохраните исходную базу до начала переноса.

Не начинайте обновление без актуальной резервной копии файлов и базы данных.

Перед продолжением убедитесь, что созданные копии действительно доступны для восстановления.

Если вы не уверены, что резервное копирование выполнено правильно, сначала уточните процедуру у технической поддержки вашего хостинг-провайдера.

space

---

Перевод сайта в режим обслуживания

Перед началом обновления необходимо временно остановить работу обменного пункта.

Для этого в административной панели активируйте режим обслуживания.

Это позволит:

• исключить создание новых заявок;
• избежать конфликтов во время обновления;
• предотвратить ошибки при работе пользователей с системой.

После завершения обновления режим обслуживания можно будет отключить.

Подготовка файлов к обновлению

Перед загрузкой новой версии необходимо удалить часть файлов текущей установки.

Данная процедура позволяет избежать конфликтов между файлами предыдущего и нового релиза.

1

Очистка Frontend

Перейдите в директорию основного сайта.

Пример: ваш_домен

Удалите следующие папки:

dist
logs

Назначение папок

Папка	Назначение
dist	Скомпилированная версия Frontend
logs	Журналы работы Frontend

После обновления данные директории будут автоматически созданы заново.

2

Очистка Backend

Перейдите в директорию Backend.

Пример: app.ваш_домен

Удалите следующие папки:

app
bootstrap
config
database
packages
resources
routes
vendor

Важно

Перед удалением обязательно убедитесь, что вы находитесь именно в директории Backend.

Удаление файлов в неправильной директории может привести к повреждению проекта.

3

Не удаляйте следующие папки

Никогда не удаляйте:

public
storage

В данных директориях хранятся:

• пользовательские изображения;
• загруженные файлы;
• документы;
• экспортированные данные;
• служебные файлы системы;
• пользовательский контент.

Удаление этих папок может привести к потере данных.

Важно

Не забудьте скачать файлы лицензии.

Они обязательны для полной установки обновления. После загрузки и распаковки архивов обновления необходимо также загрузить файлы лицензии в папку backend.

Без файлов лицензии обновление может быть установлено не полностью или работать некорректно.

Файлы лицензии и релизы

---

Загрузка файлов обновления

Для обновления используются два архива:

iexexchanger_frontend_update.zip
iexexchanger_backend_update.zip

Каждый архив предназначен для своей части системы.

1

Архив Frontend

Загрузите: iexexchanger_frontend_update.zip

в директорию основного сайта: ваш_домен

2

Архив Backend

Загрузите: iexexchanger_backend_update.zip

в директорию Backend: app.ваш_домен

3

Способы загрузки

Вы можете использовать:

• FastPanel;
• FileZilla;
• WinSCP;
• SFTP;
• SCP.

Рекомендуется выполнять загрузку от имени пользователя сайта.

Использование пользователя root не рекомендуется.

4

Распаковка архивов

После загрузки архивов:

1. Найдите архив в нужной директории.
2. Выполните распаковку.
3. Подтвердите замену существующих файлов, если система запросит подтверждение.

Замена файлов является стандартной частью процесса обновления.

5

Проверка после распаковки

Убедитесь, что:

• архивы успешно распакованы;
• новые файлы появились в системе;
• не возникло ошибок файлового менеджера;
• файлы находятся непосредственно в рабочей директории проекта.

После завершения данного этапа можно переходить к установке обновления.

Миграция на PostgreSQL 18

Этот этап выполняется только для проектов, которые всё ещё работают на MySQL или MariaDB.

Если проект уже использует PostgreSQL 18 после обновления до версии 11.3, пропустите этот раздел.

Выполните миграцию по инструкции перехода на PostgreSQL 18 для версии 11.3.

Обновление с 11.2 на 11.3

Только после этого переходите к Product Updates версии 11.4.

Product Updates не переносит данные из MySQL или MariaDB в PostgreSQL автоматически.

Не запускайте обновление 11.4 для пустой PostgreSQL-базы в расчёте на автоматическую миграцию.

Применение обновления

После загрузки файлов необходимо выполнить обновление через SSH.

Если вы ранее не работали с SSH, воспользуйтесь отдельной инструкцией по подключению к серверу.

Подключение к серверу по SSH

1

Переход в директорию Backend

Подключитесь к серверу и выполните команду:

cd www/app.ваш_домен

или

cd /var/www/имя_пользователя_backend/data/www/app.ваш_домен

Используйте фактический путь вашего проекта.

2

Выполнение команд обновления

Выполняйте команды строго в указанном порядке.

Установка обновления

php artisan product-updates:run --to=11.4

Применяет все изменения новой версии системы.

Выполняет обновление файловых источников курсов.

3

Проверка Product Updates и PostgreSQL

После успешного выполнения проверьте состояние последних обновлений:

php artisan product-updates:status --limit=5

Проверьте подключение Laravel к PostgreSQL:

php artisan db:show --database=pgsql

Команды должны завершиться без ошибок подключения к базе данных.

4

Если команда завершилась с ошибкой

Ошибка может быть связана с:

• незавершённой миграцией на PostgreSQL;
• неправильными правами на файлы проекта;
• недостатком свободного места;
• отсутствием PHP-модулей pdo_pgsql или pgsql;
• недоступностью PostgreSQL;
• параллельно работающим процессом обновления.

В этом случае:

1. Сохраните полный текст ошибки.
2. Проверьте результат миграции и команды verify.
3. Устраните найденную причину.
4. Повторно выполните предварительную проверку.
5. После успешной проверки снова запустите обновление до 11.4.

Завершение обновления

После успешного выполнения всех команд рекомендуется выполнить финальные действия.

1

Удаление архивов обновления

Удалите ранее загруженные архивы:

iexexchanger_frontend_update.zip
iexexchanger_backend_update.zip

Это позволит избежать случайного использования устаревших файлов в будущем.

2

Перезагрузка сервера

Для применения всех изменений рекомендуется выполнить полную перезагрузку сервера.

Через SSH: reboot

или воспользуйтесь инструментами вашей панели управления.

Проверка и обновление конфигурации Nginx

Перед финальной проверкой сайта обязательно изучите актуальную инструкцию по настройке Frontend Nginx и внесите необходимые изменения в конфигурацию.

В версии 11.4 изменилась схема работы Nginx, поэтому старая конфигурация может работать некорректно.

Перейдите по ссылке на актуальную инструкцию:

Настройка Nginx

Внимательно проверьте конфигурацию и приведите её к актуальной версии.

Особое внимание уделите:

• настройке проксирования Frontend на Angular SSR;
• отсутствию старых языковых редиректов в Nginx.

После внесения изменений сохраните конфигурацию, проверьте её корректность и перезапустите Nginx.

Только после этого переходите к проверке работы сайта.

Если сайт не открывается после обновления

Наиболее распространённая причина — не был автоматически запущен Frontend через PM2 после перезагрузки сервера.

Проверьте состояние процессов:

pm2 list

Если процесс отсутствует или находится в состоянии ошибки, воспользуйтесь инструкцией:

Как переустановить PM2?

Перезагрузка сервера

После завершения обновления рекомендуется полностью перезагрузить сервер, чтобы все изменения вступили в силу.

Вы можете выполнить перезагрузку одним из способов.

1

Через SSH

Подключение к серверу по SSH

Авторизуйтесь на сервере под пользователем root и выполните команду:

reboot

2

Через FastPanel

Перейдите в раздел «Настройки» → «Основное» и нажмите «Перезагрузить сервер».

После завершения перезагрузки дождитесь запуска всех сервисов и только затем переходите к проверке работоспособности сайта.

Возврат обменного пункта в работу

Отключайте режим обслуживания только после того, как основные проверки завершились успешно.

После проверки:

1. Отключите режим обслуживания.
2. Если перед миграцией или обновлением отдельно останавливались очереди, планировщики или другие процессы, верните их в работу.
3. Откройте клиентский сайт.
4. Проверьте возможность создания новой заявки.

Обновление можно считать завершённым, если Frontend и Backend доступны, приложение подключается к PostgreSQL, необходимые серверные процессы работают, а обменный пункт снова принимает новые заявки.

Если проект был переведён на PostgreSQL 18 ещё при обновлении до версии 11.3, повторная миграция при переходе на 11.4 не выполняется. Миграционный этап нужен только проектам, которые перед обновлением всё ещё используют MySQL или MariaDB.