Системные таблицы

Начиная с версии 1.16, RethinkDB поддерживает специальные системные таблицы, которые содержат конфигурационную и статусную информацию о серверах, базах данных, отдельных таблицах и проблемах кластера. Запрос к системным таблицам возвращает информацию о состоянии кластера и текущих объектах (таких как серверы и таблицы) внутри кластера. Внося или удаляя записи и обновляя поля в этих таблицах, можно изменить конфигурацию представляемых ими объектов.

Обзор

Доступ к системным таблицам осуществляется через базу данных rethinkdb. Эти таблицы не являются реальными хранилищами документов RethinkDB так, как пользовательские таблицы, а скорее “таблично-подобные” интерфейсы к системе, позволяющие использовать большинство команд ReQL для управления. Системные таблицы нельзя создавать, удалять, переконфигурировать или переименовывать.

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

Примечание: Начиная с версии 2.3, только пользователь admin может получить доступ к системным таблицам. Подробнее об учетных записях и разрешениях см. в разделе Разрешения и учетные записи пользователей.

Таблицы

• table_config хранит конфигурации таблиц, включая фрагментацию и репликацию. Записывая в table_config, вы можете создавать, удалять и переконфигурировать таблицы.
• server_config хранит имена серверов и теги. Записывая в эту таблицу, вы можете переименовывать серверы и назначать им теги.
• db_config хранит UUID и имена баз данных. Записывая в эту таблицу, можно создавать, удалять или изменять базы данных.
• cluster_config хранит ключ аутентификации для кластера.
• table_status — это только для чтения таблица, которая возвращает состояние и конфигурацию таблиц в системе.
• server_status — это только для чтения таблица, которая возвращает информацию о процессе и хост-машине для каждого сервера.
• current_issues — это только для чтения таблица, которая возвращает статистику о проблемах кластера. Подробнее см. в документации текущей таблицы системных проблем.
• users хранит учетные записи пользователей RethinkDB. (См. Разрешения и учетные записи пользователей.)
• permissions хранит разрешения и области, связанные с учетными записями пользователей RethinkDB. (См. Разрешения и учетные записи пользователей.)
• jobs перечисляет задачи — запросы, создание индексов, уплотнение дисков и другие задачи утилиты, на которых тратит время кластер, а также позволяет прерывать выполняемые запросы.
• stats — это только для чтения таблица, которая возвращает статистику о кластере.
• logs — это только для чтения таблица, которая хранит журналы сообщений со всех серверов в кластере.

Ограничения

• Хотя системные таблицы поддерживают потоки изменений, они не поддерживают все цепочки, которые есть у реальных таблиц. Например, агрегация (max и min) и limit команды не будут работать с системными таблицами.
• Некоторые системные таблицы предназначены только для чтения. Системные таблицы, допускающие запись, требуют определенной структуры документа, описанной ниже.
• Операции записи в системные таблицы не являются атомарными. Избегайте записи в одну и ту же строку системной таблицы более чем с одного клиента одновременно.
• Аргумент durability при операциях записи игнорируется для системных таблиц.

Только с системными таблицами команда table принимает новый аргумент, identifier_format. Допустимые значения — name и uuid. Когда он установлен в uuid, ссылки в системных таблицах на базы данных или другие таблицы будут UUID, а не названиями баз данных/таблиц. Это полезно для написания скриптов и административных задач, так как UUID остаются неизменными даже если имена объектов меняются. По умолчанию установлено значение name.

Конфигурационные таблицы

table_config

Фрагментацию и репликацию можно контролировать через таблицу table_config, а также более продвинутые настройки подтверждения записи и надежности. Таблицы также можно переименовать, изменив их строки. Типичная строка в таблице table_config будет выглядеть так:

{
    id: "31c92680-f70c-4a4b-a49e-b238eb12c023",
    name: "tablename",
    db: "test",
    primary_key: "id",
    shards: [
        {
            primary_replica: "a",
            "replicas": ["a", "b"],
            "nonvoting_replicas": []
        },
        {
            primary_replica: "b",
            "replicas": ["a", "b"]
            "nonvoting_replicas": []
        }
    ],
    indexes: ["index1", "index2"],
    write_acks: "majority",
    durability: "hard"
}

