Showing posts with label failover. Show all posts
Showing posts with label failover. Show all posts

Monday, 25 May 2015

SQL Server High Availability - Manual Failover by serverku

Availability As we have seen SQL Server High Availability configuration and listener since same, I would like to go ahead for manual failover test in SQL Server 2012. So I would suggest to go through related previous posts.
  1. Configure Listener for high availability in SQL Server
  2. Implement High Availability in SQL Server - How to
Moving to test manual failover of SQL Server High Availability and following are the steps. Here Server 2 is a primary replica and Server1 is a secondary replica. Now we have to switch over the primary role from Server2 to Server1.

Step 1 : Connect primary replica availability group. Go to Availability Group and right clink on that and click on Failover.


Step 2 :Select instance, which you want to make a primary replica as shown in the image.


Step 3 : Connect SQL server instance, which you selected in earlier steps.


Step 4 : Click on Next and You can see the current primary replica and new primary replica.


Step 5 : Finally success on next step.


Step 6 : Last step to confirm primary replica, so connect with listener name and confirm as shown in the image.


This is just a manual failover test of Availability Group and hope you enjoyed it. In the next post we will see automated failover of Availability Group.

Friday, 15 May 2015

Script to Database Mirroring in SQL Server by serverku

Apart from replication articles which I have written earlier, today i want to share for database mirroring configure with windows authentication without automatic failover. So let me share steps and required scripts for the same.

1. Make sure principal database has FULL recovery model.

2. Make sure Windows User on which mirror configured has enough access of both servers and databases.

3. Make sure TCPIP port open in firewall for both SQL Server instances on both server accordingly if firewall enabled.

4. Make sure database service running on windows user for which mirroring endpoint will be created.

5. Take a full backup of principal database and restore at partner server with norecovery.

6. Take a transaction backup of principal database and restore at partner server with norecovery and make sure all log backups restored with norecovery created after full backup of principal database.

7. Create a mirroring endpoint.
USE master
go

CREATE ENDPOINT [DatabaseMirroring]
AUTHORIZATION [<DomainName>\<UserName>]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = DISABLED)
8.  Get mirroring role and status details for confirmation.
USE master
go

SELECT
state_desc,
type_desc
FROM sys.database_mirroring_endpoints
9. Make sure 5022 port or whatever port used should be open in firewall if firewall enabled.

10. Run following command at partner server.
USE master
go

ALTER DATABASE <DatabaseName>
SET PARTNER ='TCP://<PrincipalHostName>.<DomainName>.local:5022'
11. Run following command at principal server.
USE master
go

ALTER DATABASE <DatabaseName>
SET PARTNER ='TCP://<PartnerHostName>.<DomainName>.local:5022'
12.Run following command in one of server if want to change high performance or high safety as per need and if it is supported.
USE master
go

-- OFF : High performance
-- FULL : High Safety
ALTER DATABASE <DatabaseName>
SET SAFETY OFF
Hope you like this post and might be useful to you.

Friday, 8 May 2015

Configure Listener for high availability in SQL Server 2012 by serverku

A week ago I posted for high availability implementation in SQL Server 2012. I would like to read the earlier post and continue that post with and it’s configure a listener for availability group. So let us follow the steps.

Step 1 :  Connect primary server instance of availability group and go to AlwaysOn High Availability –> Availability Groups—> Availability Group Listeners –> Add Listener


Step 2 :  Assign Listener DNS Name, Port and Network Mode which should be DHCP or statistic IP.


Step 3 : We are done and now it ‘s time to connect and confirm SQL Server primary instance.


It should connect SQL Server primary instance, even a case of automatic or manual failover of instance involved in Availability Groups. So whenever a failover or primary server failure happened, we do not need to changed data source\connection string of application or wherever used. Hope you may like it.

Thursday, 7 May 2015

Implement High Availability in SQL Server - How to by serverku

A week ago I wrote for the replication, how to add articles in replication, how to add filtered articles in replication. Today I would like to write for high availability implementation in SQL server. It is the best option to replace other disaster plans like mirroring, replication and clustering based on need. So let us elaborate it with steps. We will go ahead with an example of SQL Server 2012 enterprise.

1.  Install and configure Windows Failover Cluster’. Go to Server Manager –>Features—>Add features.


2. Select ‘Failover Clustering’ from feature and add it.


3. After Windows Failover Cluster installed Create a Cluster. Go to Failover Cluster Manager –> Create Cluster.


4. Add Servers which need to participate in cluster.


5. Select an option to run validation tests for added servers.


6. Select an option either you wan to run all test or selected tests.


7. Specify a Cluster name and add IP address reserved for windows cluster name object.


8.  Open Failover Cluster Manager and confirm all server added in Nodes.


9. Install SQL Server SQL Server 2012 standalone in all servers and make sure ‘AlwaysOn Availability Groups’ enabled for SQL server instances.


