SQL Server 2014 AlwaysOn AG Failover

8/19/2019 SQL Server 2014 AlwaysOn AG Failover

1/22

Choirul AmriHead of Enterprise DivisionEbiz Cipta Solusi | [email protected]


2/22

https

://groups.yahoo.com/neo/groups/sqlserver-indo

https://groups.yahoo.com/neo/groups/sqlserver-indo/infohttps://groups.yahoo.com/neo/groups/sqlserver-indo/infohttps://groups.yahoo.com/neo/groups/sqlserver-indo/info


3/22

Session Objectives

http://micha19.deviantart.com

/art/l212148508

http://micha19.deviantart.com/art/let-s-cooking-manga-girl-212148508http://micha19.deviantart.com/art/let-s-cooking-manga-girl-212148508http://micha19.deviantart.com/art/let-s-cooking-manga-girl-212148508http://micha19.deviantart.com/art/let-s-cooking-manga-girl-212148508


4/22

AlwaysOn Landscape – SQL Server 2014

Failover Cluster Instance(FCI)

• Instance level

• Shared storage

• Failover per instance

• No active secondary

• Support auto, transparentfailover

Availability Gro

• Database level

• No shared storage

• Failover per DB gr

• Active secondary

• Support auto, tranfailover


5/22

Availability Groups Advantage

• No shared storage, easier and faster to implement

•

Active secondary for better box utilization‐ Offload reporting to secondary

‐ Backup from secondary

• Support automatic failover

• Transparent client failover


6/22

What’s the “Groups” mean?

• Failover happens on “group of databases” rather than individual

• You can also create a group with only one database

•

Why: You want to make sure that related DBs are failed-over toget

Primary Server

CustomerDBTicketing

Secondary Server

CustomerDBTicketing

Jika Primary bermasalah:

Ticketing dan CustomerDB

dipindahkan bersamaan ke

secondary


7/22

Availability Groups – Availability Mode

Asynchronous

• Better performance• Primary commits without waiting notification from

• Possible data loss in failover

Synchronous• Primary waits for notification from secondary bef

committing transaction

• Performance penalty

• No data loss during failover


8/22

Availability Groups – Common Implementation

KOMODOSQL1 - Primary Server

CustomerDB

Primary Replica

Ticketing

Primary Replica

KOMODOSQL2 - Secondary Server

Readable Secondary

CustomerDB

Secondary Replica

Ticketing

Secondary Replica

KOMODOSQL3 - Secondary Server

Non-Readable (standby only)

CustomerDB

Secondary Replica

Ticketing

Secondary Replica

Synchronous

Asynchronous

Availability Listener

SQLAG-LS


9/22

DemoPlanned – Manual Failover


10/22

Failover Mode

Automatic

• Require Synchronous mode

• No data loss

• Machine shutdown or service unavailable

Planned - Manual

• Require Synchronous mode

• No data loss

• Use SSMS or T-SQL

Forced - Manual

• Replicas are in asynchronous commit mode

• Forced means: You can afford loosing data

• Obviously, data loss is possible


11/22

Automatic Failover - Requirement

Requirement

• Minimum 1 pair databases are in Synchronous-commit with Autom

failover• Secondary databases are in synchronized state

• Windows Cluster is in good condition and fulfill the quorum require


12/22

Automatic Failover – Ready to failover


13/22

DemoAutomatic Failover


14/22

Failover Mode – Real Life Scenario

Automatic

• Servers in the same data center with low latency network

• Unexpected machine crash or SQL service disruption

Planned - Manual

• Patching OS or SQL Server

• HA/DR exercise

• Upgrading hardware

Forced - Manual

• Real disaster happens – failover to DR site

• 3 servers, but 2 machines in primary DC are down

• There is no primary available in the configuration!


15/22

Forced Manual Failover – Fixing “Resolving” con

What happen if:

1) KOMODOSQL2\SQL2014 is down; then

2) Client still can access the primary as usual (but now there is no “automatic” pa3) KOMODOSQL1\SQL2014 is down

4) Automatic failover to KOMODOSQL3\SQL2014 will not happen!

5) DBs in KOMODOSQL3\ SQL2014 replica is in “resolving” mode

6) Client application cannot connect

Server Instance Availability Mode Failover Mode Role

KOMODOSQL1\SQL2014 Synchronous commit Automatic Primary

KOMODOSQL2\SQL2014 Synchronous commit Automatic Secondary

KOMODOSQL3\SQL2014 Asynchronous commit Manual Secondary


16/22

Recovering the “last man standing” node

Your situation:

• Primary and secondary in production are lost

• You only have 1 node in DR, but it is in resolving state, inaccessible f


17/22

Bring Your “resolving” replica alive

--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE

--- KOMODOSQL3 is the replica in resolving state

:Connect KOMODOSQL3\SQL2014

ALTER AVAILABILITY GROUP [KomodoSQLAG]FORCE_FAILOVER_ALLOW_DATA_LOSS;


18/22

DemoRecovering from “Resolving” sta


19/22

Q/A


20/22

Download my e-book

https://leanpub.com

Work in progress, If Y

please email me


21/22

Visit my blog


22/22

Thank You

SQL Server 2014 AlwaysOn AG Failover

Documents

Transcript of SQL Server 2014 AlwaysOn AG Failover