Версия:

Руководство пользователя / Tarantool Cartridge / Руководство администратора по Tarantool Cartridge
Руководство пользователя / Tarantool Cartridge / Руководство администратора по Tarantool Cartridge

Руководство администратора по Tarantool Cartridge

Руководство администратора по Tarantool Cartridge

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

Примечание

Дополнительную информацию по управлению экземплярами Tarantool’а см. в разделе Администрирование серверной части.

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

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

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

my_app.router: {"advertise_uri": "localhost:3301", "http_port": 3301, "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

И загрузите кластер. Это можно сделать через веб-интерфейс, который доступен по адресу http://<имя_хоста_экземпляра>:<http_порт_экземпляра> (в данном примере: http://localhost:3301).

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

  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

     

    Для получения дополнительной информации о сегментах и весах набора реплик см. документацию по модулю vshard.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. The cluster validates the configuration update by checking if the new instance is available using the membership module.

    Примечание

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

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

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

  3. Как только новый экземпляр понимает, что кластер знает о нем, экземпляр вызывает функцию box.cfg и начинает работу.

    Дополнительную информацию см. в :ref:`справочнике по вложенному модулю box.cfg <box_introspection-box_cfg>`_.

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

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

  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"]
        )
    }
    

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

Балансировка (решардинг) запускается через определенные промежутки времени и при добавлении в кластер нового набора реплик с весом, отличным от нуля. Для получения дополнительной информации см. раздел по балансировке в документации по модулю vshard.

Самый удобный способ мониторинга процесса балансировки заключается в том, чтобы отслеживать количество активных сегментов на узлах хранения. Сначала в новом наборе реплик 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

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

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

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

  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

 

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

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

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

  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 = {...} } -- подписка

Мониторинг кластера через 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 с.) – Оранжевый.

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

    Решение: Проверьте статус репликации на реплике. Более подробные инструкции приведены в руководстве по разрешению проблем по.

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

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

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

    Решение: Проверьте статус репликации на реплике. Более подробные инструкции приведены в руководстве по разрешению проблем по.

  • 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.

Разрешение проблем

См. Руководство по разрешению проблем.

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

См. раздел Аварийное восстановление.

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

См. раздел Резервное копирование.