View
168
Download
6
Category
Tags:
Preview:
Citation preview
th
EVENT
CHAPTER
Tips to Install and Manage AlwaysOn Availability Groupsin SQL Server 2012 & 2014Antonios Chatzipavlis
SQLschool.gr Founder, Principal Consultant
SQL Server Evangelist, MVP on SQL Server
Apr 30, 2015
3
I have been started with computers.
I started my professional carrier in computers industry.
I have been started to work with SQL Server version 6.0
I earned my first certification at Microsoft as Microsoft Certified Solution
Developer (3rd in Greece) and started my carrier as Microsoft Certified
Trainer (MCT) with more than 20.000 hours of training until now!
I became for first time Microsoft MVP on SQL Server
I created the SQL School Greece (www.sqlschool.gr)
I became MCT Regional Lead by Microsoft Learning Program.
I was certified as MCSE : Data Platform, MCSE: Business Intelligence
Antonios ChatzipavlisDatabase Arch i tect
SQL Server Evangel is t
MCT, MCSE, MCITP, MCPD, MCSD, MCDBA,
MCSA, MCTS, MCAD, MCP, OCA, ITIL-F
1982
1988
1996
1998
2010
2012
2013
CHAPTER
Follow us in social media
Twitter @antoniosch / @sqlschool
Facebook fb/sqlschoolgr
YouTube yt/user/achatzipavlis
LinkedIn SQL School Greece group
Pinterest pi/SQLschool/
help@sqlschool.gr
• Understanding AlwaysOn Availability Groups
• Availability Modes
• Active Secondary Replicas
• Failover options in an AlwaysOn Availability Group
• Flexible Failover Policies
• Enhancements to AlwaysOn AG in SQL Server 2014
• Pre-Requisites for Using AlwaysOn Availability Groups
• Pre-Installation Tasks
• Installation Scenarios
Agenda
Understanding AlwaysOn Availability Groups
Primary
Replica
Active secondary
Replica
Windows Server Failover Cluster
Availability
Group Listener
Read/write Read only
• Synchronous-commit mode• Primary replica sends transaction log changes to a secondary replica
• Secondary replica applies the changes in the log to its copy of the database,
and then sends an acknowledgement to the primary replica
• Primary replica commits the transaction
• Asynchronous-commit mode• Primary replica sends transaction log changes to a secondary replica and
then commits the transaction
• Secondary replica applies the changes in the log to its copy of the database
Availability Modes
• Offload workload to secondaries for improved performance
and better resource utilization
• Using secondary replicas for read access• Read-intent connections
• Any read-only connection
• Using secondary replicas for backups• Log backups
• Copy backups
Active Secondary Replicas
• Automatic failover • No data loss
• Planned manual failover• No data loss
• Forced manual failover• Possible data loss
• Use the Start Failover Wizard to initiate manual failover
Failover options in an AlwaysOn Availability Group
• Health check time-out threshold defines the frequency of health checks on the primary replica
• sp_server_diagnostics stored procedure performs health checks
• Failover condition levels• Level one – On server failure
• Level two – On server unresponsive
• Level three – On critical server error
• Level four – On moderate server error
• Level five – On any qualified failure conditions
• Use the ALTER AVAILABILITY GROUP Transact-SQL statement or PowerShell to configure the flexible failover policy
Flexible Failover Policies
• Maximum number of secondary replicas increased to eight
• Improved availability for read-only workloads
• Easier interoperability with Microsoft Azure
• Improved troubleshooting and diagnostics
Enhancements to AlwaysOn AG in SQL Server 2014
• Windows Server version
• Active Directory• Nodes must be domain members
• Nodes cannot be domain controllers
• Windows Server Failover Cluster• One replica per Availability Group per node
• Some configurations may require hotfixes
Pre-Requisites for Using AlwaysOn Availability Groups
• Install the Windows Server Failover Clustering on all servers that will be nodes in the cluster
• Create a Windows Server Failover Cluster
• Install a stand-alone instance of SQL Server on each node
• Enable the AlwaysOn Availability Groups feature on each SQL Server instance
• Create a file share to share the backups
• Install the databases on the SQL Server instance that will be the primary replica
• Perform a full backup of each database and place the backups in the file share
Pre-Installation Tasks
Installation Scenarios
• Enable AlwaysOn High Availability on
the existing FCI instance
• Add the Failover Clustering feature to
node (SA_1) that is located in the
secondary data center that you are
planning to add to the High Availability
solution.
• Add the SA_1 node to the existing
WSFC in the primary datacenter
• This node should not be part of your
Failover Cluster Instance
Failover Cluster in Primary and AG in Secondary Data Center
Failover Cluster in Primary and AG on a Failover Cluster in Secondary
• Always put services account to Kerberos using Setspn
• Create AG using a dummy database
• Create listener in a separate step
• To minimize down time proceed with manual restores
• Check the number of VLFs on AG Databases
• Set the same memory on AG Nodes in case of disaster
• Don’t forget to move SQL Logins
• Don’t forget to move Jobs and Alerts
Tips from the battle field
Thank you
SELECT
KNOWLEDGE
FROM
SQL SERVER
http://www.sqlschool.gr
Copyright © 2015 SQL School Greece
Recommended