Basics and Background Information
- Most important, mirrored databases are deprecated in later versions of MS SQL Server
- Database must use full recovery model
- You have to mirror the whole database, you cannot mirror partitions or tables or other objects, it must be the whole database It is all or nothing at database level
- The mirrored server can only be used for mirroring. It cannot be used for reporting or data access other than as the mirror (it is kept is host stand-by mode)
- Uses copy-on- write technology
- After setup, the mirrored database will always be in a continuous “restring” mode (this is indications things are good!)
- Witness server is optional, if it is not there the principal and mirror will decide failover. With witness server, a quorum is formed.
- You can use either SQL Server Standard, Enterprise or Developer editions
- Within SQL Server, grants must be given to the accounts that will be executing database mirroring
- Microsoft uses endpoints, which are assigned to each database mirroring configuration
- Requires service accounts or integrated domain level authentication
- Requires ports 1440 and 1450 be open
Not allowed
Can’t do mirrors on a partitioned database
Can’t be applied to databases using simple recovery
Can’t mirror a database to the same instance (source is the same as destination server)
Can’s setup mirrors for SQLs internal database – tempdb, master, msdb, model
Not supported on Express or Workgroup editions of SQL Server
You cannot bring a principal server offline as you can in an unmirrored configuration
Roles in a mirror configuration
Principal – the primary server where active transactions take place. After a failure, the mirror takes over role as principal.
Mirror – it has transactions copied from the principal server and applied to mirror. It is in a constant recovery state.
Witness – arbiter on which server is primary should the principal and mirror lose communication. It must have any version of SQL Server installed to act as mirror.
Operating modes
Synchronous – committed transactions are committed on both partners in mirroring pair. High safety are synchronous operations.
Asynchronous – transactions are committed without waiting for the mirror server to write the log to disk. This is high performance mode.
Failover
o One exception: You can use the mirror to create to snapshots
Automatic – configuration requiring principal, mirror and witness. Synchronous operations are required. Role switching is done automatically. This is for high availability mode.
Manual – no witness server and using synchronous operations. Role switching done manually;.
This is for high safety and no automatic failover. (No data loss)
Forced – a mirror server can forced to take over when the principal server has failed. This may
lead to data loss because transactions are not synchronized.
Setting Up and Configuring
Best practice is to use scripts that are repeatable and reduce errors
Getting ready to mirror (checklist):
o Verify all server instances are on the same service pack level
I would make sure the servers are as identical as possible (RAM, processor, hard
o Enough hard drive space on both servers with adequate opportunity for growth
o Register the server from SQL Server Management Studio (SSMS) (both principal and
mirror). This checks connectivity.
o Verify network connectivity.
o Verify the principal server database is in FULL RECOVERY model. (the error will state
this) drive, BIOS, OS version
Establish endpoints
-- Create endpoint for principal server
CREATE ENDPOINT [EndPoint Name]
State = STARTED
AS TCP (LISTENER_PORT = 1430, LISTENER_IP = ALL)
FOR DATA_MIRRORONG (ROLE = PARTNER, AUTHENTICATION =
WINDOWS NEGOTIATE, ENCRYPTIOON = REQUIRED ALGORITHM RC4)
Verify the endpoint is created (principal)
Select name, type_desc, port, ip_address from sys.tcp_endpoints;
SELECT db.name, m.mirroring_role_desc
FROM sys.database_mirroring m
JOIN sys.databases db
ON db.database_id = m.database_id
WHERE db.name = N’< database name >;’;
Select name, role_desc, state_desc from
sys.database_mirroring_endpoints;
Create endpoint for mirror server
-- create endpoint for mirror server
CREATE ENDPOINT [EndPoint Name]
STATE = STARTED
AS TCP (LISTENER_PORT = 1440, LISTENER_IP = ALL)
FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS
NEGOTIATE, ENCRYPTION = REQUIRED ALGORITHM RC4)
Create endpoint for WITNESS server
-- create endpoint for witness server
CREATE ENDPOINT [EndPoint Name]
STATE = STARTED
AS TCP (LISTENER_PORT = 1450, LISTENER_IP = ALL)
FOR DATA_MIRRORING (ROLE = WITNESS, AUTHENTICATION = WINDOWS
NEGOTIATE, ENCRYPTION = REQUIRED ALGORITHM RC4)
Grant permissions to the endpoints (you will need to run twice – connect from principal to mirror and mirror to principal. If there is a witness, you must run on witness as well.):
GRANT CONNECT ON ENDPOINT:: <EndPoint Name>; TO [<Account Name>;];
Creating database on the mirror server:
Make a complete backup on principal:
BACKUP DATABASE [Database Name]
TO DISK = N’<file name and location>.bak’
WITH FORMAT
GO
On the mirror server, map a drive to the backup location
-- use this restore database (with NoRecovery option)
RESTORE FILELISTONLY
FROM DISK = ‘<file name and location>.bak’
GO
RESTORE DATABASE <Database Name>
FROM DISK = ‘<file name and location>.bak’
WITH NORECOVERY,
MOVE ‘<database name>_Data’ TO ‘file path/file name.mdf’
MOVE ‘<database name>_Log’ TO ‘file path/file name.mdf’
GO
You should get a message that the restore was successful.
Backup and Restore Logs
On principal:
BACKUP LOG [database name]
DISK = N’\\path\filename.bak’
GO
Restore Log
RESTORE LOG [database name]
FROM DISK = N’\\path\filename.bak’
WITH FILE = 2, NORECOVERY
GO
If you set recovery after last transaction log, you are not mirroring, but recovering the database!
Synchronization
You must now apply the transaction log dump to the mirror database. This brings the database to a point of synchronization with the principal and leaves the mirror database in the Restoring state. At this point you can run through the mirroring wizard to start mirroring for high availability.
Testing Failover
From SSMS, navigate to the Database Properties > Mirroring page.
Select Failover button.
You will be prompted to confirm. Select YES.
Check in SSMS that the ports it is listening on have changed 1440/1430.
ALTER DATABASE [Database Name] set partner FAILOVER;
Identifying the Other EndPoints for DB Mirroring
— From the Mirror Server Database: identify the principal server
endpoint –
ALTER DATABASE <Database Name>
SET PARTNER = ‘ TCP://<server address>:1430’
GO
— From the Principal Server Database: identify the mirror server
endpoint…
ALTER DATABASE <Database Name>
SET PARTNER = ‘ TCP://<server address>:1440’
GO
— From the Principal Server Database: identify the witness server
endpoint…
ALTER DATABASE <Database Name>
SET PARTNER = ‘ TCP://<server address>::1450’
GO
-- To drop and existing endpoint
DROP ENDPOINT <endpoint name>;
-- to ALTER an existing endpoint
ALTER ENDPOINT <endpoint name>
STATE = STARTED
AS TCP( LISTENER_PORT = 1435 )
FOR DATABASE_MIRRORING (ROLE = PARTNER)
References
https://msdn.microsoft.com/en-us/library/ms189852.aspx
Prerequisites and Recommendations
https://msdn.microsoft.com/en-us/library/ms366349.aspx