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

Таблица текущих проблем — одна из системных таблиц, добавленная в версии 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."
}

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

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