Журналы действий для операций эластичных (разделение/слияние)

  • Применяется к: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

В этой статье объясняется, как использовать журнал действий Azure для отслеживания операций разделения секций и слияния в Azure Cosmos DB.

Основные сведения

В Azure Cosmos DB каждая физическая партиция поддерживает до 10 000 RU/s пропускной способности. При увеличении подготовленной пропускной способности базы данных или контейнера за пределами емкости текущих физических секций Azure Cosmos DB необходимо разделить эти секции, чтобы обеспечить дополнительную пропускную способность.

Разделение секции разделяет существующую физическую секцию на новые секции. Каждая новая секция принимает часть исходных данных. Этот процесс позволяет контейнеру обслуживать более высокую общую пропускную способность, так как каждая новая секция может обслуживать до 10 000 ЕЗ/с емкости. Azure Cosmos DB также может объединять секции для оптимизации макета для оптимальной производительности и распределения данных.

В зависимости от размера данных и запроса пропускной способности разделение и объединение секций может занять несколько часов. В журнале действий на портале Azure отображается состояние этих эластичных операций— увеличение пропускной способности (разделение секций) и уменьшение (слияние секций).

Дополнительные сведения о том, как секционирование разделяет работу и рекомендации по масштабированию, см. в рекомендациях по масштабированию подготовленной пропускной способности.

Мониторинг эластичных операций в журнале действий

И разделение, и объединение разделов следуют одному и тому же шаблону в журнале действий. Чтобы отслеживать ход выполнения эластичной операции, выполните следующие действия.

  1. Перейдите на учетную запись Azure Cosmos DB в портал Azure.
  2. В меню слева выберите "Журнал действий".
  3. Фильтруйте по имени ресурса базы данных или контейнера.
  4. Найдите записи журнала, связанные с эластичной операцией. Каждая запись включает имя операции, состояние и метку времени.
  5. Разверните запись журнала, чтобы увидеть связанные операции масштабирования, вложенные под основной записью. Основная запись отражает последнее общее состояние операции масштабирования. Каждая вложенная операция также имеет собственное состояние.
  6. Выберите отдельный журнал, чтобы открыть область сведений справа. На вкладке JSON раздел "Свойства" содержит подробные сведения об операции.

Каждая операция выполняется через три состояния. Конкретные сведения в каждом состоянии отличаются между разделением и слиянием, как описано в следующих разделах.

Статус Description
Запуск Эмитируется в начале операции, после того как Azure Cosmos DB определяет, какие разделы будут разделены или объединены.
В процессе Выдается каждые 30 минут в течение всей операции, предоставляя обновленные сведения по мере выполнения работы. Вы можете не увидеть этот статус, если операция завершится в течение 30 минут.
Succeeded Выдается один раз, в самом конце по завершении операции.

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

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

Увеличение пропускной способности и разделения секций

Пример. Предположим, что у вас есть контейнер с 1 физической секцией, обрабатывающий 5000 ЕЗ/с. Затем вы увеличиваете пропускную способность до 15 000 RU/с. Существующая секция может поддерживать только до 10 000 ЕЗ/с — недостаточно для запрошенного 15 000 ЕЗ/с. Azure Cosmos DB разделяет его, чтобы создать дополнительные секции, которые могут распределять более высокую пропускную способность.

Журнал основных действий

После запуска операции разделения пропускной способности вы увидите основную запись:

"Операция разделения пропускной способности — масштабирование до пропускной способности 15 000"

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

Скриншот основной записи журнала активности для операции разделения пропускной способности.

Вложенные журналы действий

Начатый статус — запись журнала действий показывает новую целевую пропускную способность и разделы, которые будут разделены для достижения этой цели. Это подтверждает, что выполняется операция масштабирования. В этом примере новая пропускная способность составляет 15 000 ЕЗ/с, а партиция "0" будет разделена.

Снимок экрана: запись состояния

Состояние выполнения — генерируется примерно каждые 30 минут. Этот статус предоставляет подробную разбивку каждого раздела, участвующего в разделении. Каждый раздел представлен как одна операция в трассировке, что позволяет отслеживать прогресс на детализированном уровне.

Ниже приведены значения для примера и описания каждого свойства.

Недвижимость Пример контрольной точки 1 Пример контрольной точки 2 Description
Всего необходимых операций 1 1 Общее количество секций, которые необходимо разделить для обслуживания запрошенной пропускной способности.
Операции в процессе 1 0 Секции, которые активно разделяются.
Операции, ожидающие планирования 0 0 Разделы готовы к разделению, но временно заблокированы другой операцией в том же разделе. Они будут происходить автоматически.
Завершенные операции 0 1 Секции, которые завершили разделение и теперь обслуживают трафик на новой пропускной способности.
Неудачные операции 0 0 Разделы, в которых произошла ошибка. Они автоматически перезаверяются в новом идентификаторе операции и будут отображаться как отдельная операция.

