Top.Mail.Ru
Tarantool » latest » Tarantool Cartridge » Administrator’s guide
 
Tarantool Cartridge / Administrator’s guide
Tarantool Cartridge / Administrator’s guide

Administrator’s guide

Administrator’s guide

В данном руководстве рассматривается развертывание и управление кластером Tarantool’а с помощью Tarantool Cartridge.

Примечание

For more information on managing Tarantool instances, see the server administration section of the Tarantool manual.

Перед тем, как развертывать кластер, ознакомьтесь с понятием кластерных ролей и разверните экземпляры Tarantool’а в соответствии с предполагаемой топологией кластера.

Развертывание кластера

Чтобы развернуть кластер, сначала настройте все экземпляры Tarantool’а в соответствии с предполагаемой топологией кластера, например:

my_app.router: {"advertise_uri": "localhost:3301", "http_port": 8080, "workdir": "./tmp/router"}
my_app.storage_A_master: {"advertise_uri": "localhost:3302", "http_enabled": False, "workdir": "./tmp/storage-a-master"}
my_app.storage_A_replica: {"advertise_uri": "localhost:3303", "http_enabled": False, "workdir": "./tmp/storage-a-replica"}
my_app.storage_B_master: {"advertise_uri": "localhost:3304", "http_enabled": False, "workdir": "./tmp/storage-b-master"}
my_app.storage_B_replica: {"advertise_uri": "localhost:3305", "http_enabled": False, "workdir": "./tmp/storage-b-replica"}

Затем, запустите экземпляры, например, используя CLI в cartridge:

cartridge start my_app --cfg demo.yml --run_dir ./tmp/run --foreground

And bootstrap the cluster. You can do this via the Web interface which is available at http://<instance_hostname>:<instance_http_port> (in this example, http://localhost:8080).

В веб-интерфейсе выполните следующие действия:

  1. В зависимости от статуса аутентификации:

    • Если аутентификация включена (в эксплуатационной среде), введите свои учетные данные и нажмите Login (Войти):

      ../../../_images/auth_creds-border-5px.png

       

    • Если отключен (для удобства тестирования), просто переходите к настройке кластера.

  2. Нажмите Configure (Настроить) рядом с первым ненастроенным сервером, чтобы создать первый набор реплик исключительно для роутера (для обработки ресурсоемких вычислений).

    ../../../_images/unconfigured-router-border-5px.png

     

    Во всплывающем окне отметьте флажок роли vshard-router или любой пользовательской роли, для которой роль vshard-router будет зависимой (в данном примере это пользовательская роль под названием app.roles.api).

    (Необязательно) Укажите отображаемое имя для набора реплик, например router.

    ../../../_images/create-router-border-5px.png

     

    Примечание

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

    Нажмите Create replica set (Создать набор реплик), и созданный набор реплик отобразится в веб-интерфейсе

    ../../../_images/router-replica-set-border-5px.png

     

    Предупреждение

    Обратите внимание: после того, как экземпляр подключится к набору реплик, НЕВОЗМОЖНО это отменить или переподключить его к другому набору реплик.

  3. Создайте новый набор реплик для мастер-узлов хранения данных (для обработки большого количества транзакций).

    Отметьте флажок роли vshard-storage или любой пользовательской роли, для которой роль vshard-storage будет зависимой (в данном примере это пользовательская роль под названием app.roles.storage).

    (Необязательно) Задайте определенную группу, например hot (горячие). Наборы реплик с ролями vshard-storage могут относиться к различным группам. В нашем примере группы hot и cold предназначены для независимой обработки горячих и холодных данных соответственно. Эти группы указаны в конфигурационном файле кластера. По умолчанию, кластер не входит ни в одну группу.

    (Необязательно) Укажите отображаемое имя для набора реплик, например hot-storage.

    Нажмите Create replica set (Создать набор реплик).

    ../../../_images/create-storage-border-5px.png

     

  4. (Необязательно) Если этого требует топология, добавьте во второй набор реплик дополнительные хранилища:

    1. Нажмите Configure (Настроить) рядом с другим ненастроенным сервером, который выделен для рабочей нагрузки с большим количеством транзакций.

    2. Нажмите на вкладку Join Replica Set (Присоединиться к набору реплик).

    3. Выберите второй набор реплик и нажмите Join replica set (Присоединиться к набору реплик), чтобы добавить к нему сервер.

      ../../../_images/join-storage-border-5px.png

       

  5. В зависимости от топологии кластера:

    • добавьте дополнительные экземпляры к первому или второму набору реплик, или же
    • создайте дополнительные наборы реплик и добавьте в них экземпляры для обработки определенной рабочей нагрузки (вычисления или транзакции).

    Например:

    ../../../_images/final-cluster-border-5px.png

     

  6. (Необязательно) По умолчанию все новые наборы реплик vshard-storage получают вес, равный 1, до загрузки vshard в следующем шаге.

    Примечание

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

    Чтобы разные наборы реплик хранили разное количество сегментов, нажмите Edit (Изменить) рядом с набором реплик, измените значение веса по умолчанию и нажмите Save (Сохранить):

    ../../../_images/change-weight-border-5px.png

     

    For more information on buckets and replica set’s weights, see the vshard module documentation.

  7. Загрузите vshard, нажав соответствующую кнопку или же выполнив команду cartridge.admin.boostrap_vshard() в административной консоли.

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

    С этого момента всю настройку кластера можно выполнять через веб-интерфейс.

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

