Transcript
Microsoft Confidential
HADR with SQL Server 2016 AlwaysON
Session- 2 AlwaysON Architecture and internals
1
Uday Bhanu PathaniyaPFE-SQL Serverudpathan@Microsoft.com
Microsoft Confidential
1. How AlwaysON works2. What's AlwaysON Availability Groups /Replicas/ Listener3. AlwaysON supportability and pre-requisites4. Demo of AlwaysON HA Configuration5. Backups on AlwaysON secondary replica
3
Legacy Architecture: Database Mirroring for local HA, Log Shipping for DR
Pre-SQL Server 2012
Challenges
Possible data loss in Log shipping.
Human intervention require in case of failover.
Unavailability of user databases during log restoration.
Can’t easily glue together databases that need to run on the same node
Data Warehouse load restrictions due to limitations in Log Shipping
Maintaining database mirroring connection strings (failover_partner) in all applications is painful, and in some cases (some 3rd party applications) not even supported
Not easy to access data on mirrored server.
No. of nodes limitations in mirroring.
Interdependency of databases are not address in mirroring as well as in log shipping.
What is AlwaysOn ?
Is a combination of database mirroring and
windows clustering.
Multiple mirrors with multiple databases that can failover together.
Single gateway(Listener) can
be configure for automatic failover
Nodes can be used to offload the select query workload and database
backup workload.
Single solution which can address HA & DR
needs.
How Always on work ?
Primary Data Center Disaster Recovery Data Center
SQL ServerPrimary
SQL ServerSecondary
Windows Server Failover Cluster (single WSFC crossing two data centers)
Availability Group
Synchronous
Asynchronous
SQL Server
Secondary
Based on windows failover cluster(WFC) & SQL Server database mirroring.
Read T-logs and transfer active portion of logs to all secondary replicas.
No Shared volume require for WFC.
Interdependent databases can be grouped into logical groups and can failover together.
Data transfer between replica nodes is compressed and encrypted.
listener support automatic client redirection to the primary replica or redirection to available readable secondaries.
Availability group listeners remove the need to designate a failover partner in the client connection string.
Grammar of AlwaysOn… • Read-write , Online user database from primary Instance of database server. • Databases added in availability in Availability groups are called availability databases & each Availability Database is a part of only single Availability Group.• Backup of the primary database has to restore on secondary replica in norecovery state and new secondary database will remain in restoring state until it is
not joined to Availability groupAvailability Database
• Logical container which logically binds the user databases which needs to be failover together. • All the availability databases will failover together on same secondary replica.• Single Availability Group can hosts multiple Availability Databases.Availability Groups
• All the possible failover partners(must be a separate instance of SQL Server on other node) are known as Availability Replica. • Each Availability replica is a copy of Availability database in a Availability Group. • Each Availability replica is assigned an initial role- Primary or secondary. Primary replica hosts read-write user database & at least one secondary replica
hosts read-only user database.Availability Replica
• There are two Modes- 1.) Synchronous-Commit mode & 2.) Asynchronous-Commit mode.• In 1. Synchronous-commit primary replica wait for acknowledgement from synchronous-commit secondary replica that it has commit the transaction
in t-log of secondary database then after primary replica commit transaction.• In 2. asynchronous-commit primary replica commit the transaction without waiting for acknowledgement from asynchronous-commit secondary
replica that it has commit the transaction.• Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making
some data loss possible.
Availability mode
• With SQL Server AlwaysOn no need to have shared storage, but can use SAN, DAS, NAS or Local Disk depending on your budget and requirements.
AlwaysOn Storage
• Active secondary replica supports backup offloading on secondary replica and readable secondary replica.• In backup offloading we can log backups , full backup of database , file or filegroup. Backup presences can be set on secondary replicas. • An availability replica can be allow read-only access to its local databases when performing the secondary role. • If an availability group currently possesses an availability group listener and one or more readable secondary replicas, SQL Server can route read-intent
connection requests to one of them (read-only routingActive Secondary Replica
•Availability replica property:- How long the connection with another availability replica can remain inactive before the connection is close
Session-timeout period
Grammar of AlwaysOn.
• Availability group listener is a Virtual network name(VNN) to which clients can connect in order to access a database in primary or secondary replica.
• The physical instance name of SQL Server is hidden to clients while accessing availability databases through listener.
• The client connection string does not to modify in order to access either of Availability database base.
• We need DNS name for listener , a listener port designation one or more IP address.
• Client use DNS to resolve VNN into multiple IP addresses and then tries to connect with each IP address until the connection request successes or timed out.
• If we configure read only routing then all read-intent connections are redirected to readable secondary replica.
Availability Group listener
Connectivity with Availability Group Listener
Connect to the Primary Replica
Server=tcp: AGListener,1433;Database=MyDB;IntegratedSecurity=SSPI
Connect to Read-Only Secondary Replica
Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly
Connect to Multisubnet failover
Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI; MultiSubnetFailover=True
AlwaysON pre-requisites
KB 2654347:Hotfix for .Net 3.5 SP1
Other Hotfix KB 2494036 for
optimal WSFC quorum , KB
2687741 for faster failover to local
relica etc.
Each node must be configure under WSFC(preferably node-fileshare).
A separate SQL Server Instance on each WSFC node
and enable AlwaysOn feature
for each SQL Server service.
Enterprise edition of SQL Server 2016
All the server instances that host availability replicas for an availability
group must use the same SQL Server
collation.
No. of available worker threads are
very important.
Create endpoints or member of
sysadmin privileges require
DHCP IP can be used but it is
recommended to use static IPs.
AlwaysON Restrictions
• Restrictions for SQL Server failover cluster instance(FCI) • The cluster nodes of an FCI can host only one replica for a given availability group• FCIs do not support automatic failover by availability groups• Changing FCI network name
• Restriction for SQL Server Availability Group • Availability replicas must be hosted by different nodes of one WSFC cluster• Unique availability group name• Only 8 secondary replicas are supported. Either all can be configured as async • commit mode or up to 3 can be configure as sync-commit mode• Maximum number of availability groups and availability databases per computer depends on Hw
configuration. MS has tested 10AGs with 100 DBs per AG. • Restriction for SQL Server Availability Databases
• If file path is different then • New Availability Group Wizard/Add Database to Availability Group Wizard• the database files must be RESTORED WITH MOVE on each instance of SQL Server that hosts a secondary
replica.• A later add-file operation on the primary replica might fail on the secondary databases.
Demo-AlwaysON HA Configuration
Backups on AlwaysON secondary replica
• Copy-Only full backup of databases , files & filegroup is supported on secondary replica. • Differentail backup is not supported on secondary replica.• Backup log supports only regular backup & log chain remain consistent irrespective of backup log location or
availability mode( Synchronous-commit or Asynchronous-commit)• Secondary replica must be in SYNCHRONIZED or SYNCHRONIZING state.• In case of more than two nodes backup preferences(AG property) can be set to ‘Prefer Secondary’ , ‘Secondary
Only’ , ‘Primary’ ,’Any Replica’. • Additionally Replica backup priorities can be set to ‘Server Instance’, ‘Backup Priory(Lowest=1, Highest=100)’ ,
Exclude Replica. • It is recommended to configure script based backup jobs on each replica. • Use the sys.fn_hadr_backup_is_preferred_replica function to determine whether the current replica is the
preferred backup replica or not. • This function return 1 in case if the current replica is a preferred replica else 0.
top related