Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

AlwaysON Basics

This Ppt covers the basics of AlwaysON.

  • Identifiez-vous pour voir les commentaires

AlwaysON Basics

  1. 1. Microsoft Confidential HADR with SQL Server 2016 AlwaysON Session- 2 AlwaysON Architecture and internals 1
  2. 2. Uday Bhanu Pathaniya PFE-SQL Server udpathan@Microsoft.com
  3. 3. Microsoft Confidential 1. How AlwaysON works 2. What's AlwaysON Availability Groups /Replicas/ Listener 3. AlwaysON supportability and pre-requisites 4. Demo of AlwaysON HA Configuration 5. Backups on AlwaysON secondary replica 3
  4. 4. Legacy Architecture: Database Mirroring for local HA, Log Shipping for DR
  5. 5. 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.
  6. 6. 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.
  7. 7. Primary Data Center Disaster Recovery Data Center SQL Server Primary SQL Server Secondary Windows Server Failover Cluster (single WSFC crossing two data centers) Availability Group Synchronous Asynchronous SQL Server Secondary
  8. 8. 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 group Availability 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 routing Active Secondary Replica •Availability replica property:- How long the connection with another availability replica can remain inactive before the connection is close Session-timeout period
  9. 9. 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
  10. 10. 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
  11. 11. 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.
  12. 12. 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.
  13. 13. Demo-AlwaysON HA Configuration
  14. 14. 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.