• id: UUID таблицы. Только для чтения.
• name: имя таблицы.
• db: база данных, в которой находится таблица, либо имя, либо UUID в зависимости от значения identifier_format. Только для чтения.
• primary_key: имя поля, используемого в качестве первичного ключа таблицы, заданного при создании таблицы. Только для чтения.
• shards: список фрагментов таблицы. Каждый фрагмент — это объект с этими полями:
  • primary_replica: имя или UUID сервера, действующего в качестве основного сервера фрагмента. Если primary_replica имеет значение null, таблица будет недоступна. Это может произойти, если сервер, действующий в качестве основного фрагмента, удален.
  • replicas: список серверов, включая основной, хранящих реплики фрагмента.
  • nonvoting_replicas: список серверов, которые не участвуют в “голосовании” в рамках процесса переключения. Если это поле опущено, оно рассматривается как пустой список. Этот список должен быть подмножеством поля replicas и не должен содержать первичную реплику.
• indexes: список вторичных индексов в таблице. Только для чтения.
• write_hook: настроенный обработчик записи для этой таблицы, если таковой имеется. Только для чтения.
  • function: двоичное представление функции обработчика записи,
  • query: представление функции обработчика записи в виде строки ReQL
• write_acks: настройки подтверждения записи для таблицы. Если установлено значение majority (по умолчанию), записи будут подтверждаться, когда большинство реплик подтвердят свои записи; если установлено значение single, записи будут подтверждаться, когда одну реплику подтвердит свою запись.
• durability: soft или hard (по умолчанию). В режиме надежности hard записи сохраняются на диск до отправки подтверждений; в режиме soft записи подтверждаются немедленно после получения. Режим soft быстрее, но немного менее устойчив к сбоям.

Если вы delete строку из table_config, таблица будет удалена. Если вы insert строку, поля name и db обязательны; другие поля необязательны и будут автоматически сгенерированы или установлены по умолчанию, если они не указаны. Не включайте поле id. Система автоматически сгенерирует UUID.

Если вы replace строку в table_config, вы должны указать все поля. Обычно легче update конкретные поля.

Собственные команды ReQL, такие как reconfigure, также управляют фрагментацией и репликацией, и если вы не используете теги серверов, вы можете изменить настройки фрагментации/репликации в веб-интерфейсе. Подробнее см. в разделе Фрагментация и репликация.

server_config

Эта таблица хранит имена серверов вместе с их тегами. Теги серверов группируют серверы в логические группы: серверы могут быть помечены по назначению (база данных, приложение и т. д.) или по расположению в дата-центре (“us_west”, “us_east”, “london” и так далее). Подробнее о тегах серверов см. в разделе Фрагментация и репликация.

Каждый сервер, который когда-либо входил в кластер и не был удален, будет иметь строку в этой таблице в следующем формате.

{
    id: "de8b75d1-3184-48f0-b1ef-99a9c04e2be5",
    name: "servername",
    tags: ["default"],
    cache_size_mb: "auto"
}

• id: UUID сервера. (Только для чтения.)
• name: имя сервера.
• tags: список неупорядоченных тегов, связанных с сервером.
• cache_size_mb: размер кэша сервера, либо число (желаемый размер в мегабайтах), либо "auto" (пусть сервер решит при запуске на основе доступной памяти системы).

Если теги не указаны при запуске сервера, серверу автоматически назначается тег default. Документы не могут быть вставлены в server_config. Новый документ создается, когда сервер подключается к кластеру.

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

db_config

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

{
    id: "de8b75d1-3184-48f0-b1ef-99a9c04e2be5",
    name: "dbname"
}

• id: UUID базы данных. (Только для чтения.)
• name: имя базы данных.

Документы могут быть вставлены для создания новых баз данных, удалены для удаления баз данных и изменены для переименования баз данных. (Переименование баз данных — единственная задача, требующая запроса к таблице db_config; для двух других задач существуют собственные команды ReQL, dbCreate и dbDrop.) Как и в случае с таблицами, если вы insert базу данных, не включайте поле id: система сгенерирует UUID автоматически.

cluster_config

Таблица cluster_config содержит только одну строку. Документы не могут быть вставлены в эту таблицу или удалены из неё.

{
    id: "heartbeat",
    heartbeat_timeout_secs: 10
}

• id: первичный ключ, heartbeat.
• heartbeat_timeout_secs: время в секундах между потерей соединения сервером с кластером и началом процесса переключения. По умолчанию установлено значение 10 секунд.

