> ## Documentation Index
> Fetch the complete documentation index at: https://nexohub.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Перенос существующей сети

> Как свести три бэкенда, у каждого из которых свой plugins/Nexo/, к одному набору файлов.

В [быстром старте](/ru/quickstart) вы выполняете `/nexohub adopt lobby`: вы называете
бэкенд, он отправляет свой `plugins/Nexo/` наверх, и это становится `_shared/`. Это вся
работа, когда у вас один бэкенд или когда остальные — его копии.

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

Так что команда — это простая часть, а эта страница — всё остальное: как выбрать, какой
бэкенд назвать, и что делать с отличиями остальных от него.

## Перед началом

Сначала установите оба плагина обычным способом. Для принятия (adopt) нужен работающий
мост на бэкенде, с которого вы принимаете файлы, и он должен знать своё собственное имя.

<Steps>
  <Step title="Установите NexoHub на прокси">
    Положите jar прокси, запустите его, скопируйте сгенерированный секрет и задайте
    `http.public_address`. Оставьте `nexo-data/` пустым; вы вот-вот его заполните.
  </Step>

  <Step title="Установите мост на каждый бэкенд">
    `NexoHubBridge.jar` рядом с Nexo, заполненные `hub.address` и `hub.secret`,
    `server_name: auto`.

    `Pack.server.type: HUB` в `plugins/Nexo/settings.yml` каждого бэкенда мост
    записывает при первом запуске. Мост также сохраняет `Pack.server` локально при
    каждом пуше, так что эта единственная настройка никогда не передаётся между
    серверами.
  </Step>

  <Step title="Сделайте копию plugins/Nexo/ каждого бэкенда">
    Это не опционально. После принятия и пуша файлы каждого бэкенда перезаписываются
    файлами хаба, и всё, что жило только на одном сервере и не попало в `nexo-data/`,
    исчезает с этого сервера.

    Внутри деревьев, которыми владеет хаб, файл, которого у него нет, удаляется,
    поэтому бэкенд не может сохранить то, что потеряла остальная сеть. За их
    пределами ничего не затрагивается. Файл, который существует на двух бэкендах с
    разным содержимым, сохраняет копию хаба.
  </Step>
</Steps>

## Выбор бэкенда для повышения

Выберите бэкенд, чьи файлы ближе всего к тому, что должно быть на каждом сервере. Всё,
что вы получите от него, — это на одну вещь меньше, которую придётся разбирать потом.

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

Прежде чем решить, сравните их. Если вы можете собрать папки на одной машине:

```bash theme={null}
diff -qr lobby/plugins/Nexo pvp/plugins/Nexo
```

Затем рассортируйте то, что получилось, на четыре кучки. Стоит сделать это на бумаге,
прежде чем что-либо трогать:

| Различие | Куда оно идёт |
| - | - |
| то, что должно было быть на каждом сервере | `_shared/`, поэтому повышайте бэкенд, у которого это есть |
| действительно индивидуальное для сервера, например другое значение в `settings.yml` | потом в `servers/<name>/` |
| одинаковое на нескольких серверах, но не на всех | потом в `groups/<name>/`, см. [управление файлами](/ru/guides/managing-files#groups) |
| сгенерировано Nexo или другим плагином | никуда; оно пересоберётся |

Последняя кучка больше, чем ожидают. `pack/pack.zip`, всё под `pack/external_packs/`,
`.assetCache/` и `.deobfCachedPacks/` — это выходные данные. Если два бэкенда
различаются там, это ничего не значит.

## Принятие

На прокси:

```
/nexohub adopt lobby
```

```
[NexoHub] Asked lobby for its plugins/Nexo/ folder.
[NexoHub] Watch this console. What it leaves under pack/external_packs/ is listed there by name.
```

На том бэкенде:

```
[NexoHubBridge] Sending 118 file(s), 2412 KiB, to the hub as 'lobby'.
[NexoHubBridge] The hub took these files; they are what the whole network builds from now.
```

И на прокси:

```
[nexohub] Adopted 118 file(s) from lobby into _shared/.
[nexohub] lobby kept 4 entr(y/ies) in pack/external_packs/, which adoption never carries:
[nexohub]   DefaultPack_5b8ebdadb1.zip: Nexo downloads this itself, on every backend
[nexohub]   ShizuArt_Tavern_Furniture.zip: nothing on that backend says it wrote this, so it looks like yours
[nexohub]   _hub-betterhud-abcdef12: the hub put it here, and it is replaced on every push
[nexohub]   betterhud.zip: BetterHud writes it, on every backend that runs it
[nexohub] 1 of those are not accounted for by any plugin there. Put them in
          nexo-data/_shared/pack/external_packs/ if the whole network should have them.
```

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

<Note>
  Если на сервере есть игрок, запрос приходит сразу же, иначе бэкенд подхватывает его при
  следующем опросе.

  Единственный случай, когда игрок необходим, — это бэкенд с `server_name: auto`, на
  котором никто ещё не был. Он пока не знает своё имя, поэтому с него нельзя принять
  файлы, пока кто-нибудь не зайдёт.
</Note>

### Что не передаётся

Наверх попадают только файлы, которые вы написали сами. Намеренно остаются на месте:

* `pack/pack.zip`, собранный пак
* всё под `pack/external_packs/`, что ваши плагины в любом случае пересоберут
* скрытые файлы и папки, так что `.assetCache/` и `.deobfCachedPacks/` остаются на месте
* резервные копии редакторов, заканчивающиеся на `~`
* всё, что больше 64 МБ

`external_packs/` — единственный пункт из этого списка, который стоит прочитать
внимательно, а не пробежать глазами, потому что там не только сгенерированные выходные
данные. Пак, который вы купили и положили прямо на бэкенд, тоже живёт там, и принятие
оставляет его точно так же, как оставляет собственный вывод плагина. Это сделано
намеренно: повышение копии этой папки с одного бэкенда заморозило бы его сборку в то, из
чего затем пересобирается каждый сервер.

Поэтому принятие называет то, что оно оставило, в обеих консолях и отделяет записи, на
которые претендует какой-либо плагин на этом бэкенде, от тех, на которые не претендует
ничто. Незаявленные — ваши. Загрузите их один раз в
`nexo-data/_shared/pack/external_packs/`, и с этого момента они будут у каждого бэкенда.
`.zip` работает там так же хорошо, как и распакованная папка.

### Почему сначала нужен запрос

Хаб отклоняет принятие, которое никто не запрашивал. Каждый бэкенд уже владеет
секретом, поэтому без этой проверки любой из них мог бы перезаписать ваши файлы в любой
момент.

Окно, которое открывает `/nexohub adopt`, действует пять минут и срабатывает один раз.
Если вы видите одно из этих сообщений, значит, произошло именно это:

```
no adoption was requested; run /nexohub adopt lobby on the proxy first
that request expired; run /nexohub adopt lobby again
```

### Если `_shared/` не пуст

Принятие записывает файлы бэкенда поверх `_shared/` без предварительной очистки, поэтому
файл, который есть там, но не на бэкенде, остаётся. Это нормально, когда вы принимаете
повторно после изменения, и вводит в заблуждение, когда вы начинаете с нуля.

Перед тем как что-либо перезаписать, делается снимок, так что если вы хотите чистый
лист, удалите `_shared/` по SFTP и примите файлы в пустую папку. Старая версия всё ещё
доступна в `/nexohub history`.

## После принятия

<Steps>
  <Step title="Проверьте, что всё парсится">
    ```
    /nexohub validate
    ```

    Правленный руками `plugins/Nexo/`, который год работал в продакшене, — хорошее
    место, чтобы найти файл, который никто не загружал с момента его создания.
  </Step>

  <Step title="Верните различия на место">
    Пройдитесь по кучкам, составленным ранее. Файлы для отдельных серверов идут в
    `servers/<name>/`, файлы, общие для нескольких серверов, — в группу, а всё
    остальное оставьте как есть.

    По возможности сохраните всё за один раз; хаб использует дебаунс, так что одна
    загрузка означает одну перезагрузку, а не по одной на каждый файл.
  </Step>

  <Step title="Посмотрите на каждый бэкенд">
    ```
    /nexohub status
    ```

    Каждый сервер должен быть `in sync` на одном и том же бандле, а имена слоёв рядом
    с каждым из них должны быть теми переопределениями, которые вы намеревались ему
    дать. Пустые серверы тоже, поскольку они отчитываются при своём опросе.
  </Step>

  <Step title="Запустите полную проверку">
    ```
    /nexohub doctor
    ```

    Вот момент, когда она себя оправдывает. Она скажет вам, могут ли игроки реально
    достучаться до `public_address`, не провалил ли какой-нибудь бэкенд свою
    перезагрузку и не стоят ли ваши бэкенды на версиях Nexo или Minecraft, которые
    соберут разные паки. Расхождение версий — обычное дело в сети, которая росла по
    одному серверу за раз, и его почти невозможно определить снаружи.
  </Step>

  <Step title="Зайдите на сервер и переключитесь">
    Скачайте пак один раз, попрыгайте между двумя серверами и следите, не начнётся ли
    второе скачивание. Одно скачивание — и миграция завершена. Если есть второе, см.
    [устранение неполадок](/ru/guides/troubleshooting#players-re-download-when-switching-servers).
  </Step>
</Steps>

## Если что-то пошло не так

Состояние до принятия находится в `/nexohub history`, под записью
`before adopting <server>`.

```
/nexohub rollback 1769508900000-77c1a2e5
```

Это возвращает `nexo-data/` назад и пушит его. О том, что откат делает с файлами,
добавленными после, см.
[как не сломать свою сеть](/ru/guides/safety#going-back).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.