Команда ReQL: reconfigure

Синтаксис команды

table.reconfigure({shards: <s>, replicas: <r>[, primaryReplicaTag: <t>, dryRun: false, nonvotingReplicaTags: null}]) → object
database.reconfigure({shards: <s>, replicas: <r>[, primaryReplicaTag: <t>, dryRun: false, nonvotingReplicaTags: null}]) → object
table.reconfigure(emergencyRepair: <option>, dryRun: false) → object

Описание

Переконфигурируйте фрагментацию и репликацию таблицы.

• shards: количество фрагментов, целое число от 1 до 64. Требуется.
• replicas: целое число или объект-отображение. Требуется.
  • Если replicas является целым числом, оно указывает количество реплик на фрагмент. Указание количества реплик, превышающего количество серверов, вернёт ошибку.
  • Если replicas является объектом, он указывает пары «ключ-значение» тегов сервера и количества реплик, назначенных этим серверам: {tag1: 2, tag2: 4, tag3: 2, ...}. Для получения дополнительной информации о тегах сервера ознакомьтесь со статьёй Инструменты администрирования.
• primaryReplicaTag: первичный сервер, указанный по его тегу сервера. Требуется, если replicas является объектом; тег должен быть в объекте. Не должно быть указано, если replicas является целым числом.
• dryRun: если true задано, сгенерированная конфигурация не будет применена к таблице, а только возвращена.

• nonvotingReplicaTags: реплики с этими тегами сервера будут добавлены в nonvoting_replicas список результирующей конфигурации. (Подробности о не-голосующих репликах см. в failover.)

• emergencyRepair: используется для режима экстренного ремонта. См. отдельную секцию ниже.

Возвращаемое значение reconfigure — это объект с тремя полями:

• reconfigured: количество переконфигурированных таблиц. Будет 0 если dryRun задано как true.
• config_changes: список новых и старых значений конфигурации таблицы. Каждый элемент списка будет объектом с двумя полями:
  • old_val: значение конфигурации таблицы config до выполнения reconfigure.
  • new_val: значение конфигурации таблицы config после выполнения reconfigure.
• status_changes: список новых и старых значений статуса таблицы. Каждый элемент списка будет объектом с двумя полями:
  • old_val: значение статуса таблицы status до выполнения reconfigure.
  • new_val: значение статуса таблицы status после выполнения reconfigure.

Для config_changes и status_changes, см. команды config и status для объяснения возвращаемых объектов в полях old_val и new_val.

Таблица временно потеряет доступность после вызова reconfigure; используйте команду wait, чтобы подождать, пока таблица снова станет доступной, или status, чтобы проверить, доступна ли таблица для записи.

Примечание: Всякий раз, когда вызывается reconfigure, устойчивость записи устанавливается в hard, а подтверждения записи — в majority; их можно изменить, используя команду config для таблицы.

Если reconfigure вызывается для базы данных, все таблицы в базе данных будут затронуты изменением конфигурации. Возвращаемое значение будет массивом объектов, описанных выше, по одной таблице.

См. Фрагментация и репликация для подробного обсуждения этой темы, включая расширенные темы.

Пример: Переконфигурирование таблицы.

> r.table('superheroes').reconfigure({shards: 2, replicas: 1}).run(conn, callback);

Пример возврата:

{
  "reconfigured": 1,
  "config_changes": [
    {
      "new_val": {
        "id": "31c92680-f70c-4a4b-a49e-b238eb12c023",
        "name": "superheroes",
        "db": "superstuff",
        "primary_key": "id",
        "shards": [
          {
            "primary_replica": "jeeves",
            "replicas": ["jeeves", "alfred"],
            "nonvoting_replicas": []
          },
          {
            "primary_replica": "alfred",
            "replicas": ["jeeves", "alfred"],
            "nonvoting_replicas": []
          }
        ],
        "indexes": [],
        "write_acks": "majority",
        "durability": "hard"
      },
      "old_val": {
        "id": "31c92680-f70c-4a4b-a49e-b238eb12c023",
        "name": "superheroes",
        "db": "superstuff",
        "primary_key": "id",
        "shards": [
            "primary_replica": "alfred",
            "replicas": ["jeeves", "alfred"],
            "nonvoting_replicas": []
        ],
        "indexes": [],
        "write_acks": "majority",
        "durability": "hard"
      }
    }
  ],
  "status_changes": [
    {
      "new_val": (status object),
      "old_val": (status object)
    }
  ]
}