Таблицы состояния

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

table_status

В этой таблице хранится информация о доступности таблиц. На каждую таблицу (за исключением системных таблиц) приходится один документ.

{
    id: "31c92680-f70c-4a4b-a49e-b238eb12c023",
    name: "tablename",
    db: "test",
    status: {
        ready_for_outdated_reads: true,
        ready_for_reads: true,
        ready_for_writes: true,
        all_replicas_ready: true
    },
    shards: [
        {
            primary_replicas: ["a"],
            replicas: [{server: "a", state: "ready"}, {server: "b", state: "ready"}]
        },
        {
            primary_replicas: ["b"],
            replicas: [{server: "a", state: "ready"}, {server: "b", state: "ready"}]
        }]
}

• id: UUID таблицы.
• name: имя таблицы.
• db: база данных, в которой находится таблица, имя или UUID, в зависимости от значения identifier_format (см. «ограничения» в обзоре в верхней части этого документа).
• status: подполя в этом поле указывают, готовы ли все фрагменты таблицы принять запрос данного типа: outdated_reads, reads и writes. Поле all_replicas_ready указывает, завершены ли все операции дозагрузки.
• shards: по одной записи для каждого фрагмента в table_config. У каждого объекта фрагмента есть следующие поля:
  • primary_replicas: список из нуля или более серверов, работающих в качестве первичных реплик для фрагмента. Если список содержит более одного сервера, разные части фрагмента обслуживаются различными первичными серверами; это временное состояние.
  • replicas: список всех серверов, работающих в качестве реплик для данного фрагмента. Это может включать серверы, которые больше не настроены как реплики, но по-прежнему хранят данные до тех пор, пока их нельзя безопасно удалить. Поле state может принимать следующие значения:
    • ready: сервер готов обслуживать запросы.
    • transitioning: сервер находится в процессе перехода между состояниями.
    • backfilling: сервер получает данные от другого сервера.
    • disconnected: сервер не подключён к кластеру.
    • waiting_for_primary: сервер ожидает, пока станет доступен его первичный реплика.
    • waiting_for_quorum: первичный сервер ожидает, пока кворум реплик таблицы станет доступным, прежде чем начать принимать записи.

Статус_сервера

Эта таблица возвращает информацию о состоянии и доступности серверов в кластере RethinkDB. Для каждого сервера, подключённого к кластеру, создается один документ. Если сервер теряет подключение к кластеру, он будет удален из таблицы server_status.

Это типичная схема документа для сервера, подключённого к хост-серверу — то есть серверу, к которому подключается клиент при запросе данных в таблицу server_status.

{
    id: "de8b75d1-3184-48f0-b1ef-99a9c04e2be5",
    name: "servername",
    network: {
        hostname: "companion-cube",
        cluster_port: 29015,
        http_admin_port: 8080,
        reql_port: 28015,
        time_connected: <ReQL time object>,
        connected_to: {
            "companion-orb": true,
            "companion-dodecahedron": true
        },
        canonical_addresses: [
            { host: "127.0.0.1", port: 29015 },
            { host: "::1", port: 29015 }
            ]
    },
    process: {
        argv: ["/usr/bin/rethinkdb"],
        cache_size_mb: 100,
        pid: 28580,
        time_started: <ReQL time object>,
        version: "rethinkdb 2.2.5 (CLANG 7.0.2 (clang-700.1.81))"
    }
}

• id: UUID сервера.
• name: имя сервера.
• network: информация о сети, в которой находится сервер:
  • hostname: имя хоста, возвращённое gethostname().
  • *_port: порты RethinkDB на этом сервере (с точки зрения самого сервера).
  • canonical_addresses: список канонических адресов и портов сервера. Они могут отличаться от hostname и cluster_port, в зависимости от вашей конфигурации сети.
  • time_connected: время подключения (или повторного подключения) сервера к кластеру.
  • connected_to: список пар «ключ-значение» серверов, к которым сервер в настоящее время подключен (true) или о которых он знает, но к которым не подключён (false). В большинстве случаев другие серверы будут идентифицироваться по имени, но если сервер, к которому обращаются, не может определить имя сервера в кластере, к которому он не подключен, он будет идентифицирован по UUID.
