Active geo-replication is an Azure SQL Database business-continuity feature that continuously replicates one primary database to a readable secondary database, often in another Azure region. It supports manual or programmatic geo-failover for individual databases and can also serve read-only workloads from the secondary.
Azure SQL active geo-replication, geo-secondary, geo-replica
Difficulty
advanced
CLI mappings
5
Last verified
2026-05-08
Microsoft Learn
Active geo-replication is an Azure SQL Database business-continuity feature that continuously replicates one primary database to a readable secondary database, often in another Azure region. It supports manual or programmatic geo-failover for individual databases and can also serve read-only workloads from the secondary.
In Azure architecture, this term sits in the database reliability and operations layer. It connects application behavior, connection strings, private networking, Azure Monitor metrics, database tier limits, failover planning, readable secondaries, and operational runbooks. The control plane exposes database resources, replica links, alert rules, and monitoring configuration. The data plane shows how clients connect, query, replicate, and recover. A safe design always ties the term to the application pattern, because database metrics and replication settings only matter when interpreted against workload behavior and business recovery objectives. For Active geo-replication, the important fields are primary database, secondary database, partner server, region, replication link, replication lag, failover command path, and security configuration on the secondary. Replication is asynchronous, and the geo-secondary is readable.
Why it matters
This matters because database problems usually surface as business outages before teams agree on the root cause. High sessions may come from connection leaks rather than compute shortage, and a replica may satisfy disaster recovery only if security, lag, failover steps, and application routing are already tested. The practical habit is to collect objective evidence, compare it with application design, and decide whether the next action is tuning, scaling, failover, rollback, or access correction. For Active geo-replication, the most useful evidence is not the product label; it is the concrete output that shows current state, ownership, scope, and the next safe action.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
Azure SQL Database replicas
Signal 02
disaster recovery architecture
Signal 03
read-only secondary routing
Signal 04
failover runbooks
Signal 05
az sql db replica commands
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Create a readable secondary database in another region.
Fail over one critical database during a regional outage.
Offload selected read-only workloads to a geo-secondary.
Target disaster recovery only where database-level criticality justifies cost.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Active geo-replication in action
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Mariner Payments needed database-level disaster recovery for a card settlement system hosted in Azure SQL Database, but failover groups were not a fit for every database.
🎯Business/Technical Objectives
Replicate one critical database to a secondary Azure region.
Keep a readable secondary for reporting and failover validation.
Meet an application recovery target under 30 minutes.
Document manual geo-failover steps and security prerequisites.
✅Solution Using Active geo-replication
replication
The architecture team configured active geo-replication for the settlement database, creating a readable geo-secondary on a logical server in a paired region. The application normally wrote to the primary database, while reporting queries used the readable secondary when appropriate. Operations rehearsed `az sql db replica list-links` and planned failover using the documented procedure, including connection string changes because active geo-replication is configured per database and does not provide the stable listener abstraction that failover groups provide. Security prepared logins and contained users on the secondary server so access would work after promotion. Replication lag was monitored during settlement windows.
📈Results & Business Impact
Failover rehearsal completed in 18 minutes, beating the 30-minute target.
Reporting workload moved 22% of read traffic away from the primary database.
Security validation caught two missing secondary-server logins before production rollout.
Disaster recovery evidence satisfied the payment operations review board.
💡Key Takeaway for Glossary Readers
Active geo-replication is valuable when one Azure SQL database needs regional continuity and readable secondary capability.
Case study 02
Active geo-replication in action
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Evergreen Retail had a global loyalty database that needed resilience during regional outages, but the team also wanted read-only access close to analytics users.
🎯Business/Technical Objectives
Create a continuously synchronized secondary database in another region.
Allow read-only analytics without affecting primary checkout writes.
Measure replication lag before relying on the secondary for reporting.
Practice manual failover before holiday traffic.
✅Solution Using Active geo-replication
replication
The database team enabled active geo-replication from the primary loyalty database to a secondary region near analytics users. Read-only reporting jobs connected to the geo-secondary, while checkout and points updates continued on the primary. Azure Monitor tracked replication lag, CPU, sessions, and failed connections on both databases. The team ran quarterly failover drills using Azure CLI and documented the manual steps to promote the secondary, update application configuration, and verify security access. Because active geo-replication is asynchronous, the business agreed to an RPO target and tested whether reports tolerated slight lag during peak sales periods.
📈Results & Business Impact
Analytics read latency improved 38% for users near the secondary region.
Primary database CPU during reporting windows dropped from 71% to 49%.
Failover drills reduced recovery steps from 27 manual tasks to 12 runbook tasks.
Replication lag stayed under the agreed threshold in 97% of monitored intervals.
💡Key Takeaway for Glossary Readers
Active geo-replication can support both disaster recovery and read-scale when lag and failover operations are understood.
Case study 03
Active geo-replication in action
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
MetroMed Supply Chain planned a regional resilience upgrade for a single high-value ordering database without changing every database on the logical server.
🎯Business/Technical Objectives
Apply disaster recovery only to the ordering database.
Avoid unnecessary replica cost for low-criticality databases.
Validate user access on the secondary before go-live.
Create evidence for RTO and RPO sign-off.
✅Solution Using Active geo-replication
replication
The architects chose active geo-replication because it is configured per database. They created a geo-secondary for the ordering database on a logical server in another region and left lower-priority databases without replicas. The DBA team prepared contained users and verified that application identities could connect to the readable secondary. Monitoring tracked replication lag and basic health metrics, while a failover exercise promoted the secondary in a test window and then re-established replication. The runbook clearly stated when active geo-replication was sufficient and when a failover group would be better, especially for applications needing stable listener endpoints across multiple databases.
📈Results & Business Impact
DR spend was 44% lower than replicating every database on the server.
Access validation found one missing user mapping before the first failover test.
The ordering database met its 25-minute recovery drill objective.
Architecture review approved the per-database replication model for targeted criticality.
💡Key Takeaway for Glossary Readers
Active geo-replication lets teams focus regional resilience where the database-level business impact justifies it.
Why use Azure CLI for this?
Azure CLI is useful for Active geo-replication because it turns portal-visible configuration into repeatable evidence. Operators can list the target, inspect IDs and state, confirm whether the command is read-only or mutating, and save sanitized output for release or incident records. For this term, CLI work should start with context checks such as tenant, subscription, resource group, registry, database, role scope, or resource ID. Use JSON output when tags, digests, receiver lists, token permissions, assignment scopes, metrics, or replica links matter. Treat commands that delete manifests, disable tokens, update scope maps, create alerts, or fail over databases as approval-required changes, not casual inspection.
CLI use cases
Inventory the current Active geo-replication configuration before a release, access change, cleanup, alert update, or database operation so the operator can prove the target is correct.
Troubleshoot production behavior by comparing live Azure output for Active geo-replication with the expected architecture, owner, scope, tag, permission, metric, or replica state.
Automate a repeatable verification check around Active geo-replication in a pipeline or runbook so drift is caught before users, workloads, or auditors discover it.
Create sanitized post-change evidence for Active geo-replication, keeping IDs, state, timestamps, digests, run IDs, metrics, or links while redacting secrets and sensitive endpoints.
Before you run CLI
Confirm the active tenant and subscription with `az account show`; many Active geo-replication mistakes are wrong-context mistakes that look like product failures.
Identify the exact resource boundary before running commands: registry, repository, scope map, token, task, webhook, action group, role scope, database, or replica link.
Classify the command as read-only, security-impacting, cost-impacting, destructive, or availability-impacting; approval is required before mutating Active geo-replication in production.
Decide how sensitive output will be handled before the command runs, especially token passwords, webhook URIs, object IDs, connection details, and registry metadata.
What output tells you
The output confirms whether Azure returned the intended Active geo-replication target by name, resource ID, subscription, region, repository, database, role scope, or alert group.
State fields show what Azure will actually use: tags, digests, retention status, repository actions, token status, task triggers, receivers, session metrics, or replica links.
Nested JSON often contains the important evidence; table output can hide permissions, timestamps, action lists, credential status, endpoint scope, or metric dimensions.
The output also tells you whether the next action should be inspection, approval, rollback, scale, cleanup, failover, credential rotation, or a safer design review.
Mapped Azure CLI commands
Active geo-replication commands
direct
az sql db replica create --resource-group <rg> --server <primary-server> --name <db> --partner-server <secondary-server> --secondary-type Geo
az sql db replicaprovisionDatabases
az sql db replica list-links --resource-group <rg> --server <server> --name <db>
az sql db replicadiscoverDatabases
az sql db replica set-primary --resource-group <rg> --server <secondary-server> --name <db>
az sql db replicaoperateDatabases
az sql db replica delete-link --resource-group <rg> --server <server> --name <db> --partner-server <partner-server>
az sql db replicaremoveDatabases
az monitor metrics list --resource <database-resource-id> --metric replication_lag_seconds --interval PT1M
az monitor metricsdiscoverDatabases
Architecture context
Use active geo-replication when an individual Azure SQL database needs regional redundancy or read-scale. Use failover groups when multiple databases or stable listener endpoints are required. Test failover, user access, monitoring, and application routing before treating the replica as a recovery plan.
Security
Security depends on database identity, network, and access configuration matching the operational pattern. Connection metrics can expose application behavior, while geo-replication requires users, logins, firewall rules, private access, and permissions to work on the secondary after failover. For Active geo-replication, verify who can connect, what endpoint they use, whether secrets are protected, and whether diagnostic evidence can be shared without leaking connection strings or sensitive workload details.
Cost
Cost can be direct or indirect. High active connections can lead teams to scale a database when the actual fix is connection-pool tuning, while geo-replication adds secondary database cost that must be justified by RTO, RPO, read-scale, and business impact. For Active geo-replication, cost review should compare tuning, scaling, alerting, and replication against the measurable business risk of outage or performance failure.
Reliability
Reliability depends on recognizing whether the term represents pressure, redundancy, or recovery capability. High active sessions can precede failed logins, while a geo-secondary only helps if replication, security, monitoring, and application routing are tested. For Active geo-replication, operators should define thresholds, failover criteria, rollback steps, and evidence such as session trends, replication links, lag, health metrics, and successful access checks.
Performance
Performance depends on workload interpretation. Active sessions, failed connections, workers, CPU, and query behavior must be read together before deciding to scale or roll back. Geo-replication can offload read-only work, but asynchronous replication means lag and routing matter. For Active geo-replication, performance review should include application pool settings, latency targets, replica lag, read workload placement, and whether alert thresholds represent sustained pressure rather than harmless bursts.
Operations
Operational excellence means database behavior is observed with repeatable commands and dashboards rather than guesses. Use Azure Monitor metrics, SQL resource commands, replica commands, and alert rules to capture state before and after changes. For Active geo-replication, the runbook should name the database, server, resource ID, metric or replica field, expected healthy value, owner, escalation path, and exact output to save for incident review.
Common mistakes
Treating Active geo-replication as a label instead of a boundary with owner, scope, evidence, and rollback consequences.
Running mutating commands from the wrong subscription, resource group, registry, role scope, database, or region because the Azure CLI context was not checked first.
Saving raw secrets, token passwords, webhook URLs, or sensitive identity details in tickets instead of sanitized operational evidence.
Assuming a successful command proves the design is correct; it only proves Azure accepted the request or returned the current state.