High Availability (HA) replica in Azure SQL Database


What is a High Availability (HA) Replica?

  • It’s like having a backup server that can quickly take over if the main server (called the primary replica) fails.
  • These backups are called HA replicas, and they are always ready to step in without delay (called hot standby).

Key Features:

  1. No Data Copy Needed:
    • HA replicas use the same storage as the primary server, so there’s no need to duplicate the data.
  2. Failover Happens Automatically:
    • If the primary server becomes unavailable, one of the HA replicas takes over automatically, ensuring minimal downtime.
    • Your application won’t need to update its connection string; it just reconnects to the new replica.
  3. Retry Logic is Important:
    • Since active connections might drop during failover, your application should have a mechanism to retry the connection.
    • Some programming libraries, like Microsoft.Data.SqlClient for .NET, already support this feature.
  4. Not Stand-Alone:
    • HA replicas aren’t visible or managed separately. They’re part of the primary replica and cannot be directly controlled.
  5. Billing:
    • You’re charged for the compute resources of HA replicas, but no extra charges for storage.
  6. Number of HA Replicas:
    • You can have 0 to 4 HA replicas.
    • These can be set up when creating a database or added later using Azure tools like Azure Portal, CLI, or PowerShell.
  7. Read-Only Connections:
    • HA replicas can handle read-only requests if the connection string includes ApplicationIntent=ReadOnly.
    • If there are no HA replicas, the request is sent to the primary server in read-write mode.

How Data is Synced Across Replicas:

  • The primary server logs changes (like transactions) and sends them to all HA replicas.
  • Each replica applies these changes at its own speed, so there might be slight differences (called latency) between replicas.

Why Use HA Replicas?

  1. To ensure your database is always available, even if the primary server goes down.
  2. To balance workloads by sending read-only queries to HA replicas, reducing the load on the primary server.

Simple Analogy:

Think of a high-availability replica like a backup power generator.

  • The primary server is your main power supply.
  • If the main power supply fails, the backup generator (HA replica) kicks in automatically without disrupting your work.

Related Posts

Secure supply chain: SBOM, SLSA, signing, provenance (plain English)

If you ship software today, you don’t just ship your code. You ship: That whole chain is your software supply chain. And attackers love it, because instead…

Read More

CI/CD for Cloud Apps: Build → Scan → Deploy → Rollback (a practical reference pipeline)

CI/CD sounds simple until you’re responsible for a production system and realize: This guide gives you a reference CI/CD pipeline you can adopt for most cloud apps…

Read More

Policy as Code: OPA/Rego basics + how it prevents bad infra

You know that feeling when an incident starts with a sentence like: Most “bad infra” isn’t malicious. It’s normal engineering drift:new hires, rushed PRs, copy-paste manifests, unclear…

Read More

Reusable IaC Module Design: naming, inputs/outputs, versioning (the engineer’s playbook)

Reusable IaC modules are like internal libraries: if the “API” is clean, teams move fast. If it’s messy, everyone forks it, patches it, and you end up…

Read More

GitOps explained: Argo CD vs Flux, patterns, and anti-patterns

GitOps is one of those ideas that sounds like buzzwords… until you run it for 30 days and suddenly you can’t imagine operating Kubernetes without it. Because…

Read More

Terraform vs CloudFormation vs Pulumi: which fits which team (the practical, engineer-first guide)

You’re not really choosing a tool. You’re choosing how your team will think about infrastructure for the next 2–5 years: This guide helps you decide fast, without…

Read More
guest
0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x
()
x