Divarion-D
76844fef11
Overhaul the Docsify documentation (English + Russian) so it matches the current codebase and follows one consistent pattern. Content accuracy (post-migration): - Rewrite development/autoloader.md to PSR-4 / Composer (the old XC_Autoloader scanner, igbinary tmp/cache/autoload_map and registerDirectories are gone). - PascalCase every source path (src/core -> src/Core, domain/Stream, cli/Commands, public/Controllers, Infrastructure/Redis, ...) across all docs. - Replace the removed autoload.php references with vendor/autoload.php (build_system, bootstrap-contexts, error-handling, modules). - ssl-generation: note that the installer now auto-generates a unique self-signed certificate before Nginx starts. Common pattern (Clean & uniform): - Strip emoji from headings; remove the in-page Navigation blocks (the Docsify sidebar already provides navigation). - One H1 + intro per doc; uniform "Related files" / "Связанные файлы" section, added to the code-centric docs that lacked it. Structure: - Remove the empty stray docs/api/; move updates_checklist.md into builds/; link the previously-orphaned ucs-integration.md. - Regroup the sidebars (split the oversized guides group into Developer Guides / Security & Access / Integrations; fold builds into Build & Release). Augment: - dev-workflow: Local Setup (make dev-tools) + Quality Checks (phpstan, cs, gates). - build_system: Composer Dependencies section (committed prod-only vendor, committed lock, dev tools via composer install, no build-time vendor step). en/ru parity: - Apply the same structure, fixes and pattern to docs/ru/ (translated), including a new Russian ucs-integration.md. The en and ru file sets are now identical.
7.6 KiB
Руководство по миграции XC_VM
Безопасная миграция с совместимых IPTV-систем с использованием встроенных инструментов миграции XC_VM.
Критическое уведомление о миграции
Обязательно прочитайте перед началом миграции.
Миграция XC_VM переносит только данные. Вся конфигурация намеренно исключена из процесса миграции.
Это включает (но не ограничивается):
- API-ключи (например, TMDb)
- Учётные данные внешних сервисов
- Настройки, зависящие от окружения
- Конфигурацию панели и системы
- Состояние выполнения и состояние стримов
Все эти значения необходимо настроить вручную после миграции.
Это осознанное архитектурное решение, а не ограничение и не ошибка. Пропуск повторной настройки приведёт к неработающему получению метаданных, обновлению названий стримов и другим связанным функциям.
Перед началом
💡 Рекомендация: Выполняйте миграцию на чистой установке XC_VM.
⚠️ Важно: Системные настройки и настройки панели НЕ переносятся. Переносятся только данные базы, поддерживаемые механизмом миграции.
Если вы выполняете миграцию в существующую установку, учтите следующее:
- XC_VM удалит все таблицы в основной базе данных, совпадающие с данными из базы миграции.
- Резервные копии обязательны. Автоматического отката не предусмотрено.
Шаги миграции
1. Загрузка бэкапа
Загрузите резервную копию существующей базы данных на сервер XC_VM с помощью SFTP.
Пример пути:
/tmp/backup.sql
2. Восстановление бэкапа в базу миграции
Очистите базу миграции и восстановите бэкап:
sudo /home/xc_vm/console.php tools migration "/tmp/backup.sql"
Перед продолжением убедитесь, что восстановление завершилось без ошибок.
3. Запуск миграции
После успешного восстановления запустите миграцию одним из следующих способов.
Вариант 1 — Командная строка (рекомендуется)
/home/xc_vm/console.php migrate
Вариант 2 — Веб-установщик
- Вернитесь в веб-установщик (ссылка отображается при настройке панели)
- Выберите пункт Migration
- Следуйте инструкциям на экране
Вы будете видеть прогресс миграции в реальном времени. После завершения система станет доступной.
Восстановление доступа после миграции
Если вход невозможен из-за отсутствующих учётных данных или кода доступа, используйте rescue-инструменты.
Создание резервного кода доступа
php /home/xc_vm/console.php tools access
Создание администратора
php /home/xc_vm/console.php tools user
⚠️ После восстановления доступа немедленно смените код доступа и учётные данные администратора.
Подготовка балансировщиков нагрузки
Балансировщики нагрузки не переносятся.
- При необходимости переустановите операционную систему
- Перенастройте сеть и маршрутизацию
- Подключите их заново к основному серверу
Действия после миграции (обязательно)
После миграции система не готова к продакшену, пока не выполнены следующие шаги.
Пропуск этих действий приведёт к ожидаемому, но неработающему поведению.
1. Инициализация состояния выполнения
- Запустите все стримы вручную
- Убедитесь, что стримы доступны и работают стабильно
Состояние выполнения стримов никогда не сохраняется при миграции.
2. Повторная настройка системы
Проверьте и восстановите все настройки, зависящие от окружения:
- Пути к файлам
- Лимиты и квоты
- Сетевые настройки и reverse proxy
- Параметры производительности
Не предполагается, что значения по умолчанию совпадают с вашей прежней конфигурацией. Значения по умолчанию применяются намеренно.
3. Восстановление API-ключей и провайдеров
API-ключи никогда не переносятся
Следующее необходимо настроить вручную:
- TMDb API key
Это ожидаемое поведение.
Если после миграции не загружаются метаданные, проверьте, что API-ключ добавлен заново и провайдер включён. Это не является ошибкой миграции.
Распространённые проблемы после миграции
Метаданные не загружаются (TMDb)
Причина: API-ключ TMDb и конфигурация провайдера не были восстановлены.
Решение: Повторно добавьте API-ключ TMDb и включите провайдер в настройках основного сервера.
Итог
- Миграция переносит только основные данные приложения
- Конфигурация исключена намеренно
- API-ключи и настройки окружения должны быть восстановлены вручную
- Отсутствие функциональности после миграции ожидаемо до завершения повторной настройки