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

Начиная с версии 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 — это только для чтения таблица, хранящая журнальные сообщения со всех серверов кластера.

Ограничения

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

server_status

Эта таблица возвращает информацию о статусе и доступности серверов в кластере 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.

permissions

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

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

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

current_issues

Эта таблица показывает проблемы, которые были обнаружены в кластере 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 поддерживает changefeeds. Только сообщения, записываемые в таблицу журналов, будут генерировать события changefeed.

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