Environment Variables

Azure-Specific Recovery Variables:

Env var Purpose
AZURE_RECOVER_FROM_BUCKET Container name to recover from
AZURE_RECOVER_FROM_ACCOUNTNAME Storage account name
AZURE_RECOVER_FROM_ACCOUNTKEY Storage account access key
AZURE_RECOVER_FROM_ENDPOINT_BASE Blob endpoint URL
AZURE_RECOVER_FROM_OBJECT_KEY_PREFIX Object key prefix in primary bucket
AZURE_RECOVER_FROM_ENCRYPTION_KEY Encryption key matching primary
AZURE_RECOVER_FROM_REPLACE_REGION Region replacement mapping

Common DR Variables:

Env Var Purpose Default
BUCKET_STORAGE_MULTIPLE_ENDPOINTS Required for Azure DR - allows each bucket to keep its own endpoint false
ENABLE_ALERTS Controls alert firing true for active, false for standby

Why BUCKET_STORAGE_MULTIPLE_ENDPOINTS=true is Required

In Azure, each storage account has a unique endpoint URL. Without this setting:

  • LogScale assumes all buckets use the same endpoint

  • The standby cluster overwrites ALL bucket endpoints with its own

  • Result: 403 authentication errors during DR recovery

Environment Variable Naming Convention:

text
{provider.envVarPrefix}_{purpose}_{configKey}

For Azure DR recovery: AZURE + _RECOVER_FROM_ + {configKey}

AZURE_RECOVER_FROM_* Preservation on Promotion

Current behavior: The AZURE_RECOVER_FROM_* environment variables are set only when dr="standby" and are removed when promoting to dr="active" (or dr=""). This follows the Terraform locals logic (local.dr_recovery_envvars is conditional on var.dr == "standby").

Operational implication: Removing these env vars changes the HumioCluster spec and may cause the operator to roll/recreate pods during promotion. Plan for a restart window as part of the promotion process.

Why AZURE_RECOVER_FROM_REPLACE_BUCKET is NOT set: Azure storage accounts have unique endpoints (e.g., primaryacct.blob.core.windows.net), unlike S3/OCI which share regional endpoints. Setting REPLACE_BUCKET would swap container names but keep the secondary's endpoint, causing 403 authentication errors. Instead, the AZURE_RECOVER_FROM_ENDPOINT_BASE and AZURE_RECOVER_FROM_ACCOUNTNAME variables point directly to the primary storage account. During recovery, the bucket entity from the primary snapshot is marked readOnly=true, which prevents LogScale from uploading new segments to it.

Cold Start Requirement for DataSnapshotLoader

The AZURE_RECOVER_FROM_* environment variables are only consulted by DataSnapshotLoader during a cold start - when all LogScale pods are down simultaneously and no peer is available to serve a snapshot via HTTP. During a rolling restart, DataSnapshotLoader preferentially loads snapshots from running peers, bypassing bucket storage entirely.

The load order is:

  1. Local snapshot - from the pod's own storage (fastest)

  2. HTTP peer - fetched from a running LogScale pod in the same cluster

  3. Bucket storage - the cluster's own Azure Blob container

  4. Recovery bucket - the AZURE_RECOVER_FROM_* bucket (only if no snapshot matching the Kafka cluster ID was found in steps 1-3)

Important

Implication for DR recovery and failback: For the recovery bucket to be consulted, all LogScale pods must be stopped and all existing global snapshots for the cluster must be deleted from the cluster's own bucket storage. If any local snapshot with a matching kafkaClusterId exists, DataSnapshotLoader will use it and never check the recovery bucket. See the Operation Guide - Manual Failback Procedure (Phase 3) for the step-by-step process.

Reverse Recovery Environment Variables

Variable Source (from secondary remote state)
AZURE_RECOVER_FROM_BUCKET Secondary storage container name
AZURE_RECOVER_FROM_ACCOUNTNAME Secondary storage account name
AZURE_RECOVER_FROM_ACCOUNTKEY Secondary storage account key
AZURE_RECOVER_FROM_ENDPOINT_BASE Secondary storage blob endpoint
AZURE_RECOVER_FROM_OBJECT_KEY_PREFIX Secondary storage object key prefix
AZURE_RECOVER_FROM_ENCRYPTION_KEY Secondary encryption key
AZURE_RECOVER_FROM_REPLACE_REGION <secondary-region>/<primary-region> (inverted - the snapshot's region references are patched to the primary's region)

Note

BUCKET_STORAGE_MULTIPLE_ENDPOINTS is NOT included in reverse_recovery_envvars because the primary already has it via dr_common_envvars (set when dr="active"). Adding it again would create a duplicate, which the operator rejects.

See the Operation Guide - Manual Failback Procedure (Phase 3, Step 5f) for how these variables are applied during failback.