# Устранение неполадок

В данном разделе описаны некоторые часто встречающиеся проблемы,
возникающие при эксплуатации кластера Picodata, и предложены способы их
решения.

## Не удается включить плагин {: #plugin_enable_failure }

**Пример ошибки**

```shell
picodata> ALTER PLUGIN uroboros 0.2.10 ENABLE;
raft: proposal dropped
```

**Причина**

[Raft] не может обработать этот запрос. Например, в данный момент проходят перевыборы лидера кластера.

[Raft]: ../architecture/raft_failover.md

**Решение**

Повторить запрос через некоторое небольшое время (1–5 минут).
Подробности о состоянии Raft можно посмотреть в [консоли администратора] Picodata:

```lua title="Состояние Raft"
\lua
box.space._raft_state:fselect()
```

```lua title="Журнал Raft"
\lua
box.space._raft_log:fselect()
```

```lua title="Данные о main_loop, лидере Raft-группы, терме и т.д."
\lua
pico.raft_status()
```

Если инстанс кластера работает со сбоями, то более
подробную информацию можно получить в его выводе _stdout_.

[консоли администратора]: ../tutorial/connecting.md#admin_console

## Пользователь не может авторизоваться {: #admin_access_failure }

**Пример ошибки**

```shell
Enter password for user:
server responded with error: PasswordMismatch: User not found or supplied credentials are invalid
```

**Причина**

1. Для пользователя не был задан пароль (например, в новом кластере)
1. Для авторизации используется неверный пароль
1. Для авторизации используется неверный [метод аутентификации]
1. Пользователь был ранее явно заблокирован другим пользователем
1. Пользователь был ранее заблокирован из-за превышения попыток
неудачного входа (например, пароль пользователя был изменен, но для
авторизации по какой-то причине был несколько раз указан старый пароль)

[метод аутентификации]: access_control.md#auth_types

**Решение**

1. Если у пользователя нет пароля, то его нужно задать ([пример] для
   администратора)
1. Использовать верный пароль
1. Проверить, что для авторизации используется корректный [метод
аутентификации]. Данный совет актуален в том случае, если ранее для
пользователя этот метод был [переопределен]
1. Авторизоваться под другим пользователем с
административным доступом (если его нет, то использовать файл
[admin.sock]) и разблокировать пользователя:

```sql
ALTER USER user LOGIN;
```

[пример]: ../tutorial/connecting.md#set_admin_password
[admin.sock]: ../reference/cli.md#run_admin_sock
[переопределен]: ../reference/sql/alter_user.md#syntax

## Невозможно подключиться к инстансу {: #connection_failure }

**Пример ошибки**

```shell
Connection refused. Is the server running on that host and accepting TCP/IP connections?
pgbench: error: could not create connection for client 192
```

или

```sql
{ code: 24, kind: Uncategorized, message: "Too many open files" }
```

**Причина**

Причины, по которым подключение к инстансу завершается ошибкой,
разнообразны. Одна из них связана с тем, что при большом количестве
подключений на стороне сервера (инстанса Picodata) может быть исчерпан
лимит на файловые дескрипторы.

**Решение**

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

На уровне системы:

```shell
sudo sysctl -w fs.file-max=1048576
```

На уровне процесса:

```shell
sudo sysctl -w fs.nr_open=999999
```

Для персистентного хранения новых значений отредактируйте файл
`/etc/sysctl.conf`, вписав в него указанные параметры, и затем примените
изменения:

```shell
sudo sysctl -p
```

В ряде случаев может потребоваться увеличить ограничение, накладываемое
на ОС со стороны Systemd. Для этого отредактируйте файл
`/etc/systemd/system.conf`, вписав туда нужное значение параметра
`DefaultLimitNOFILE`.

!!! warning "Внимание!"

    Увеличение количества дескрипторов увеличит потребление системных
    ресурсов

## Выпадение инстанса из кластера {: #instance_detach }

**Описание**

Инстанс в какой-то момент выходит из состава кластера: находится в
состоянии `Offline`. Перезапуск инстанса не помогает.

**Причина**

Инстанс содержит устаревшие данные, не позволяющие ему в текущем виде
присоединиться к кластеру

**Решение**

- остановить проблемный инстанс
- узнать его UUID, например, с помощью команды `picodata status --peer <любой работающий инстанс>`
- исключить проблемный инстанс из кластера: `picodata expel <UUID> --peer <любой работающий инстанс> --cluster-name <имя кластера>`
- удалить [snap- и xlog-файлы](../architecture/instance_runtime_files.md) проблемного инстанса
- запустить проблемный инстанс

!!! note "Примечание"
    Если инстанс управляется службой Systemd, то для остановки/запуска
    следует использовать соответствующие варианты команды `systemctl`

## Проблема уязвимости кластера из-за указания одного инстанса в instance.peer {: #instance_peer_failure }

**Описание**

В кластере с несколькими тирами и большим числом репликасетов
недоступность инстанса, указанного как `instance.peer`, может привести к
невозможности добавления новых инстансов в кластер.

**Причина**

В руководстве [Создание кластера](../tutorial/deploy.md) приведены
примеры файлов конфигурации для кластера из нескольких тиров. Поскольку
это все еще небольшой кластер, для всех его инстансов рекомендовано
использовать один и тот же `instance.peer` — это первый инстанс
кластера. Однако, при масштабировании кластера и разделении его частей
на функциональные роли с помощью тиров, такой подход может быть
неоптимальным: недоступность `instance.peer` будет влиять на
невозможность расширения кластера, а также возникнет проблема при
ребутстрапе самого инстанса, указанного в `instance.peer` (он не будет
видеть сам себя).

**Решение**

Для сложных кластеров рекомендуется использовать для параметра `peer`
массив инстансов. Например:

```yaml
peer:
  - 192.168.101.167:3301
  - 192.168.101.168:3301
  - 192.168.101.166:3301
```

Желательно, чтобы эти инстансы были расположены на разных серверах
кластера.

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

## Сообщение об ошибке повторного подключения к репликасету {: #instance_restart_error_messages }

**Описание**

Когда инстанс перезапускается и заново подключается к мастер-реплике
своего репликасета, в журнале сообщений инстанса можно увидеть сообщение
об ошибке следующего вида:

```shell
localhost [3369449] main/392/applier/pico_service@192.169.1.7:3190 box.cc:4483 E> ER_CFG: Incorrect value for option 'replication': duplicate connection with the same replica UUID
```

**Причина**

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

**Решение**

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