Конфигурация кластера задается в конфигурационном файле формата YAML. Этот файл включает в себя топологию кластера и описания ролей.

У всех экземпляров в кластере Tarantool’а одинаковые настройки. Для этого каждый экземпляр в кластере хранит копию конфигурационного файла, а кластер синхронизирует эти копии: как только вы подтверждаете обновление конфигурации в веб-интерфейсе, кластер валидирует ее (и отклоняет неприемлемые изменения) и передает ее автоматически по всему кластеру.

Чтобы обновить конфигурацию:

  1. Нажмите на вкладку Configuration files (Конфигурационные файлы).

  2. (Необязательно) Нажмите Downloaded (Загруженные), чтобы получить текущую версию конфигурационного файла.

  3. Обновите конфигурационный файл.

    Можно добавлять/изменять/удалять любы разделы, кроме системных: topology, vshard и vshard_groups.

    Чтобы удалить раздел, просто удалите его из конфигурационного файла.

  4. Создайте сжатую копию конфигурационного файла в виде архива в формате .zip и нажмите кнопку Upload configuration (Загрузить конфигурацию), чтобы загрузить ее.

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

Управление кластером

В данной главе описывается, как:

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

Изменение топологии кластера

При добавлении нового развернутого экземпляра в новый или уже существующий набор реплик:

  1. Кластер валидирует обновление конфигурации, проверяя доступность нового экземпляра с помощью модуля membership.

    Примечание

    Модуль membership работает по протоколу UDP и может производить операции до вызова функции box.cfg.

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

  2. Новый экземпляр ожидает, пока другой экземпляр в кластере не получит обновление конфигурации (оповещение реализовано с помощью того же модуля membership). На этом шаге у нового экземпляра еще нет своего UUID.

  3. Once the instance realizes its presence is known to the cluster, it calls the box.cfg function and starts living its life.

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