Пример: Переконфигурирование таблицы, указание реплик по тегам серверов.

> r.table('superheroes').reconfigure({shards: 2, replicas: {wooster: 1, wayne: 1}, primaryReplicaTag: 'wooster'}).run(conn, callback);
// Result passed to callback
{
  "reconfigured": 1,
  "config_changes": [
    {
      "new_val": {
        "id": "31c92680-f70c-4a4b-a49e-b238eb12c023",
        "name": "superheroes",
        "db": "superstuff",
        "primary_key": "id",
        "shards": [
          {
            "primary_replica": "jeeves",
            "replicas": ["jeeves", "alfred"],
            "nonvoting_replicas": []
          },
          {
            "primary_replica": "alfred",
            "replicas": ["jeeves", "alfred"],
            "nonvoting_replicas": []
          }
        ],
        "indexes": [],
        "write_acks": "majority",
        "durability": "hard"
      },
      "old_val": {
        "id": "31c92680-f70c-4a4b-a49e-b238eb12c023",
        "name": "superheroes",
        "db": "superstuff",
        "primary_key": "id",
        "shards": [
            "primary_replica": "alfred",
            "replicas": ["jeeves", "alfred"],
            "nonvoting_replicas": []
        ],
        "indexes": [],
        "write_acks": "majority",
        "durability": "hard"
      }
    }
  ],
  "status_changes": [
    {
      "new_val": (status object),
      "old_val": (status object)
    }
  ]
}

Режим экстренного ремонта

RethinkDB поддерживает автоматический сбой, когда более половины голосующих реплик каждого фрагмента таблицы по-прежнему доступны (см. документацию Failover для получения дополнительных сведений). Однако, если половина или более голосующих реплик фрагмента потеряны, автоматический сбой не произойдёт, оставив два варианта:

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

Аргумент emergencyRepair фактически представляет собой другую команду; при его указании разрешены только другие аргументы reconfigure, кроме dryRun. При выполнении каждая фрагментация таблицы анализируется и классифицируется в одну из трёх категорий:

• Здоровая: более половины голосующих реплик фрагмента по-прежнему доступны.
• Подлежащая ремонту: фрагмент не является здоровым, но имеет по крайней мере одну доступную реплику, голосующую или не голосующую.
• Не поддающаяся ремонту: у фрагмента нет доступных реплик.

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

Укажите emergencyRepair с одним из двух строковых вариантов:

• unsafe_rollback: фрагменты, которые не поддаются ремонту, оставятся без изменений.
• unsafe_rollback_or_erase: фрагмент, который не поддаётся ремонту, будет уничтожен и пересоздан на доступном сервере, на котором находится другой фрагмент этой таблицы.

Возвращаемое значение reconfigure в режиме экстренного ремонта такое же, как и раньше. Проверьте поле config_changes, чтобы увидеть старые и новые параметры конфигурации таблицы. Как и в обычном режиме, если вы укажете emergencyRepair с dryRun: true, таблица фактически не будет переконфигурирована.

Примечание: emergencyRepair может быть использован только для отдельных таблиц, а не для баз данных. Он не может быть использован после команды db.

Режим экстренного ремонта чрезвычайно опасен. Он обходит обычные меры предосторожности, которые предотвращают потерю данных и делают недействительными гарантии согласованности, которые обычно предоставляет RethinkDB, и может легко потерять данные в любом режиме — в режиме unsafe_rollback_or_erase он может потерять все данные фрагмента.

Пример: Выполнение экстренного ремонта таблицы.

r.table('superheroes').reconfigure(
  {emergencyRepair: "unsafe_rollback"}
).run(conn, callback);