Supporting MS SQL Server Failover Using Database Mirroring · Supporting MS SQL Server Failover ......

Supporting MS SQL Server Failover Using Database Mirroring

with Mertech Flex2SQL for MS SQL Server

Contents

Overview

How Does it Work?

SQL Server Setup

Using Mirroring Support

Contact Information

© 2006 - 2013 Mertech Data Systems, Inc. All rights reserved. This document is for informational purposes only. Mertech makes no warranties, expressed or implied, in this document.

Microsoft, Windows, and SQL Server are registered trademarks of Microsoft Corporation DataFlex is a trademark of Data Access Worldwide, Inc. Other trademarks and trade names mentioned herein are the property of their respective owners.

Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.

- 1 -

Overview

Microsoft introduced database mirroring in SQL Server 2005 to increase database availability.

Database mirroring maintains two copies of a single database on different server instances. One

instance is the primary or principal server, the other instance is the standby or mirror server. If the

principal server goes down the mirror server can take over with no loss of committed data.

Fast failover with minimal data loss has traditionally involved higher hardware cost and greater

software complexity. Database mirroring, however, can fail over quickly with no loss of committed

data, does not require proprietary hardware, and is easy to set up and manage.

SQL Server 2005 SP1 or above is required to use mirroring.

How Does it Work?

All SQL Server databases record data changes in a transaction log before any changes are made to

the actual database. In database mirroring, the principal server writes the transaction log buffer to

disk and simultaneously sends it to a mirror server. The transaction log records are then replayed on

the mirror server to keep the two database instances in sync. A third (optional) server witnesses the

health of the principal and mirror servers to enable automatic failover.

Principal

Data Flow

Witn

ess

Mirror

Optional

Server Roles

Principal

The originating server, the one that sends the transaction log to the standby SQL Server instance.

The principal database is available to an SQL client during normal operation.

Mirror

The standby SQL Server instance, the one that receives the transaction log from the principal server.

The mirror database is not available to an SQL client unless the principal server is down and the

mirror server has taken over.

Partner

The principal and mirror servers are considered partners in maintaining the mirrored database.


- 2 -

Witness

The witness server's role is to allow the mirror server to recognize that the principal server is down

and to take over. The witness server does not have a database of its own.

The principal, mirror, and witness servers all send heartbeat messages to each other to monitor their

connection status. If the partners become disconnected from each other, they rely on the witness to

make sure that only one of them is currently serving the database. If a mirror server loses its

connection to the principal server, the mirror server contacts the witness to determine whether the

witness has lost its connection to the principal server:

• If the principal server is still connected to the witness, the principal server continues to serve the

database while accumulating log records to send the mirror server when the partners reconnect.

• If the witness is also disconnected from the principal server, the mirror server initiates an

automatic failover.

All Servers Alive

Principal

Witn

ess

Mirror

Principal Remains in Charge

Principal

Witn

ess

Mirror

Mirror Takes Over

Principal

Witn

ess

Mirror

The requirement that at least two of the server instances be connected is known as quorum. Quorum

makes sure that the database can only be served by one partner at a time.


- 3 -

Operational Modes

There are three operational modes in SQL Server mirroring:

High Availability

The High Availability operating mode supports maximum database availability with automatic failover

to the mirror database if the principal database fails. It requires that you set safety to FULL and

define a witness server as part of the database mirroring session. The database mirroring operation is

synchronous, a transaction is not completed on the principal server until the principal server receives

an acknowledgement from the mirror server that the transaction log record has been recorded. Once

this occurs, the client application gets confirmation that the transaction was committed. A witness

server is used to monitor the status of the principal and mirror servers. If the principal server

becomes unavailable, and the mirror server and witness are connected, the mirror server can initiate

take over.

Principal

1. Update

2. Log

3. ACK

Witn

ess

Mirror

4. Comitted

High Protection

The High Protection operating mode also has transactional safety set to FULL and the database

mirroring operation is synchronous. However, there is no witness server as part of the mirroring

session. In this mode only a manual failover is possible because the partners have no way to

determine each other’s status.

Principal Mirror

1. Update

2. Log

3. ACK