Чтобы добавить в кластер новые узлы, выполните следующие действия:

  1. Разверните новые экземпляры Tarantool, как описано в разделе по развертыванию.

    Если новые узлы не появились в веб-интерфейсе, нажмите Probe server (Найти сервер) и укажите их URI вручную.

    ../../../_images/probe-server-border-5px.png

     

    Если узел доступен, он появится в списке.

  2. В веб-интерфейсе:

    • Создайте новый набор реплик с одним из новых экземпляров: нажмите Configure (Настроить) рядом с ненастроенным сервером, отметьте флажками необходимые роли и нажмите Create replica set (Создать набор реплик):

      Примечание

      Если вы добавляете экземпляр vshard-storage, следует помнить, что вес всех таких экземпляров по умолчанию становится равным 0 после начальной загрузки vshard, которая происходит во время первоначального развертывания кластера.

      ../../../_images/zero-border-5px.png

       

    • Или добавьте дополнительные экземпляры к существующему набору реплик: нажмите Configure (Настроить) рядом с ненастроенным сервером, нажмите на вкладку Join replica set (Присоединиться к набору реплик), выберите набор реплик и нажмите Join replica set.

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

  3. При развертывании нового набора реплик vshard-storage заполните необходимую информацию: нажмите Edit (Изменить) рядом с необходимым набором реплик, увеличьте его вес и нажмите Save (Сохранить), чтобы начать балансировку данных.

Вместо веб-интерфейса можно использовать GraphQL для просмотра и изменения топологии кластера. Конечная точка кластера для выполнения запросов GraphQL – /admin/api. Можно пользоваться любыми сторонними клиентами GraphQL, такими как GraphiQL или Altair.

Примеры:

  • вывод списка всех серверов в кластере:

    query {
        servers { alias uri uuid }
    }
    
  • вывод списка всех наборов реплик с серверами:

    query {
        replicasets {
            uuid
            roles
            servers { uri uuid }
        }
    }
    
  • подключение сервера к новому набору реплик с включенной ролью хранилища:

    mutation {
        join_server(
            uri: "localhost:33003"
            roles: ["vshard-storage"]
        )
    }
    

Балансировка данных

Rebalancing (resharding) is initiated periodically and upon adding a new replica set with a non-zero weight to the cluster. For more information, see the rebalancing process section of the vshard module documentation.

Самый удобный способ мониторинга процесса балансировки заключается в том, чтобы отслеживать количество активных сегментов на узлах хранения. Сначала в новом наборе реплик 0 активных сегментов. Через некоторое время фоновый процесс балансировки начинает переносить сегменты из других наборов реплик в новый. Балансировка продолжается до тех пор, пока данные не будут распределены равномерно по всем наборам реплик.

Чтобы отслеживать текущее количество сегментов, подключитесь к любому экземпляру Tarantool через административную консоль и выполните команду:

tarantool> vshard.storage.info().bucket
---
- receiving: 0
  active: 1000
  total: 1000
  garbage: 0
  sending: 0
...

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

Для получения дополнительной информации о параметрах мониторинга см. раздел по мониторингу хранилищ.

Отключение наборов реплик

Под отключением всего набора реплик (например, для технического обслуживания) подразумевается перемещение всех его сегментов в другие наборы реплик.

Чтобы отключить набор реплик, выполните следующие действия:

  1. Нажмите Edit (Изменить) рядом с необходимым набором реплик.

  2. Укажите 0 как значение веса и нажмите Save (Сохранить):

    ../../../_images/zero-weight-border-5px.png

     

  3. Подождите, пока процесс балансировки не завершит перенос всех сегментов набора. Можно отслеживать текущее количество сегментов, как описано в разделе по балансировке данных.

Исключение экземпляров

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

Чтобы исключить экземпляр из кластера, нажмите рядом с ним, затем нажмите Expel server (Исключить сервер) и Expel:

../../../_images/expelling-instance-border-5px.png

 

Примечание

There are two restrictions:

  • You can’t expel a leader if it has a replica. Switch leadership first.
  • You can’t expel a vshard-storage if it has buckets. Set the weight to zero and wait until rebalancing is completed.

Включение автоматического восстановления после отказа,

В конфигурации кластера мастер-реплика с включенным автоматическим восстановлением после отказа, если происходит отказ указанного пользователем мастера из любого набора реплик, кластер автоматически выбирает следующую реплику из списка приоритетов и назначает ей роль активного мастера (чтение/запись). Когда вышедший из строя мастер возвращается к работе, его роль восстанавливается, и активный мастер снова становится репликой (только для чтения). Это работает для всех ролей.

