Команда ReQL: reconfigure

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

table.reconfigure(shards=<s>, replicas=<r>[, primary_replica_tag=<t>, dry_run=False, nonvoting_replica_tags=None]) → object
database.reconfigure(shards=<s>, replicas=<r>[, primary_replica_tag=<t>, dry_run=False, nonvoting_replica_tags=None]) → object
table.reconfigure(emergency_repair=<option>, dry_run=False) → object

Описание

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

• shards: количество фрагментов, целое число от 1 до 64. Необходимо.
• replicas: либо целое число, либо объект-отображение. Необходимо.
  • Если replicas — целое число, оно определяет количество реплик на фрагмент. Указание количества реплик больше, чем серверов, вернёт ошибку.
  • Если replicas — объект, он определяет пары ключ-значение меток серверов и количество реплик, назначенных этим серверам: {"tag1": 2, "tag2": 4, "tag3": 2, ...}. Для получения дополнительной информации о метках серверов, прочтите Инструменты администрирования.
• primary_replica_tag: первичный сервер, указанный по его метке сервера. Необходимо, если replicas — объект; метка должна быть в объекте. Это не должно быть указано, если replicas — целое число.
• dry_run: если True сгенерированная конфигурация не будет применена к таблице, а только возвращена.
• nonvoting_replica_tags: реплики с этими метками сервера будут добавлены в список nonvoting_replicas результирующей конфигурации. (См. failover для получения подробностей о не голосующих репликах.)
• emergency_repair: используется для режима аварийного восстановления. См. отдельный раздел ниже.

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

• reconfigured: количество переконфигурированных таблиц. Будет 0 если dry_run равно 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)

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

{
  "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}, primary_replica_tag='wooster').run(conn)

{
  "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, когда более половины голосующих реплик для каждого фрагмента таблицы всё ещё доступны (см. документацию Failover для получения дополнительных подробностей). Однако, если половина или более голосующих реплик фрагмента потеряны, автоматический failover не произойдёт, оставив два варианта:

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

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

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

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

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

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

Возвращаемое значение reconfigure в режиме аварийного восстановления такое же, как и раньше. Проверьте поле config_changes для просмотра старых и новых настроек конфигурации таблицы. Как и в обычном режиме, если вы укажете emergency_repair с dry_run: True, таблица фактически не будет переконфигурирована.

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

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

Пример: Выполнение аварийного восстановления таблицы.

r.table('superheroes').reconfigure(emergency_repair='unsafe_rollback').run(conn)