az sql db replica list-links --resource-group <resource-group> --server <primary-server> --name <database>
Databases
Data platform
SQL geo-replica
Microsoft Learn describes active geo-replication as a capability for creating readable secondary databases for Azure SQL Database in the same or different regions. A SQL geo-replica is that secondary database, kept synchronized asynchronously and available for disaster recovery, migration, or read-only workloads.
Source: Microsoft Learn - Active geo-replication for Azure SQL Database Reviewed 2026-05-25
- Exam trap
- Creating a geo-replica for disaster recovery but leaving secondary server networking, identities, or private DNS untested.
- Production check
- Run az sql db replica list-links and confirm the expected partner server, database, role, and state.
Article details and learning context
- Aliases
- Azure SQL geo-replica, geo-secondary, active geo-replication secondary, readable secondary database
- Difficulty
- intermediate
- CLI mappings
- 4
- Last verified
- 2026-05-25
- Review level
- template-specs-five-use-cases
- Article depth
- template-specs-five-use-cases-three-case-studies
Related context
No curated learning path mapped yet; use the category trail.
Understand the concept
In plain English
A SQL geo-replica is a secondary copy of an Azure SQL database that lives on another logical server, often in another region. The primary database accepts writes, while the geo-replica stays updated through replication and can serve read-only workloads or become primary during a planned or emergency failover. It gives teams a way to prepare for regional recovery or low-downtime migration. It is not the same as a normal backup because it is an online database with its own server, networking, security, and cost.
Why it matters
SQL geo-replica matters because recovery and migration plans need a live target, not just a hope that backups will restore quickly. A geo-replica can reduce downtime during region failure, server migration, subscription movement, or application upgrade rehearsals. It also creates a place to run read-only workloads when the business can tolerate replication lag. The tradeoff is responsibility: the secondary server must be secured, monitored, costed, and tested like production. If teams create a replica but never validate failover, connection routing, user access, or data freshness, they may pay for resilience they cannot actually use. Test recovery evidence before leadership accepts readiness. under pressure.
Technical context
In Azure architecture, a SQL geo-replica is created through active geo-replication for Azure SQL Database. It has its own database resource, server context, service tier, network boundary, identity configuration, and monitoring signals. Replication is asynchronous, so operators must understand lag, failover behavior, and application tolerance for possible data loss. Geo-replicas interact with failover groups, private endpoints, firewall rules, connection strings, read-scale patterns, migration plans, and regional landing-zone policies. CLI and portal workflows manage replica creation, link inspection, role changes, and link removal.
Exam context
Compare with
Where it is used
Where you see it
- In the Azure portal, the Replicas or Geo-replication view shows primary database, secondary database, region, replication link, replica status, and available failover actions for readiness review.
- In Azure CLI output, az sql db replica list-links shows partner server, partner database, replication role, link state, and identifiers used for recovery drills and promotion evidence.
- In monitoring dashboards, teams track replication health, failover events, connection failures, read-only workload behavior, alert thresholds, and owners for the secondary database endpoint during tabletop reviews.
Common situations
- Prepare a live secondary Azure SQL database in another region so a critical application has a tested regional recovery target.
- Migrate a database between logical servers or regions with less downtime than a full export and import cycle.
- Offload read-only reporting or validation queries to a secondary database when the business can tolerate replication lag.
- Create a temporary failback copy during a risky application upgrade so the team can recover if the primary change fails.
- Validate disaster-recovery readiness by promoting a replica in a test window and measuring application reconnect behavior.
Illustrative Azure scenarios
These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.
Scenario 01 SaaS vendor migrates tenants with minimal downtime Scenario, objectives, solution, measured impact, and takeaway.
Scenario
A SaaS vendor needed to move several high-value tenant databases from an aging region to a newer Azure region. Export and import testing showed downtime would exceed the maintenance window.
Goals
- Move tenant databases with less than 30 minutes of visible downtime.
- Maintain a rollback path until post-migration validation completed.
- Avoid changing application code for every tenant migration wave.
- Collect evidence of replication health before cutover.
Approach using SQL geo-replica
The database team created SQL geo-replicas for selected tenant databases on a partner logical server in the target region. Azure CLI scripts created each replica, listed replication links, and blocked cutover until the expected partner server and role appeared. During the maintenance window, applications were paused, final smoke tests ran against the secondary, and the replica was promoted. Connection routing was updated through tenant configuration rather than code changes. The old primary stayed available as a rollback reference until billing, login, and transaction checks passed.
Potential outcomes
- Average tenant downtime fell from a projected 95 minutes to 18 minutes across the first migration wave.
- No tenant data reconciliation errors were found after promotion and application smoke testing.
- Migration evidence packages were created automatically from CLI link output and validation queries.
- The team removed six retired replicas after the rollback window, avoiding unnecessary monthly database spend.
What to learn
A SQL geo-replica can turn a risky database move into a controlled promotion when replication health is measured before cutover.
Scenario 02 Insurance analytics team offloads read-heavy actuarial queries Scenario, objectives, solution, measured impact, and takeaway.
Scenario
An insurance analytics group ran complex actuarial extracts against the same Azure SQL database used by policy-service applications. During reporting periods, primary CPU spikes increased policy quote latency.
Goals
- Move lag-tolerant actuarial reads away from the primary database.
- Keep the secondary database available as a disaster-recovery option.
- Define freshness rules for reports that did not require current writes.
- Reduce production quote latency during monthly analysis windows.
Approach using SQL geo-replica
Architects created a SQL geo-replica on a secondary logical server and routed actuarial reporting jobs to the secondary endpoint. Reports were labeled with an allowed freshness window, and jobs that required current writes stayed on the primary. Operators monitored replica health, query duration, and primary CPU before and after the change. The secondary server received matching auditing, private endpoint access, and database roles for the analytics identity. A quarterly exercise promoted the replica in a test subscription to confirm recovery assumptions remained valid.
Potential outcomes
- Primary CPU peaks during reporting fell from 91 percent to 63 percent after lag-tolerant extracts moved to the replica.
- Quote API p95 latency improved by 28 percent during monthly actuarial processing.
- Reports with stale-data sensitivity were reduced from 34 to 9 after the freshness classification exercise.
- Security review passed because the secondary used dedicated analytics roles and private endpoint access.
What to learn
Geo-replicas are useful for read offload only when teams explicitly classify which reports can tolerate replication lag.
Scenario 03 Manufacturing firm protects plant scheduling during regional risk Scenario, objectives, solution, measured impact, and takeaway.
Scenario
A manufacturing firm relied on an Azure SQL scheduling database to coordinate plant shifts and supplier deliveries. A regional outage exercise showed backups alone could not meet the plant's recovery target.
Goals
- Prepare an online secondary database for regional disaster recovery.
- Verify plant applications could connect from the alternate network path.
- Measure promotion time and expected data freshness during drills.
- Avoid over-sizing the secondary without performance evidence.
Approach using SQL geo-replica
The infrastructure team configured a SQL geo-replica in a secondary region and matched the secondary server's private endpoint, firewall rules, and auditing with the primary environment. Azure CLI listed replica links every morning and sent alerts when the expected relationship was missing. A quarterly drill promoted the replica in a controlled window, ran shift-schedule write tests, and measured query performance under simulated plant load. After each drill, the team reviewed whether the replica service tier still matched the required recovery workload.
Potential outcomes
- The plant met a 40-minute recovery target in three consecutive drills, down from an unproven four-hour restore plan.
- One private DNS mismatch was found during the first drill and fixed before a real weather-related regional alert.
- Replica service tier was reduced after load testing, saving 18 percent without missing performance targets.
- Operations gained a daily control that confirmed the geo-replication link existed before plant leadership reviewed readiness.
What to learn
A SQL geo-replica provides real continuity value only when the secondary environment is tested like the primary.
Azure CLI
With ten years as an Azure engineer, I use Azure CLI for geo-replicas because replica work crosses servers, regions, and change windows. CLI lets me create the replica with exact partner server and service objective values, list replication links, verify roles, and script failover tests. It also helps compare replicas across many databases without opening every portal blade. During migration rehearsals, CLI output becomes evidence of when the replica was created, when it was promoted, and which link was removed. That repeatability matters because a geo-replication mistake can affect both data recovery and application connection planning. Capture outputs for audits. That repeatability matters when promotion approvals happen under pressure.
Useful for
- Create a geo-replica on a partner server with the intended service objective and region during a recovery buildout.
- List replication links for a database and confirm which server currently owns the primary and secondary roles.
- Promote a replica during a planned migration rehearsal and record the command output as change evidence.
- Delete a replication link only after confirming the migration or failover rollback window has closed.
- Inventory all geo-replicas in a subscription to find costly secondaries that no longer support recovery or reporting.
Before you run a command
- Confirm the primary server, partner server, resource groups, subscription, region, database name, and service objective before creating a replica.
- Verify that the secondary server has network access, private DNS, firewall rules, identity settings, and monitoring ready before promotion.
- Check change approval and recovery objectives because set-primary or link deletion can alter write ownership or remove a fallback path.
- Understand cost impact; creating a geo-replica starts another database billing stream and may require additional logging or private endpoint resources.
What the output tells you
- Replica role fields identify whether the database is primary or secondary, which is essential before any promotion or cleanup command.
- Partner server and partner database values confirm the actual recovery target rather than the intended target in a design document.
- Replication state and link identifiers help diagnose whether the relationship is healthy, creating, broken, or ready for operational action.
- Service objective and region information reveal whether the secondary is sized and placed appropriately for reporting or recovery expectations.
Mapped commands
SQL geo-replica CLI
az sql db replica create --resource-group <resource-group> --server <primary-server> --name <database> --partner-server <secondary-server> --partner-resource-group <secondary-resource-group> --service-objective <service-objective>az sql db replica set-primary --resource-group <secondary-resource-group> --server <secondary-server> --name <database>az sql db replica delete-link --resource-group <resource-group> --server <primary-server> --name <database> --partner-server <secondary-server>Architecture context
Architecturally, I place a SQL geo-replica inside the broader continuity pattern. The primary region owns writes, the secondary region has a prepared database, and the application plan defines when the secondary is read-only, promoted, or used only for migration. The secondary logical server needs private DNS, firewall rules, auditing, identity, tagging, and monitoring before it is trusted. For multiple databases that fail over together, I usually prefer a failover group on top of the replica pattern. For single-database migration or reporting, an individual geo-replica can be cleaner. The design decision depends on dependency grouping, routing needs, and recovery objectives. Document ownership. Documenting ownership keeps recovery choices clear during incidents.
- Security
- Security impact is direct because the geo-replica is a real database copy containing production data. It needs the same encryption posture, auditing expectations, access review, network isolation, and identity governance as the primary. A secondary server with loose firewall rules or forgotten SQL logins can become the weak side of a resilient design. Operators should verify Microsoft Entra administration, contained users, private endpoints, diagnostic settings, vulnerability assessment, and Defender configuration where used. Promotion can also change where writes occur, so application secrets and managed identities must be ready for the secondary endpoint before any failover or migration event. Review regularly. Replica access should be reviewed whenever the primary database receives new privileged users.
- Cost
- Cost impact is direct because a geo-replica is another database resource with compute, storage, backups, networking, and monitoring. It may need the same service tier as the primary for fast recovery, or a lower tier if promotion allows scaling first. Read-only workloads can justify some spend by offloading the primary, but they can also hide that the replica was sized for analytics rather than failover. Cross-region designs add operational and testing cost. FinOps reviews should tag replicas by purpose, measure whether they are used for reporting, and verify that retired migration replicas are removed after the fallback window closes. Review monthly. Budget review should confirm each replica still serves an active objective.
- Reliability
- Reliability impact is strong but depends on execution. A geo-replica provides a running secondary database that can be promoted when the primary region or server is unavailable, but replication is asynchronous and may have lag. Reliability planning must include recovery point expectations, failover criteria, link health monitoring, application retry behavior, and what to do if a secondary is not current enough for a business process. The secondary must be tested under realistic load because idle readiness is not the same as promoted readiness. Remove or reconfigure replica links carefully after migration so teams do not lose their fallback path unexpectedly.
- Performance
- Performance impact depends on read routing, replica sizing, and replication lag. Read-only workloads on the geo-replica can reduce pressure on the primary, especially for reporting or validation queries, but users may see stale data. Under-sized secondary databases may handle replication while idle but struggle after promotion. Network latency between application clients and the secondary region also matters during failover. Operators should test realistic query patterns on the replica, monitor replication health, and avoid using lag-sensitive reads for decisions that require current writes. Promotion performance should be validated before the recovery plan is trusted. Rehearse promoted workloads before declaring recovery success. Latency tests should run before users depend on secondary reports.
- Operations
- Operators manage geo-replicas by creating links, checking replica role, watching replication health, testing read-only connections, and practicing planned failover. Day-to-day operations include confirming the secondary exists in the intended region, validating network access, reviewing lag-sensitive workloads, and documenting whether the replica is for disaster recovery, reporting, or migration. Troubleshooting often starts with replica link output, database state, server firewall rules, private DNS, and failed client connection logs. After promotion, operators validate writes, run application smoke tests, update runbooks, and decide whether to reverse replication or clean up the old primary. Keep promotion and cleanup runbooks current for every replica. They should also track who may approve promotion during business hours.
Common mistakes
- Creating a geo-replica for disaster recovery but leaving secondary server networking, identities, or private DNS untested.
- Assuming the replica is always current enough for every business process even though active geo-replication is asynchronous.
- Using a low-cost secondary tier for savings, then discovering after promotion that application performance is unacceptable.
- Deleting the replication link immediately after migration without preserving a rollback window or documenting the new primary ownership.
Copied command