I'll try to be as clear and concise as possible. I really hope someone can help me I have wasted a lot of time with this because I am not into infrastructure stuff.
Goal: Configure AlwaysOn with two SQL Server instances, connect to the database through an Availability Group Listener.
Error:
Current config:
I have two separate VMs managed with Hyper-V, in the same server.
Both are in the same subnet.
Both have Windows 2012 R2 and SQL Server 2014 SP2 installed.
The feature for failover clusters is enabled in both servers.
I have created a cluster with the two nodes and one cluster network.
I have created an Availability Group in SQL Server
I have added both SQL Server Instances to the Availability Group
The same domain user is an admin in both VMs.
Firewall has been disabled in both VMs.
...but when I try to add the Availability Group Listener I get the SQL Server error 19458.
What I tried:
I have seen that many people talk about having the same Collation in both servers: SQL_Latin1_General_CP1_CI_AS
Availability Group Listener - Targeting Incorrect Node
The secondary node had been setup with a different collation. So, I uninstalled the instance and installed it again with the correct collation. I reconfigured the nodes and the availability replicas and I still keep getting the same error.
Then I tried with the Static IP option, but I get a different error:
I also read somewhere that it might work if I create the listener before the secondary replica. I did that but then the secondary replica can't be added because of the same error.
It doesn't work by granting the Object Creation permission in AD as stated here Failed to create Availability Group Listener
Maybe useful: The synchronization works as expected between the two VMs.
Thank you very much.
To create the AG Listener before configure it via SSMS we ask to the network team to create a DNS name linked to a static IP then we use it to create the AG Listener (don't forget to specify Static IP when creating AG Listener)
Related
I am unable to connect my RDS SQL Server instance from my AWS EC2 instance.
I have installed SQL Server Management Studio on my AWS EC2 Windows Server 2019 instance.
I am neither able to ping my RDS endpoint from that machine nor able to connect using SSMS. In the security group inbound rules for RDS I have entered IP of my EC2 instance under all traffic option, also tried using SQL Server option in security inbound rules.
There's two key questions that are relevant here: 1) is the connectivity allowed in AWS, and 2) is the connectivity allowed by the host/applications on the individual instances.
For 1, you need visibility into the networking aspect of your cloud. I use Batfish's virtual traceroute in your environment. There's an free and open source project (https://batfish.org) or you can try a free trial of the enterprise offering (https://www.intentionet.com/trial).
After you validate that the traffic is allowed in AWS (no Network ACLs or security groups are misconfigured, vpc peerings / routing tables are correct, etc.) you should move on to verifying application config on the actual hosts.
(Disclaimer: I work on Batfish and Batfish Enterprise).
What you need to do is:
The security group that you have attached to the RDS instance you need to add a rule for the inbound section of the security group to be SQL Server and have the source of that rule be the same name as the security group, this is called a self referencing security group rule. Then go to the EC2 instance and attach that same security group to the instance. This will solve the Security Group potential problem.
The other piece you need to check is if the EC2 instance is in a different subnet than the RDS SQL Server you need to make sure the Network Access Control List (NACL) will allow the inbound/outbound traffic of SQL between the subnets.
I'm trying to solve a mystery. We have two SQL Server instances residing on the same server. SQL instance A is linked to SQL instance B. Connections are made using pass through authentication. The calling service is on a different server. No settings were put in place for Kerberos delegation, no SPN, no trust for delegation, etc. However, we weren't getting authentication failures when running distributed queries through the linked server connection. This makes no sense to me unless having the two instances on a single server results in a single hop scenario (from calling client service to server on which both instances reside). The underlying Kerberos config is now in place, so Kerberos is being used successfully, I'm just trying to understand how the connection would have worked before I made the necessary changes. Does anyone have any insight into this? Thanks.
The number of 'hops' is given by the number of distinct 'Local Security Authority' involved. When you had two SQL Server instances on the same machine there was only one LSA involved, so no delegation was required.
We're trying to deploy a DACPAC to a new server via MS Release Management Studio. We've successfully deployed to other new servers with the same DACPAC with an existing restored database prior to data-tier upgrade. Proving that the DACPAC and deployment process is working.
The only difference is this server has Always On Availability Groups (AOAG) and the target we are deploying to is the group listener. Following the advice from here:
You have to deploy it to the Listener, which will in fact redirect your connection to the primary replica of your AlwaysOn Availability Group.
The changes will also be transferred to the secondary replicas.
The listener enables a client to connect to an availability replica without knowing the name of the physical instance of SQL Server to which the client is connecting.
So normally you can use this listener name in the Release Management Studio like another SQL Server Instance.
Having tried to manually upgrading the data-tier application using the listener it states that the target server is not accessible.
Does anyone have a process for this or has had some experience they can share as to why this is happening and what I can do to get past it?
UPDATE (resolved):
It looks as though our server was patched which caused a failover to occur. The secondary replica didn't have an account setup for our Release Management Studio user.
Also, our DBA finally chipped in with our replica's being set to read-only.
Consequently, we had made some discoveries, such as DACPAC's will upgrade a database to a data-tier application even if they are not registered.
And although you can deploy a DACPAC to your primary replica as a DAC, the secondary's won't be registered as DAC's unless you manually upgrade / register them. Useful to know.
Thanks to all those that asked questions :)
It looks as though our server was patched which caused a failover to occur. The secondary replica didn't have an account setup for our Release Management Studio user.
Also, our DBA finally chipped in with our replica's being set to read-only.
Consequently, we had made some discoveries, such as DACPAC's will upgrade a database to a data-tier application even if they are not registered.
And although you can deploy a DACPAC to your primary replica as a DAC, the secondary's won't be registered as DAC's unless you manually upgrade / register them. Useful to know.
Thanks to all those that asked questions :)
This also happens becasue your database recovery setting will be simple. In Availability group or mirroring case it should be full
I have a number of database on premises that use change tracking to enable 2-way synchronisation with remote disconnected clients; the idea being when the clients connect online they sync their changes and pull down all others.
I need to move the database to an instance on a virtualised server in Azure (note: not Azure SQLDB) but every option - backup/restore, bacpac, etc - seems to reset that version number that SQL Server uses for Change Tracking.
Does anyone know of a way of moving a SQL Server 2012 database to another instance and retaining the Version Number and existing change tracking info?
Thanks
If I only have one VM in Azure I can get outtages at any time when Azure decides to reboot/reprovision my server. Therefor I have to at least two servers in an availability group to get a stable environment.
This is used by a web app (web roles) and an important aspect is that the databases are used for reading. They will get their data from sql replication from an on-premises database. The replication can be done separately to each database. Additionally using Azure Sql Database is not an option because we have not be able to implement a durable data sync solution (using Microsoft Sync Framework), Sql Database does not support sql replication, and constantly uploading the complete database would be too slow.
How should the database VMs be hosted and accessed to able to use Sql Server VMs?
One alternative is to use AlwaysOn Availability Groups. This however requires Sql Server Enterprise edition and the price is very high considering I need to have at least two servers. In this scenario I at least get one connection point behind which a sql server always should be answering. This is however beyond our reach because of the cost.
One alternative could be to use Traffic manager to round robin the connections. When the database server goes down we have to wait for TTL to expire before the webrole would refresh the ip address so that seems a big problem.
How should one host Sql Server VMs in Azure?
You can use FailoverPartner parameter in the connection string to specify the secondary replica address. You can see more in this article.