What is the difference between adding a cluster node and adding an AG replica?
A cluster node is a Windows Server member of WSFC that can host clustered roles. An AG replica is a SQL Server instance on such a node that participates in the availability group and holds a copy of the databases. The layers are distinct even if wizards combine steps.
In what order do you typically add capacity for Always On on a new Windows server?
Join the server to WSFC first, re-check quorum, then install SQL (aligned version/CU), enable Always On, configure the HADR endpoint, and on the primary use ALTER AVAILABILITY GROUP ... ADD REPLICA followed by seeding (automatic or backup/restore + join).
How do you add a node to an existing WSFC, and what validation should you run?
Failover Cluster Manager → cluster → Nodes → Add Node, or PowerShell Add-ClusterNode. Run Validate a Configuration (full or targeted) and fix failures that affect your design before relying on the node.
After the node count changes, what must you verify for cluster health?
Confirm quorum (and witness if used). Dynamic quorum / dynamic witness may adjust votes, but you still verify odd total votes and that losing an AZ or site does not violate your RPO/RTO targets.
What must match on the new SQL instance before it can join an existing AG?
Same SQL Server major version and typically the same CU; collation and other instance-level settings must be compatible with the group — collation mistakes are expensive to fix later.
How do you enable Always On on the new instance, and what is the immediate follow-up?
SQL Server Configuration Manager → SQL Server service → enable Always On Availability Groups → restart the instance. Then configure the HADR / database mirroring endpoint on a chosen TCP port (often 5022) and open it between all replicas.
On the primary, how do you add the new instance to the AG, and what replica options matter?
ALTER AVAILABILITY GROUP ... ADD REPLICA ON ... with the right endpoint URL, synchronous vs asynchronous commit, automatic vs manual failover, readable secondary (where licensed), backup priority, etc.
Compare automatic seeding to the manual backup/restore path for bringing databases onto a new replica.
Automatic seeding copies data over the AG fabric after the replica is added when enabled and suitable — no manual BACKUP/RESTORE for that path. Manual is used when automatic seeding is off, unsupported, or you want file-level control via UNC or copy.
For the manual join path, what recovery model is required on the primary, and what RESTORE option must you use until the final join?
FULL recovery is required for AG participation. On the new replica, restore the full and every log with NORECOVERY (or equivalent) so the database stays RESTORING until SET HADR AVAILABILITY GROUP.
When might you use COPY_ONLY on the initial full for seeding a new replica, and what must stay true afterward?
COPY_ONLY avoids disturbing your differential base on the primary. It is allowed if every subsequent log backup you restore continues an unbroken LSN chain from that full. When in doubt, use a normal full for a straightforward join.
What T-SQL joins a database on the new replica to the AG after restores, and where do you run it?
On the new replica (database still RESTORING): ALTER DATABASE db SET HADR AVAILABILITY GROUP = 'YourAGName';. SQL Server then brings the DB into the group and catches up via redo on the HADR channel.
Name three common pitfalls when manually seeding a new AG replica.
Bringing the DB to RECOVERY or STANDBY too early (can’t SET HADR — may need a new full); a broken LSN chain (missing log backup); wrong paths (forgot MOVE to local disks) or permissions (secondary service account can’t read backups).
Which DMVs do you use to confirm replica and database synchronization health after the add?
sys.dm_hadr_availability_replica_states and sys.dm_hadr_database_replica_states — look for synchronized / healthy redo; investigate suspended or stuck states.
If the new replica is readable, what might you need to update for read-only clients?
Read-only routing so applications using ApplicationIntent=ReadOnly land on the right secondary; also consider resource sizing (CPU, memory, max worker threads) if it will take meaningful read workload.
What is a concise interview walkthrough line for adding a node to an existing AG?
“I add the Windows server to WSFC and re-check quorum. I install SQL at the same version/CU, enable Always On, and open the HADR endpoint. On the primary I ALTER AVAILABILITY GROUP ADD REPLICA, then automatic seeding or backup/restore + JOIN until replicas are synchronized, and I adjust read-only routing if this is a readable secondary.”
For rolling patches in an AG, what is the usual order of operations?
Typically patch secondaries first, then a controlled failover to move primary work — follow Microsoft guidance for your SQL Server version; align maintenance policies (e.g. CHECKDB on secondaries) with the team.
