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

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

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

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