Чтобы задать приоритет в наборе реплик:

  1. Нажмите Edit (Изменить) рядом с необходимым набором реплик.

  2. Выполните прокрутку в окне Edit replica set (Изменить набор реплик), чтобы увидеть весь список серверов.

  3. Перенесите реплики на необходимые места в списке приоритета и нажмите Save (Сохранить):

    ../../../_images/failover-priority-border-5px.png

     

По умолчанию, автоматическое восстановление после отказа отключено. Чтобы включить его:

  1. Нажмите Failover (Восстановление после отказа):

    ../../../_images/failover-border-5px.png

     

  2. В окне Failover control (Управление восстановлением после отказа) нажмите Enable (Включить):

    ../../../_images/failover-control-border-5px.png

     

Статус восстановления после отказа изменится на enabled (включено):

../../../_images/enabled-failover-border-5px.png

 

For more information, see the replication section of the Tarantool manual.

Смена мастера в наборе реплик

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

  1. Нажмите кнопку Edit (Изменить) рядом с необходимым набором реплик:

    ../../../_images/edit-replica-set-border-5px.png

     

  2. Выполните прокрутку в окне Edit replica set (Изменить набор реплик), чтобы увидеть весь список серверов. Мастером будет верхний сервер.

    ../../../_images/switch-master-border-5px.png

     

  3. Перенесите необходимый сервер наверх и нажмите Save (Сохранить).

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

Управление пользователями

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

../../../_images/users-tab-border-5px.png

 

Обратите внимание, что вкладка Users (Пользователи) доступна только в том случае, если в веб-интерфейсе реализована авторизация.

Кроме того, некоторые функции (например, удаление пользователей) можно отключить в конфигурации кластера, что регулируется при помощи настройки auth_backend_name, которая передается в cartridge.cfg().

Устранение конфликтов

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

Для предотвращения конфликтов используется специальный триггер space.before_replace. Он выполняется каждый раз перед внесением изменений в таблицу, для которой он был настроен. Функция триггера реализована на языке программирования Lua. Эта функция принимает в качестве аргументов исходные значения изменяемого кортежа и новые значения. Функция возвращает значение, которое используется для изменения результата операции: это будет новое значение измененного кортежа.

Для операций вставки старое значение отсутствует, поэтому в качестве первого аргумента передается нулевое значение nil.

Для операций удаления отсутствует новое значение, поэтому нулевое значение nil передается в качестве второго аргумента. Функция триггера также может возвращать нулевое значение nil, превращая эту операцию в удаление.

В примере ниже показано, как использовать триггер space.before_replace, чтобы предотвратить конфликты репликации. Предположим, у нас есть таблица box.space.test, которая изменяется в нескольких репликах одновременно. В этой таблице мы храним одно поле полезной нагрузки. Чтобы обеспечить согласованность, мы также сохраняем время последнего изменения в каждом кортеже этой таблицы и устанавливаем триггер space.before_replace, который отдает предпочтение новым кортежам. Ниже приведен код на Lua:

fiber = require('fiber')
-- определение функции, которая изменит функцию test_replace(tuple)
        -- добавление временной метки к каждому кортежу в спейсе
        tuple = box.tuple.new(tuple):update{{'!', 2, fiber.time()}}
        box.space.test:replace(tuple)
end
box.cfg{ } -- восстановление из локальной директории
-- настройка триггера во избежание конфликтов
box.space.test:before_replace(function(old, new)
        if old ~= nil and new ~= nil and new[2] < old[2] then
                return old -- игнорирование запроса
        end
        -- либо применение как есть
end)
box.cfg{ replication = {...} } -- подписка

Monitoring a cluster via CLI

В данном разделе описываются параметры, которые можно отслеживать в административной консоли.