На рисунке ниже показано, как эти свойства отображаются на вкладке JSON записи журнала действий на портале Azure.

Снимок экрана: свойства IN Progress JSON для секции, разделенной на вкладке JSON журнала действий.

Успешное состояние – разделение завершено, все новые разделы доступны онлайн, и доступна полная выделенная пропускная способность.

Снимок экрана: запись состояния

JSON состояния журнала действий

Следующие свойства JSON создаются на каждом этапе операции разделения секции. Контрольная точка 1 и контрольная точка 2 иллюстрируют, как статус "В процессе" обновляется со временем по мере завершения работы разделов.

Статус Свойства JSON (контрольная точка 1) Свойства JSON (контрольная точка 2)
Запуск {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database1",
  "collectionName": "container1",
  "targetThroughput": "15000",
  "status": "Will split partitions 0 into different partitions"
}
В процессе {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database1",
  "collectionName": "container1",
  "targetThroughput": "15000",
  "Total Operations Required": "1",
  "In Progress Operations": "1",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "0",
  "Failed Operations": "0"
}		 {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database1",
  "collectionName": "container1",
  "targetThroughput": "15000",
  "Total Operations Required": "1",
  "In Progress Operations": "0",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "1",
  "Failed Operations": "0"
}
Succeeded {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database1",
  "collectionName": "container1",
  "targetThroughput": "15000",
  "status": "Completed splits operation"
}

Несколько раундов деления

При увеличении пропускной способности процесс разделения происходит в нескольких раундах. Каждый раунд разбивает разделы, созданные предыдущим раундом, до тех пор, пока их не будет достаточно, чтобы обслуживать требуемую пропускную способность. Каждый раунд имеет собственные записи журнала "Начато" и "В процессе". Когда все раунды завершены, в главной записи журнала отображается одно состояние "Успешно".

В течение каждого раунда журнал действий фиксирует периодические контрольные точки примерно каждые 30 минут. Каждая контрольная точка отображается как запись "Выполняется" с обновленным моментальным снимком состояния операции. В зависимости от того, сколько времени занимает раунд, может отображаться несколько записей "В процессе". Если раунд заканчивается быстро (например, 30 минут или меньше), статус "Начато" может отображаться без отчетов о ходе выполнения.

Пример. Предположим, что у вас есть контейнер с 1000 ЕЗ/с и 1 физической секцией, а пропускная способность увеличивается до 30 000 ЕЗ/с.

Раунд 1 — раздел 0 разбивается на секцию 1 и секцию 2.

Раунд 2— раздел 1 разбивается на секцию 3 и секцию 4.

В конце концов у вас есть 3 секции (секции 2, 3 и 4), обслуживающие 30 000 ЕЗ/с. После завершения раунда 2 в основной записи журнала отображается как успешный.

Main log status: Started

┌───────  Round 1: Split  ───────┐

  Partition 0
  1,000 RU/s

  ▼                              ▼

  Partition 1        Partition 2
                     ✓ final partition

┌───────  Round 2: Split  ───────┐

  Partition 1

  ▼                              ▼

  Partition 3        Partition 4
  ✓ final partition  ✓ final partition

───────  Final Partitions  ───────

  Partition 2    Partition 3    Partition 4
  from Round 1   from Round 2   from Round 2

✔ RESULT: 3 partitions serving 30,000 RU/s

Main log status: Succeeded

В журнале действий отображаются записи на портале, сложенные сверху вниз, с последним наверху. Каждый раунд начинается с собственной записи о начале. Все записи "Ход выполнения" между одним состоянием "Начато" и следующим относятся к одному раунду.

Снимок экрана журнала действий, показывающего несколько этапов разделения разделов с записями «Начато» и «В процессе» для каждого этапа.

В этом примере первый раунд разделения окружен синим полем и отображает статус "Начато", а затем следуют две записи со статусом "В процессе". Раунд 2 следует аналогичной схеме и выделен фиолетовой рамкой.

Снимок экрана вида портала журнала активности, показывающий раздельные записи Раунда 1 и Раунда 2, выделенные в отдельных полях.

JSON состояния журнала действий

Следующее содержимое JSON извлекается непосредственно из записей журнала действий. Для ясности общие поля JSON опущены, и остается только состояние.

Раунд 1. Разделение

Статус Свойства JSON (контрольная точка 1) Свойства JSON (контрольная точка 2)
Запуск {
  "status": "Will split partitions 0 into different partitions"
}
В процессе {
  "Total Operations Required": "1",
  "In Progress Operations": "1",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "0",
  "Failed Operations": "0"
}		 {
  "Total Operations Required": "1",
  "In Progress Operations": "0",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "1",
  "Failed Operations": "0"
}

Раздел 0 завершил разделение, как показано при переходе от операции "Выполняется" к завершенной операции. Теперь мы перейдем к разделению Раздела 2.

Раунд 2. Сплит

