Automatic Seeding Error

In my lab, I decided to play around with the automatic seeding functionality that is part of Availability Groups. This was sparked by my last post about putting SSISDB into an AG. I wanted to see how it would work for a regular database. When I attempted to do so, I received the following error:

Automatic Seeding Error
Cannot alter the availability group ‘Group1’, because it does not exist or you do not have permission. (Microsoft SQL Server, Error: 15151)

This seemed odd to me. What would cause this error? What changed in my environment?

First, I realized that I did break down my AG and recreate it in management studio. When I created the group, I did not put any databases into the group, so I cold test automatic seeding.

Next, I decided to go through the process and instead of using the GUI, I scripted out the commands and would run manually. This way I could pinpoint where the process was failing.

--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE.
:Connect sql2016n1

USE [master]

GO

ALTER AVAILABILITY GROUP [Group1]
MODIFY REPLICA ON N'SQL2016N2' WITH (SEEDING_MODE = AUTOMATIC)

GO

USE [master]

GO

ALTER AVAILABILITY GROUP [Group1]
ADD DATABASE [WWI_Preparation];

GO

:Connect sql2016n2

ALTER AVAILABILITY GROUP [Group1] GRANT CREATE ANY DATABASE;

GO

When I ran the above code, the steps that were to run on SQL2016N1, succeeded, but those that were to run on SQL2016N2, failed. Additionally, I received the below message:

Msg 15151, Level 16, State 1, Line 24
Cannot alter the availability group ‘Group1’, because it does not exist or you do not have permission.

I went and looked at the AlwaysOn High Availability folder in SSMS on SQL2016n2 and found nothing.

2017-05-15_17-07-58

So, the group cannot be given permissions to create any database, because the group did not exist. Then it dawned on me as to why.

Creating an availability group, without databases using the GUI, only creates the group on the primary. It does not reach out to the secondary replicas to join those nodes to the group. This must be done manually. So to resolve the error, I had to run this code on SQL2016N2:


USE [master]
GO
ALTER AVAILABILITY GROUP Group1 JOIN
GO

This allowed the secondary replica to join the AG that was established on SQL2016N1. Then I was able to proceed with the next step of running


USE [master]
GO
ALTER AVAILABILITY GROUP [Group1] GRANT CREATE ANY DATABASE;
GO

Once this was completed, the database started seeding from one node to the other.

I think the biggest takeaway from this is the importance of using a script to do DBA actions instead of the GUI. It allows for a more focused and deliberate execution, where you can see things happen in order. This, in turn, teaches you and allows for greater flexibility, when things go bump.

Enabling AlwaysOn for SSISDB

I am at client where I get to do some fun work. I get to work on a brand new environment that is dedicated to SQL Server. It has some pretty cool specs. Biggest thing is that they are going all 2016. Both the OS and SQL Server will be 2016. This has let to a lot of fun and interesting discussions. One of those being how do we place the SSIS Catalog into an availability group.

This led me to ponder the possibilities. When AlwaysOn first came out, this was not supported. Sure, you could find clever work-arounds for this, but at the end of the day, they were not sanctioned by Microsoft. This would then leave the client in a bit of a bind if they ran into issues. However, starting in SQL Server 2016, this is now supported. Microsoft has made it possible to officially place the SSISDB into an availability group.

Which group you put the SSISDB in, will be a design question that you will need to answer for yourself. In short, it should go into a group that makes sense. If all your databases are in one group, then placing this in DB into the same group makes sense. If you have multiple groups, you may need to make a choice that best suits your application needs.

In this example, I will assume you already have an availability group set up with a listener. In my lab, I have a very simple setup. my availability group is called Group1 and my listener is called Listener1.

This video shows the steps I took to add the SSISDB into an availability group. I even show publishing a SSIS package to the listener name instead of a SQL Server Name.

In case you do not want to watch the video, below is the process I did to add the SSISDB into the availability group.

  1. On the Primary Replica, open SQL Server Management Studio
  2. Right click on Integration Services Catalog, click Create Catalog
    img1
  3. On the Create Catalog Dialog,
    img2
    Check the box to enable automatic execution of Integration Services stored procedures at SQL Server startup. Then enter a strong password.
  4. Open the Availability Group folder and navigate to the group you want to add the SSISDB to. Right click on Availability Database and click Add Database.
    img3
  5. Due to the encryption that the SSISDB uses, you will need to provide the password you used when creating the catalog. Put that password into the password field, click refresh and then click the check box next to SSISDB. Click Next
    img4
  6. On the Add Database to Availability Group dialog, ensure that Automatic Seeding is selected. Click Next.
    img5
  7. You will be presented with a list of the secondary replicas, connect to each one listed. Then click Next
    img6
  8. The information will be validated. As long as there are no failures, click Next.
    img7
  9. On the summary dialog, click Finish. SSMS will add the database to the availability group
    img8
  10. Click Close
    img9
  11. Once the database has been added to the availability group, go to the Integration Services Catalog folder, right click and click Enable AlwaysOn Support. (you may need to refresh this folder before the option is available to you)
    img10
  12. Click connect next to each secondary replica. Then click OK.
    img11

The SSISDB is now established in an availability group and will failover based on the group rules.