Подключение к узлам через CLI

В каждом узле Tarantool (роутер/хранилище) есть административная консоль (интерфейс командной строки) для отладки, мониторинга и разрешения проблем. Консоль выступает в качестве интерпретатора Lua и отображает результат в удобном для восприятия формате YAML. Чтобы подключиться к экземпляру Tarantool через консоль, выполните команду:

$ tarantoolctl connect <имя_хоста_экземпляра>:<порт>

где <имя_хоста_экземпляра>:<порт> – это URI данного экземпляра.

Мониторинг хранилищ

Для получения информации об узлах хранения данных используйте vshard.storage.info().

Пример вывода

tarantool> vshard.storage.info()
---
- replicasets:
    <replicaset_2>:
    uuid: <replicaset_2>
    master:
        uri: storage:storage@127.0.0.1:3303
    <replicaset_1>:
    uuid: <replicaset_1>
    master:
        uri: storage:storage@127.0.0.1:3301
  bucket: <!-- buckets status
    receiving: 0 <!-- buckets in the RECEIVING state
    active: 2 <!-- buckets in the ACTIVE state
    garbage: 0 <!-- buckets in the GARBAGE state (are to be deleted)
    total: 2 <!-- total number of buckets
    sending: 0 <!-- buckets in the SENDING state
  status: 1 <!-- the status of the replica set
  replication:
    status: disconnected <!-- the status of the replication
    idle: <idle>
  alerts:
  - ['MASTER_IS_UNREACHABLE', 'Master is unreachable: disconnected']

Список состояний

Код Уровень критичности Описание
0 Зеленый Набор реплик работает в обычном режиме.
1 Желтый Есть некоторые проблемы, но они не влияют на эффективность набора реплик (их стоит отметить, но они не требуют немедленного вмешательства).
2 Оранжевый Набор реплик не восстановился после сбоя.
3 Красный Набор реплик отключен.

Возможные проблемы

  • MISSING_MASTER — В конфигурации набора реплик отсутствует мастер-узел.

    Уровень критичности: Оранжевый.

    Состояние кластера: Ухудшение работы запросов на изменение данных к набору реплик.

    Решение: Задайте мастер-узел для набора реплик, используя API.

  • UNREACHABLE_MASTER — Отсутствует соединение между мастером и репликой.

    Уровень критичности:

    • Если значение бездействия не превышает порог T1 (1 с.) – Желтый,
    • Если значение бездействия не превышает порог T2 (5 с.) – Оранжевый,
    • Если значение бездействия не превышает порог T3 (10 с.) – Красный.

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

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

  • LOW_REDUNDANCY — У мастера есть доступ только к одной реплике.

    Уровень критичности: Желтый.

    Состояние кластера: Коэффициент избыточности хранения данных равен 2. Он ниже минимального рекомендуемого значения для использования в производстве.

    Решение: Проверить конфигурацию кластера:

    • Если в конфигурации указан только один мастер и одна реплика, рекомендуется добавить хотя бы еще одну реплику, чтобы коэффициент избыточности достиг 3.
    • Если в конфигурации указаны три или более реплик, проверьте статусы реплик и сетевое соединение между репликами.
  • INVALID_REBALANCING — Нарушен инвариант балансировки. Во время миграции узел хранения может либо отправлять сегменты, либо получать их. Поэтому не должно быть так, чтобы набор реплик отправлял сегменты в один набор реплик и одновременно получал сегменты из другого набора реплик.

    Уровень критичности: Желтый.

    Состояние кластера: Балансировка приостановлена.

    Решение: Есть две возможные причины нарушения инварианта:

    • Отказ балансировщика.
    • Статус сегмента был изменен вручную.

    В любом случае обратитесь в техническую поддержку Tarantool’а.

  • HIGH_REPLICATION_LAG — Отставание реплики превышает порог T1 (1 с.).

    Уровень критичности:

    • Если отставание не превышает порог T1 (1 с.) – Желтый;
    • Если отставание не превышает порог T2 (5 с.) – Оранжевый.

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

    Solution: Check the replication status of the replica. Further instructions are given in the Tarantool troubleshooting guide.

  • OUT_OF_SYNC — Произошла рассинхронизация. Отставание превышает порог T3 (10 с.).

    Уровень критичности: Красный.

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

    Solution: Check the replication status of the replica. Further instructions are given in the Tarantool troubleshooting guide.

  • UNREACHABLE_REPLICA — Одна или несколько реплик недоступны.

    Уровень критичности: Желтый.

    Состояние кластера: Коэффициент избыточности хранения данных для данного набора реплик меньше заданного значения. Если реплика стоит следующей в очереди на балансировку (в соответствии с настройками веса), запросы перенаправляются в реплику, которая все еще находится в очереди.

    Решение: Проверьте сообщение об ошибке и выясните, какая реплика недоступна. Если реплика отключена, включите ее. Если это не поможет, проверьте состояние сети.

  • UNREACHABLE_REPLICASET — Все реплики, кроме текущей, недоступны. Уровень критичности: Красный.

    Состояние кластера: Реплика хранит устаревшие данные.

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

