Таблица текущих проблем системы

Таблица текущих проблем является одной из таблиц системы, добавленных в версии 1.16 RethinkDB. Запрос к ней возвращает проблемы, обнаруженные в кластере; в нормальной, без ошибок, работе она будет пустой. Таблица является только для чтения.

Запрос к этой таблице без фильтров возвращает список всех текущих проблем в кластере.

Примечание: как и другие таблицы системы, к таблице current_issues можно получить доступ только с помощью учётной записи пользователя admin.

r.db("rethinkdb").table("current_issues").run(conn, callback);

Схема документа

Проблемы, добавленные в таблицу, следуют той же структуре.

{
    id: "<uuid>",
    type: "<type>",
    critical: <bool>,
    info: {
        <type-specific fields>
    },
    description: "<type-specific string>"
}

• id: первичный ключ; он не меняется на протяжении всего жизненного цикла проблемы.
• type: короткая строка, указывающая тип проблемы. (В остальной части документа рассматриваются типы подробнее.)
• critical: true, если проблема, вероятно, приведёт к потере доступности.
• info: поля деталей; ключи и значения будут зависеть от типа проблемы.
• description: удобочитаемое описание проблемы, включая предложения по её решению.

Вы можете запросить конкретные типы проблем, отфильтровав поле type.

r.db("rethinkdb").table("current_issues").filter({type: "outdated_index"}).run(conn, callback);

Типы проблем

Обратите внимание, что если вы вызовете table с identifier_format установленным в uuid, то ссылки на серверы, таблицы и базы данных в поддокументе info будут UUID, а не именами.

Проблемы записи в журнал

type: "log_write_error"
critical: false
info: {
    servers: ["server_a", "server_b", ...],
    message: "<error message>"
}

RethinkDB не удалось записать в файл журнала (или в stdout/stderr). Строка message будет содержать ошибку, полученную RethinkDB от операционной системы при неудачной записи; servers будет списком затронутых серверов.

Найдите и устраните проблему, препятствующую записи сервера в журналы (например, освободите место на диске, если диск заполнен). Будет только одна проблема на каждое уникальное сообщение об ошибке — если несколько серверов столкнутся с одной и той же ошибкой, в таблице появится только одна проблема.

Проблемы с конфликтами имён

type: "server_name_collision" | "db_name_collision" | "table_name_collision"
critical: true
info: {
    name: "<name in conflict>",
    ids: ["<uuid1>", "<uuid2>", ...],
    db: "<name>"
}

(Поле db отсутствует, если type равно table_name_collision.)

Несколько серверов, баз данных или таблиц в одной базе данных получили одно и то же имя. Поле name показывает конфликтующее имя; ids — это UUID сущностей, имеющих это имя. В случае с table_name_collision, db будет базой данных, в которой находятся таблицы. Переименуйте конфликтующие сущности.

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

На каждое конфликтующее имя будет одна проблема.

Проблемы с устаревшими индексами

type: "outdated_index"
critical: false
info: {
    tables: [
        {
            table: "foo",
            db: "bar",
            indexes: ["ix1", "ix2", ...]
        }
    ]
}

Индексы, созданные с более ранней версией RethinkDB, необходимо перестроить из-за изменений в обработке индексов ReQL. Подробности о том, как перестроить индексы, см. в разделе «Мой вторичный индекс устарел».

Эта проблема будет отображаться в таблице current_issues только один раз — проверьте поле info для таблиц и индексов, на которые она влияет.

Проблемы доступности таблицы

type: "table_availability"
critical: true | false
info: {
    table: "foo",
    db: "bar",
    shards: [
        {
            primary_replicas: ["replica1"],
            replicas: [
                { server: "replica1", state: "ready" },
                { server: "replica2", state: "disconnected" }
            ]
        }
    ],
    status: {
        all_replicas_ready: false,
        ready_for_writes: false,
        ready_for_reads: true,
        ready_for_outdated_reads: true
    }
}

В кластере отсутствует хотя бы одна репликация таблицы. Строка description будет зависеть от ролей, которые исполняли отсутствующие сервера в таблице. Если таблица недоступна для чтения и/или записи, critical будет true; если таблица может использоваться для чтения и записи, она будет false.

Если таблица недоступна для чтения и/или записи, но все её серверы по-прежнему доступны, проблема не будет отображаться.

Эта проблема будет отображаться не более одного раза для каждой таблицы.

Проблемы с доступностью памяти

type: "memory_error"
critical: false
info: {
    servers: [ "server1" ],
    message: "Data from a process on this server has been placed into swap memory in the past hour. If the data is from RethinkDB, this may impact performance."
}

Это сообщение — предупреждение о том, что на сервере RethinkDB произошла ошибка страницы, и используется своп-пространство. В Linux это сообщение будет отображаться только если процесс RethinkDB начал подкачку памяти; в OS X — при подкачке любого процесса. Windows-версия RethinkDB не может определить, когда происходит подкачка.

Когда происходит подкачка в процессе RethinkDB, производительность ухудшается, и чем больше подкачки, тем хуже производительность. Вы можете попытаться решить эту проблему, убедившись, что другие приложения не используют физическую память на сервере, настроив кэш подкачки, скорректировав параметр ядра swappiness (подробнее см. в разделе Устранение неполадок) или добавив больше оперативной памяти на сервер.

Проблемы с подключением

type: "non_transitive_error"
critical: false
info: {
    servers: [ "server1", "server2" ],
    message: "Server connectivity is non-transitive."
}

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

Эта проблема будет отображаться не более одного раза для каждого сервера.