Статус Свойства JSON (контрольная точка 1) Свойства JSON (контрольная точка 2)
Запуск {
  "status": "Will split partitions 2 into different partitions"
}
В процессе {
  "Total Operations Required": "1",
  "In Progress Operations": "1",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "0",
  "Failed Operations": "0"
}		 {
  "Total Operations Required": "1",
  "In Progress Operations": "0",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "1",
  "Failed Operations": "0"
}
Succeeded {
  "status": "Completed splits operation"
}

Слияние разделов

При значительном уменьшении подготовленной пропускной способности базы данных или контейнера существующее количество физических секций больше не требуется. Вы можете запустить слияние секций, чтобы уменьшить количество физических секций и оптимизировать использование единиц запросов (RU/s) и распределение данных. Объединение снижает затраты на обслуживание неиспользуемых секций и позволяет системе работать более эффективно при сниженной пропускной способности.

Операция слияния объединяет несколько существующих секций в одну новую секцию. Например, если секции 2, 3 и 4 объединены, результатом является один новый раздел 5. Каждая новая секция, созданная слиянием, представлена как одна операция в журнале действий. Слияние следует тому же шаблону обновлений состояния, что и разделение пропускной способности.

Пример. Предположим, что вы масштабировали контейнер до 100 000 ЕЗ/с для миграции больших данных, что потребовало 10 физических секций. Хотя 10 физических секций могут содержать 500 ГБ данных, было принято только 50 ГБ данных, и требуется только 10,000 RU/s.

После уменьшения зарезервированной пропускной способности до 10 000 RU/с можно объединить 10 секций в 1 секцию и оптимизировать использование RU/с.

Журнал основных действий

После запуска операции слияния секций вы увидите основную запись:

"Операция слияния PartitionCoalescer для контейнера"

Эта запись служит родительской для всех операций, связанных со слиянием. Эта запись используется на протяжении всей операции для отслеживания ее хода выполнения. Могут быть другие журналы, связанные с слиянием, например "Слияние физических разделов контейнера SQL", но они не содержат сведения о состоянии.

В следующем примере показаны несколько журналов, связанных с слиянием, под основной записью. Значима только операция слияния PartitionCoalescer для элемента Container.

Снимок экрана основной записи журнала активности для операции слияния разделов, показывающий вложенные связанные слиянием журналы.

Вложенные журналы действий

Состояние начала. Запись журнала действий показывает контейнер, участвующий в слиянии, и разделы, которые будут объединены. Контейнер отражает, использует ли она подготовленную или общую пропускную способность. Для этого типа операции нет целевой пропускной способности, так как вы не масштабируетесь. В этом примере все 10 секций объединяются в 1 секцию.

Снимок экрана записи статуса

Выполняется — генерируется примерно каждые 30 минут. Это состояние обеспечивает подробную разбивку каждой операции слияния. Каждое слияние представлено как одна операция в трассировке, поэтому можно отслеживать ход выполнения на детализированном уровне.

Ниже приведены значения для примера и описания каждого свойства.

Недвижимость Пример контрольной точки 1 Пример контрольной точки 2 Description
Всего необходимых операций 1 1 Общее количество слияний разделов, необходимых для достижения целевого количества разделов.
Операции в процессе 1 0 Слияния, которые активно выполняются.
Операции, ожидающие планирования 0 0 Слияние готово к выполнению, но временно блокируется из-за другой операции на том же разделе.
Завершенные операции 0 1 Завершённые слияния.
Неудачные операции 0 0 Слияния, в которых произошла ошибка. Они автоматически пересылаются под новым идентификатором операции.

На рисунке ниже показано, как эти свойства отображаются на вкладке JSON записи журнала действий на портале Azure.

Снимок экрана: свойства IN Progress JSON для слияния секций на вкладке JSON журнала действий.

Выполнено успешно . Слияние завершено, и остальные секции обслуживают трафик.

Снимок экрана: запись состояния

JSON состояния журнала действий

Следующие свойства JSON выводятся на каждом этапе операции слияния. Контрольная точка 1 и контрольная точка 2 иллюстрируют, как статус "В процессе" обновляется со временем по мере завершения работы разделов.

Статус Свойства JSON (контрольная точка 1) Свойства JSON (контрольная точка 2)
Запуск {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database3",
  "collectionName": "container3",
  "status": "Collection <id> will merge partitions 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 into a new partition"
}
В процессе {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database3",
  "collectionName": "container3",
  "Total Operations Required": "1",
  "In Progress Operations": "1",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "0",
  "Failed Operations": "0"
}		 {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database3",
  "collectionName": "container3",
  "Total Operations Required": "1",
  "In Progress Operations": "0",
  "WaitingToBeScheduled Operations": "0",
  "Completed Operations": "1",
  "Failed Operations": "0"
}
Succeeded {
  "isSharedThroughput": "False",
  "resourceRid": "<id>",
  "databaseName": "database3",
  "collectionName": "container3",
  "status": "Completed merge operation."
}
  • Last updated on