10.  Here we will have a ‘Server1’ as a Primary, ‘Server2’ and ‘Server3’ act as a Secondary. So let us create a sample database in primary server.



11. Make sure the location of databases should be same to all secondary servers and databases have a full recovery model.

12.  Connect primary SQL server instance, go to AlwaysOn High Availability —> New Availability Group Wizard.


13. Specify a AG  name.


14.  Select databases which you would like to participate in AG. Make sure database full backup must be done, also it can be seen in status there.



15. Add ‘Server2’ and ‘Server3’ as a replica and set Server1 and Server2 for Automatic Failover. Make Readable setting for replicas as per need.


16.  Make sure 1433 (or whatever port of instances) and 5022 should be open in the firewall if the firewall is turned on.

17.  Set option of backup preferences and priority where you would like to perform it.


18.  Make one shared folder for full backup of databases which must be accessible to all secondary servers to restore it there.


19. Expand AlwaysOn High Availability—> Availability groups—>Availability Replicas where you can all participated servers in AG.


I will write next some more about it. Hope you enjoy AG. Have a nice day!

Thursday, 30 April 2015

How to manual failover mirroring without affecting replication - SQL Server by serverku

Before a couple of days we planned to manual failover of production servers and all live databases for that instance to mirror instance and did a failover too. It was a good experience for failover without fail anything like replication, scheduled jobs, linked servers, ssis packages, reports, windows tasks and whatever dependencies. Well perfect planning and team work was key for that succeed failover for us. This post is about to considering mirroring without witness server\automatic failover and transactional replication where the production database to act as a publisher and principal and the plan for same like following.

Planning
  • Configured mirror all production databases to mirror instance without witness server.
  • Created a dns alias for production server.
  • Used that alias as a data source to connect production sql server instance in linked servers, reports, ssis packages in all servers which pointing production instance and in application too .
  • Created all scheduled jobs with disable status in mirror instance.
  • Created all linked servers of production instance in mirror instance.
  • Created all logins of production instance in mirror instance.
  • Created all database mail profiles of production instance in mirror instance.
  • Created sql server agent operators of production instance in mirror instance.
  • Created windows scheduled tasks with disable status in mirror server.
All of above steps applied in advance with recent changes just before to start failover and need to change dns alias to mirror server, enable scheduled jobs and windows tasks during failover.

Problem 
But had a little bit confusing for replication, How to manually failover of mirroring without affecting replication? That was an issue. I have applied the solution and made it succeed. After manual failover, transactional replication started to raise an error and stopped working. Because it was trying to connect publisher database but it became a mirror after failover,

The process could not execute 'sp_replcmds' on '<original Publisher Server>'.

Workaround
There is one more step apart from listed above.
  • Add Failover Partner as a parameter (–PublisherFailoverPartner) in snapshot, log reader and queue reader agents.
How to add parameter?
I am sharing some screen shots which drive us for the explanation,
1. Go to Replication monitor and move to agent tab. Select agent from Agent types drop box, you will have list of agents, select it and click Agent Profiler from right click property.


2. Under Agent property, create a new user profile which will be created same as system profile, just need to add value <failover partner> of –PublisherFailoverPartner parameter.


3. Add –PublisherFailoverPartner parameter value for all agents like snapshot, log reader, queue reader agent and merge agent we have merge replication configured.


Note : After creating a new user agent profile check the box “Use for this agent”. I created a new agent profile because it does not allow to add –PublisherFailoverPartner parameter for system profile from the user interface. But we can add it with system procedures with tsql script.
USE distribution 
GO

-- For Snapshot Agent
EXEC sp_add_agent_parameter
@profile_id = 1,
@parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'<Failover Partner>'

-- For Log Reader Agent
EXEC sp_add_agent_parameter
@profile_id = 2,
@parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'<Failover Partner>'

-- For Distribution Agent
EXEC sp_add_agent_parameter
@profile_id = 3,
@parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'<Failover Partner>'

-- For Merge Agent
EXEC sp_add_agent_parameter
@profile_id = 4,
@parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'<Failover Partner>'

-- Queue Reader Agent
EXEC sp_add_agent_parameter
@profile_id = 9,
@parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'<Failover Partner>'
It has allowed to add this parameter for system profiles, but change the profile_id whatever system or user profile used for an agent which you will get it from sp_help_agent_profile system procedure from distribution database.

How to confirm?
By following script we can confirm the parameter values for such agents. Run this script in msdb database from distributor server.
USE msdb 
GO

SELECT a.profile_id,
a.profile_name,
a.description,
a.def_profile,
b.parameter_name,
b.value
FROM msagent_profiles a
INNER JOIN msagent_parameters b
ON ( a.profile_id = b.profile_id )
WHERE b.parameter_name = '-PublisherFailoverPartner'

(Click on image to enlarge)
Hope you enjoyed this case and might help you a lot. Did you face this issue or what is your solution? Something missing in failover plan? Please share your ideas and opinion about it. Your comments are most welcome!