• process: информация о процессе RethinkDB сервера:
  • argv: аргументы командной строки, с которыми был запущен сервер, в виде массива строк.
  • cache_size_mb: размер кеша в мегабайтах. (Это можно настроить при запуске или отредактировав запись server_status для этого сервера.)
  • pid: идентификатор процесса.
  • time_started: время запуска процесса сервера.
  • version: строка версии сервера RethinkDB.

Таблицы учетных записей пользователей

Подробнее об этих двух таблицах читайте в разделе Разрешения и учетные записи пользователей.

users

Таблица users содержит по одному документу для каждого пользователя в системе, каждый с двумя парами «ключ-значение»: уникальное поле id и поле password. Поле id — это имя учетной записи. Поле password ведет себя по-разному при записи и чтении; вы можете изменить пароль учетной записи, записав значение в это поле (или удалить пароль, записав false), но пароль нельзя прочитать. Вместо этого при чтении password будет true или false, указывая, есть ли у учетной записи пароль или нет.

{
    id: "admin",
    password: true
}

Документы могут быть вставлены в users для создания новых пользователей и удалены для их удаления. Вы не можете изменить значение id существующего документа, только изменить или удалить пароли через update.

разрешения

Документы в таблице разрешений имеют от двух до четырёх пар «ключ-значение».

• id: список от одного до трех элементов, указывающих пользователя и область действия данного разрешения, элементами которого являются имя пользователя, UUID базы данных (для области действия базы данных и таблицы) и UUID таблицы (только для области действия таблицы).
• permissions: объект с одним до четырёх логических ключей, соответствующих допустимым разрешениям (read, write, connect и config).
• database: имя базы данных, к которой относятся эти разрешения, присутствует только для разрешений с областью действия базы данных или таблицы.
• table: имя таблицы, к которой относятся эти разрешения, присутствует только для разрешений с областью действия таблицы.

{
    id: [
            "bob"
        ],
    permissions: {
        read: true,
        write: false,
        config: false
    }
}
{
    database: "field_notes",
    id: [
            "bob",
            "8b2c3f00-f312-4524-847a-25c79e1a22d4"
        ],
    permissions: {
        write: true
    }
}
{
    database: "field_notes",
    table: "calendar",
    id: [
            "bob",
            "8b2c3f00-f312-4524-847a-25c79e1a22d4",
            "9d705e8c-4e49-4648-b4a9-4ad82ebba635"
        ],
    permissions: {
        write: false
    }
}

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

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

Другие таблицы

текущие_проблемы

Эта таблица отображает проблемы, обнаруженные в кластере RethinkDB. Подробнее см. документацию Текущая таблица проблем системы.

jobs

Таблица jobs содержит информацию о задачах, выполняемых в кластере RethinkDB, включая запросы, уплотнение дисков и построение индексов, а также позволяет вам убивать задачи запросов, удаляя их из таблицы. Подробнее см. документацию Системная таблица заданий.

stats

Таблица stats предоставляет статистику о пропускной способности чтения/записи сервера, подключениях клиентов и использовании памяти. Подробнее см. документацию Системная таблица статистики.

logs

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

{
    id: ["2015-01-09T02:11:55.190829899", "5a59c88f-8f66-4703-bf74-bf4cd7205db3"]
    level: "notice",
    message: "Running on Linux 3.13.0-24-generic x86_64",
    server: "companion_cube_3yz",
    timestamp: <ReQL time obj>,
    uptime: 0.389226
}

• id: массив из двух элементов, содержащий метку времени записи в журнал (в UTC) и UUID сервера, генерирующего сообщение.
• level: строка, указывающая уровень серьёзности сообщения журнала. Одно из debug, info, notice, warn, или error.
• message: содержание сообщения журнала.
• server: UUID или имя генерирующего сервера (в зависимости от значения identifier_format).
• timestamp: время публикации сообщения журнала.
• uptime: количество секунд, прошедших с момента запуска сервера к моменту генерации сообщения журнала.

Таблица logs поддерживает changefeed. Только сообщения, записываемые в таблицу журналов, будут генерировать события changefeed.

• Таблица хранит максимум 1000 сообщений на сервер. Changefeed не будет доставлять события для записей журналов, когда они удаляются.
• При подключении или отключении сервера его записи журнала будут добавлены или удалены из таблицы logs. Действие подключения или отключения не будет генерировать события changefeed для этих записей журнала.