4. Comitted


- 4 -

High Performance

In the High Performance operating mode, transactional safety is OFF and the transfer of log records is

asynchronous. The principal server does not wait for an acknowledgement from the mirror that all

transaction log records have been recorded on the mirror. The mirror does its best to keep up with

the principal, but it is not guaranteed at any point in time that all the most recent transactions from

the principal will have been hardened in the mirror's transaction log.

Principal Mirror

1. Update

3. Log

2. Comitted

Database Mirroring Feature Support by SQL Server 2012

Enterprise Business

Intelligence Standard Web

Express

with Advanced Services

Express with Tools Express

Yes Yes (Safety Full Only)

Yes (Safety Full Only)

Witness only

Witness only

Witness only

Witness only

Refer to Microsoft documentation for additional information and a description

of feature support by server addition.


- 5 -

SQL Server Setup

Create the Databases

The principal server, mirror server, and (optional) witness must be hosted by separate server

instances.

• The principal and mirror server instances must be running on the same version and edition of

SQL Server.

• The mirror database must have the same name as the principal database.

• All the database users should have logins on the mirror server.

Our example uses SQL server instances, LEIA\MAIN and LEIA\MIRROR running SQL Server 2008.

Enable FULL Recovery Mode

Both databases must use the FULL recovery model. Log records that result from bulk-logged

operations cannot be sent to the mirror database.

Check to see if FULL recovery mode is enabled:

Select name, recovery_model_desc

FROM sys.databases

WHERE name = 'main';

GO

If not, set FULL recovery mode:

USE master;

GO

ALTER DATABASE main SET RECOVERY FULL;

GO


- 6 -

You can also use SQL Server Management Studio:

1. In Object Explorer, click the server name to expand the server tree.

2. Right-click the database.

3. Select Properties.

4. Select Options in the Select a page pane.

5. Select Full Recovery model using the drop-down arrow.

6. Click OK.

Create Endpoints

Configure endpoints (port listeners) where the principal and mirror are going to establish

communication.

Principal Endpoint:

USE main;

GO

CREATE ENDPOINT MirroringEndPoint_Principal

STATE=STARTED

AS TCP (LISTENER_PORT=10111)

FOR DATABASE_MIRRORING (ROLE=PARTNER) -- Enabled as Partner only

GO

Mirror Endpoint:

USE main;

GO

CREATE ENDPOINT MirroringEndPoint_Mirror

STATE=STARTED

AS TCP (LISTENER_PORT=10112)

FOR DATABASE_MIRRORING (ROLE=ALL) -- enabled as Witness or

Partner

GO

To inspect your created endpoints:

SELECT name, role_desc, state_desc

FROM sys.database_mirroring_endpoints;


- 7 -

Backup the Principal Database

Important: The principal and mirror backup (log and data) should be located in the same exact location (e.g. C:\backup\data.bak).

Issue a full backup of the database and transaction log:

USE main

GO

BACKUP DATABASE main

TO DISK = 'C:\main_Data.bak'

WITH FORMAT

GO

BACKUP LOG main

TO DISK = 'C:\main_Log.bak'

WITH FORMAT




3. Select Tasks | Back Up.

4. In the Backup type list box, select Full.

5. Click Add, enter the backup file name, then click OK.

Restore the Backup to the Mirror

Restore the backup to the mirror server using the WITH NORECOVERY option.

RESTORE DATABASE main

FROM DISK='C:/main_data.bak' WITH REPLACE,NORECOVERY

Also restore the log WITH NORECOVERY option.

RESTORE LOG main

FROM DISK='C:/main_Log.BAK' WITH NORECOVERY




3. Select Tasks | Restore | Database.

4. On the General page, use the Source section to specify the source and location of the

backup sets to restore.

5. On the Options page, select Recovery state RESTORE with NORECOVERY.

This mirror database is no longer available to open or make changes; it

is now a mirror database and can only be used for mirroring.


- 8 -

Enable the Mirroring Session

Setting up a database mirroring session requires a server network address for each of the server

instances.

Before you can specify a port in a server network address, the database mirroring endpoint must exist on the server instance