Мониторинг роутеров

Для получения информации о роутерах используйте vshard.router.info().

Пример вывода

tarantool> vshard.router.info()
---
- replicasets:
    <replica set UUID>:
      master:
        status: <available / unreachable / missing>
        uri: <!-- URI мастера
        uuid: <!-- UUID экземпляра
      replica:
        status: <available / unreachable / missing>
        uri: <!-- URI реплики, используемой для запросов
        uuid: <!-- UUID экземпляра
      uuid: <!-- UUID набора реплик
    <replica set UUID>: ...
    ...
  status: <!-- статус роутера
  bucket:
    known: <!-- количество сегментов с известным местом назначения
    unknown: <!-- количество других сегментов
  alerts: [<alert code>, <alert description>], ...

Список состояний

Код Уровень критичности Описание
0 Зеленый Роутер работает в обычном режиме.
1 Желтый Некоторые реплики недоступны, что влияет на скоость выполнения запросов на чтение.
2 Оранжевый Работа запросов на изменение данных ухудшена.
3 Красный Работа запросов на чтение данных ухудшена.

Возможные проблемы

Примечание

В зависимости от характера проблемы используйте либо UUID реплики, либо UUID набора реплик.

  • MISSING_MASTER — В конфигурации одного или нескольких наборов реплик не указан мастер.

    Уровень критичности: Оранжевый.

    Состояние кластера: Частичное ухудшение работы запросов на изменение данных.

    Решение: Укажите мастера в конфигурации.

  • UNREACHABLE_MASTER — Роутер потерял соединение с мастером одного или нескольких наборов реплик.

    Уровень критичности: Оранжевый.

    Состояние кластера: Частичное ухудшение работы запросов на изменение данных.

    Решение: Восстановите соединение с мастером. Сначала проверьте, включен ли мастер. Если он включен, проверьте состояние сети.

  • SUBOPTIMAL_REPLICA — Восстановите соединение с мастером. Сначала проверьте, включен ли мастер. Если он включен, проверьте состояние сети.

    Уровень критичности: Желтый.

    Состояние кластера: Запросы только на чтение направляются на резервную реплику.

    Решение: Проверьте статус оптимальной реплики и ее сетевого подключения.

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

    Уровень критичности: Красный.

    Состояние кластера: Частичное ухудшение работы запросов на изменение данных и на чтение данных.

    Решение: В наборе реплик недоступны мастер и реплика. Проверьте сообщение об ошибке, чтобы найти этот набор реплик. Исправьте ошибку, как описано в решении ошибки UNREACHABLE_REPLICA.

Аварийное восстановление

Please see the disaster recovery section in the Tarantool manual.

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

Please see the backups section in the Tarantool manual.