To identify the port currently associated with database mirroring endpoint of a server instance:

SELECT type_desc, port FROM sys.tcp_endpoints

Start the database mirroring session on the mirror:

ALTER DATABASE main

SET PARTNER = 'TCP://127.0.0.1:10111'

GO

Start the database mirroring session on the principal:

ALTER DATABASE main

SET PARTNER = 'TCP://127.0.0.1:10112'

GO

Obtain general information:

SELECT

DB_NAME(database_id) AS 'DatabaseName'

, mirroring_role_desc

, mirroring_safety_level_desc

, mirroring_state_desc

, mirroring_safety_sequence

, mirroring_role_sequence

, mirroring_partner_instance

, mirroring_witness_name

, mirroring_witness_state_desc

, mirroring_failover_lsn

FROM sys.database_mirroring

WHERE mirroring_guid IS NOT NULL;

Refer to Microsoft documentation for additional details.


- 9 -

Using Mirroring Support in Mertech Flex2SQL

DataFlex developers using Mertech’s Flex2SQL can take advantage of the SQL Server Database

Mirroring feature to develop high-availability applications. To use this feature, the developers need to

use a new command, SET_MIRROR_SERVER in their login module. This identifies the mirrored

server to the driver which in turns negotiates the communication with the server. If the principal

server fails, the driver automatically connects to the mirror server and continues operation. This does

not require any additional code in DataFlex to check for a lost connection.

Note: Any non-committed transactions need to be retried by the application.

A VDF application normally retries the transaction, but please consult the VDF manual for details.

Syntax

SET_MIRROR_SERVER to <Server name> <Main server>

Example

To make DataFlex work with mirroring and Mertech's driver, you can create a program that logs in,

sets the mirror, and then executes your application.

loginchain.src

use mertech.inc

string p1 p2

Load_Driver "SQL_DRV"

// Set the Mirror Server

SET_MIRROR_SERVER to "MACHINE\MIRROR" "main"

If (Err) showln "Error setting failover Server"

// Login into the main server

login "MACHINE\MAIN" "user" "password" "sql_drv"

cmdline p1

cmdline p2

chain (p1 + " " + p2)

Compile the login program and run it:

dfcomp loginchain.src

dfrun logchain your_application_executable

Note: The GET_MIRROR_SERVER command is also available. Syntax:

GET_MIRROR_SERVER to <VAR>.


- 10 -

The Flex2SQL automatic login dialog also has an option to set the mirror server and database:

If you have a personalized login dialog, using the SET_MIRROR_SERVER command is the best option.

Note: The mirror server and mirror database can also be provided as

settings in the Mertech INI file.

Testing Your Mirrored Environment

To verify that your Visual DataFlex application is running in a mirrored environment:

1. Shutdown the main server.

2. Start your application.

A driver trace will show that your application logged into the mirror server.


- 11 -

3. Examine stored data.

4. Make changes to stored data.

5. Restart the principal server.

6. Fail over to the principal server.

ALTER DATABASE main

SET PARTNER FAILOVER

GO


- 12 -

7. Examine the changes in SQL Server Manager.

Conclusion

Using SQL Server Mirroring, you can ensure that your application is up 24/7. If your principal server

goes down, failover to a standby server can occur automatically without any loss of data and

transparently to your users.

Mertech’s Flex2SQL for MS SQL Server takes advantage of the MS SQL mirroring support and enables

a DataFlex application to be used in a high-availability environment.

Contact Information

If you would like to know more about Mertech’s products, please visit our website

www.mertechdata.com or contact us at:

Corporate Head Office Mertech Data Systems, Inc.

18503 Pines Boulevard, Suite 312 Pembroke Pines, FL 33029 USA Tel: +1 (954) 585 9016 Fax: +1 (866) 228 1213

California Office Mertech Data Systems, Inc.

114 East Shaw Avenue, Suite 100 Fresno, CA 93710 USA

http://www.mertechdata.com/

Supporting MS SQL Server Failover Using Database Mirroring · Supporting MS SQL Server Failover ......

Documents

Transcript of Supporting MS SQL Server Failover Using Database Mirroring · Supporting MS SQL Server Failover ......