SQL 2012 :: Conditions Required For Automatic Failover On AlwaysOn?
Oct 27, 2015
An automatic failover set exists. This set consists of a primary replica and a secondary replica (the automatic failover target) that are both configured for synchronous-commit mode and set to AUTOMATIC failover.Configured the both AG Group database automatic failover and synchronous-commit mode.But automatic Failover failed also Cluster service not started automatically at Node2. It got connected through AO Listerner after starting Node1. As below SQL Error log during shutdown Node1
Date,Source,Severity,Message
10/27/2015 10:44:20,spid37s,Unknown,AlwaysOn Availability Groups: Waiting for local Windows Server Failover Clustering node to come online. This is an informational message only. No user action is required.
10/27/2015 10:44:20,spid37s,Unknown,AlwaysOn Availability Groups: Local Windows Server Failover Clustering node started.
I'm looking for a solution to have cross data center automatic failover in the event of a data center loss for highly critical databases. I would like to have local HA and also automatic failover to the DR site. This does not seem possible with AlwaysOn.
Is my only option for automatic cross data center failover to build a node in one data center and a node in the other data center with a node/FS at a third data center in order to maintain quorum? I'd like to have local HA in the mix but that doesn't seem possible.What pattern for the highest data security and also availability?
I have a 3 node 2014 AlwaysOn setup. The primary and secondary are set for automatic failover. The third node, of course, is manual (until 2016). The 2 nodes with are automatic are sitting in one datacenter, the third is in another. If the first datacenter was to go down, I would manually have to failover to the third node? What's the normal process here for having two datacenters and ensuring the availability group is always available?
Data synchronization and manual failover works fine. But, sometimes, the AlwaysOn cluster automatically fails over to Sync Commit Secondary on Primary data center. Here is the error message from Failover Cluster Manager->Cluster Events:
"Cluster has missed two consecutive heartbeats for the local endpoint xx.xx.xx.yy:~3343~ connected to remote endpoint xx.xx.xx.zz:~3343~"
"Cluster has lost the UDP connection from local endpoint xx.xx.xx.yy:~3343~ connected to remote endpoint xx.xx.xx.zz:~3343~"
I had our network engineer check all connections multiple times and he confirmed everything is fine. But he was also able to confirm (using monitoring tools) that right at the time of a failover, there is almost 2GB worth of traffic going from Primary Server to DR server. That happens every time. I had checked the times of all failovers and there is no job or process occuring that will produce 2GB worth of data. Also, this happens regardless of which server is primary.
Even though the failover works fine, this unexpected automatic failover due to missed heartbeats are occurring often (2-3 times a month).
Here is the list of errors from the Cluster Validation Report:
Under Network Section, I see the following error messages in Red:
Validate Network Communication
Network interfaces Server4 (DR) - SAN_Team and Server1 (Primary) - SAN_Team - VLAN 20 are on the same cluster network, yet address xx.xx.xx.pp is not reachable from xx.xx.xx.yy using UDP on port 3343.
Network interfaces Server4 (DR) - SAN_Team and Server2 (Secondary) - SAN_Team - VLAN 20 are on the same cluster network, yet address xx.xx.xx.qq is not reachable from xx.xx.xx.yy using UDP on port 3343.
If there is a history kept somewhere of failover events of a database in an AO group? I have 2 replicas with automatic failover and I'm looking for a history of failovers.
We are implementing a multi-site (Windows Server Failover Cluster) WSFC to enable Always On between our primary and DR site. We are not going to use SQL clustered instances. We are not planning to use shared disks. Each node is running a standalone instance of SQL 2012.
I have successfully configured a 3 node multi-site Windows failover cluster with no shared storage. For quorum, I have defined a File Share Witness (FSW). The FSW has voting rights and is in the DR site. The setup looks like this –
WSFC –
•Node A – Site #1 (voting right = 1) •Node B – Site #1 (voting right = 1) •Node C – Site #2 (voting right = 0) •FSW – Site #2 (voting right = 1)
Again - There are no shared disks in our setup. We are not going to use SQL clustered instance. We are going to use Always On with these 3 nodes.
SQL Always On –
•Node A – Site #1 (Primary Replica) •Node B – Site #1 (Readable Secondary) •Node C – Site #2 (Readable Secondary)
All the setup including the “availability group” works properly under this setup. However, a failover to site #2 under DR situation is not working and I know why but don’t know what needs to be done to fix the problem.
The following works fine –
•Automatic failover between nodes A and B (same site – site #1) •Forced failover to node C in site #2 provided at least one of the nodes in site #1 is up (non – DR situation) - this will ensure the cluster is up
The following is not working –
•Forced failover to node C in site #3 when both nodes in site #1 are lost (true DR situation) – This is because the cluster is not up at this point.
I know I have to bring the cluster up somehow and I have not been able to do so by restarting the cluster service.
I tried to run the command to start cluster service.
Question –
How can I FORCE the cluster to come up in Site #2 on node C when it has no voting rights?
I have always worked with even number of nodes and shared disks with traditional clustering. I am not sure what needs to be done in this scenario with 3 nodes and a FSW.
How can we find the cluster failover count in always on ?
As my AG is configured as synchronous mode , AG went offline and we manually restarted the AG service when we check the properties on AG role they r in default setting ?
What happens when an automatic failover occurs, in a two server AlwaysOn Availability Group configuration, where the secondary replica is configured as read-only?
Will it only allow read-only connections, or will it become read-write and can accept INSERT, UPDATES and DELETES when assigned the new role as Primary?
Is it correct that adding a third server/node, that just acts as passive and should be used for automatic failover, to support true HADR, would NOT need another license .. and that licenses would only be required for the previous Primary and Secondary (Read-Only) replicas?
1. Once fail over to secondary replica, what will happen to connected session in primary node? can the session fail over to secondary seamlessly or need to re-login. what happen committed transactions which has not write to disk. 2. Assume I have always on cluster with three nodes, if primary fails, how second node make write/ read mode. 3. after fail over done to 2nd secondary node what mode in production(readonly or read write). 4. how to rollback to production primary ,will change data in secondary will get updated in primary.
1. In alwaysON fail over cluster, Once fail over to secondary replica, what will happen to connected session in primary node? can the session fail over to secondary seamlessly or need to re-login. what happen committed transactions which has not write to disk.
2. Assume I have always on cluster with three nodes, if primary fails, how second node make write/ read mode.
3. After fail over done to 2nd secondary node what mode in production(readonly or read write).
4. How to rollback to production primary ,will change data in secondary will get updated in primary.
I am trying to do a select with the closest match.
Code Snippet
CREATE TABLE [#Person]
(
[PersonId] tinyint IDENTITY(1,1) NOT NULL
,[Height] char(2) NOT NULL
,[Weight] char(3) NOT NULL
,[Age] varchar(3) NOT NULL
,[HairColor] varchar(7) NOT NULL
,[EyeColor] varchar(7) NOT NULL
);
INSERT INTO [#Person] ([Height],[Weight],[Age],[HairColor],[EyeColor])
VALUES ('71', '150', '23', 'Brown', 'Blue');
INSERT INTO [#Person] ([Height],[Weight],[Age],[HairColor],[EyeColor])
VALUES ('70', '190', '22', 'Blonde', 'Brown');
INSERT INTO [#Person] ([Height],[Weight],[Age],[HairColor],[EyeColor])
VALUES ('69', '140', '20', 'Black', 'Brown');
INSERT INTO [#Person] ([Height],[Weight],[Age],[HairColor],[EyeColor])
VALUES ('65', '150', '21', 'Brown', 'Green');
SELECT * FROM [#Person]
WHERE
([Height] > '66' AND [Height] < '72')
AND ([Weight] > '150' OR [Weight] < '180')
AND ([Age] > '20' OR [Age] < '25')
AND ([HairColor] IN ('Brown', 'Blonde', 'Black'))
AND ([EyeColor] IN ('Blue', 'Brown', 'Green'));
DROP TABLE [#Person];
This simple example works great. But what if I wanted everybody who met 4 of the 5 conditions? I tried to think of a counting solutions, and then order by the count but I could quite get there. Any help would be greatly appreciated. My live data is actual sales records with 20 some odd record types. I am hoping any solutions I find will scale well.
Hi there, I am testing the db mirroring, making sure it will auto failover. I've stopped the SQL services on my principal and then I looked at the mirror db is says it's restoring. It stayed like that for 10 min before I enabled the mirroring again. Anyone knows why it's not failing over??????
Here's my setup: SQL 2005 Standard, Server 1 Principal, Server 2 Mirror & Witness.
We've recently set up a Principle, Mirror and Witness configuration with the Mirror and Witness in a separate building to the Principle. All three are part of the same domain (DMZ) and are different servers, the buildings are connected via a fiber optic cable. All servers and SQL Server instances are logged in with the same domain admin account DMZesAdmin.
Mirroring is all set-up and the databases are synchronized. Every once in a while some (not all, normally 6 out of 15) databases will switch roles and become active on the mirror. The SQL Server mirroring monitor job then reports:
Date 25/01/2007 12:37:01 Log Job History (Database Mirroring Monitor Job)
Step ID 1 Server DMZSQL01 Job Name Database Mirroring Monitor Job Step Name Duration 00:00:02 Sql Severity 16 Sql Message ID 32038 Operator Emailed Operator Net sent Operator Paged Retries Attempted 0
Message Executed as user: DMZesadmin. An internal error has occurred in the database mirroring monitor. [SQLSTATE 42000] (Error 32038). The step failed.
I have no idea, what causes the failover, it could be a slow network or a bad set-up, can anyone give me some ideas of what to do to track down the problem or any experience of what could be causing this, it happens randomly every day or three. No warning and if I go to the mirror and failover back to the principle again then it's all just fine. However I don't want half my databases working on 1 server and half on the other.
Any ideas?
Thanks Ed
UPDATE:
I've just been looking at the logs on my Mirror and at the same time it reports in this order
Error: 1479, Severity: 16, State: 1.
The mirroring connection to "TCP://DMZSQL01.dmz.local:5022" has timed out for database "WARCMedia" after 10 seconds without a response. Check the service and network connections.
Database mirroring is inactive for database 'WARCMedia'. This is an informational message only. No user action is required.
Recovery is writing a checkpoint in database 'WARCMedia' (41). This is an informational message only. No user action is required.
The mirrored database "WARCMedia" is changing roles from "PRINCIPAL" to "MIRROR" due to Failover.
Database mirroring is inactive for database 'WARCMedia'. This is an informational message only. No user action is required.
...
This looks like a time out, is there any way to set the TimeOut threashold for Database mirroring or set retry intervals??
3 servers - PRINCIPAL IP: 10.2.5.31 - DNS Lookup: db-server-2.mosside.choruscall.com - MIRROR IP: 10.2.5.30 - DNS Lookup: sql-mirror.mosside.choruscall.com - WITNESS ip: 10.2.5.32 - DNS Lookup: sql-witness.mosside.choruscall.com
Each Server is running Windows Server 2003 Enterprise Edition with SQL Server 2005 Enterprise Edition. All server instances are enabled for remote connections(By default they are not). All servers have the flag 1400 traceon and have been restarted. PORT 5022 is unrestricted on network.
The server instances are connecting via certificates. Each server has an endpoint for the certificates to to connect on.
Certificate Setup Proceedure:
Principal_Host:
1. Create Master Key with Password
2. Create certificate with subject
3. Create endpoint for certificate (Listener_Port = 5022, Listener_ip = all) to connect on for database_mirroring
4. Backup Certificate (principal_cert.cer)
5. Take backed up certificate to Mirror_Host
(Reapeat Steps 1-5 for Witness and Mirror)
Mirror_Host: Create Certificate on Mirror_Host for inbound connections from Principal:
6.(On Mirror_Host) Create Login for Principal using same password in step 1 (principal_login)
7. Create user for login just created. (principal_user)
8. Create local certificate for Principal on Mirror using certificate generated by principal.
ex: Create Certificate Principal_cert Authorization Principal_user FROM FILE='c:principal_cert.cer'
9. (If an endpoint has been created already on the mirror)Grant connectiion to the login:
ex: Grant connect on endpoint::mirror_endpoint to principal_login
Repeat Steaps 6-9 for Principal and Witness Servers accordingly.
10. Import Database to SQL Server 2005 Principal Instance
11. Backup Database to disk with format
12. Backup Database log file to disk with format
13. Copy backups to mirror
14. Restore Database and log file with norecovery on Mirror_Host
15. Configre Database for Database Mirroring on Principal Server
There are two ways to do this. Via the wizzard or via the Transact-SQL window. Using the wizzard appears to work since I started using FQDN.
PROBLEM:
After configuration, everythig appears to be correct. That is, the principal displays that it is the principal and it is synchronized with the mirror. The mirror also displays that it is the mirror and it is synchronized with the principal and it is in recovery. If I failover manually, the mirror becomes the principal and the principal becomes the mirror (They form a quarum). If I disconnect the principal from the network, the mirror is supposed to form a quarum with the witness and promote itself to principal status. This is not what is happening. The witness recognizes that the principal is down and logs that info into its log file. The Mirror attempts to contact the witness but cannot log onto the machine. The Mirror Logs the following:
Error: 1438, Severity: 16, State: 2. The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry.
<<<<<<<MIRROR SERVER >>>>>>>>
2007-09-06 15:08:45.32 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:08:45.32 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:09:05.32 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:09:05.32 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:09:25.33 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:09:25.33 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:09:45.34 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:09:45.34 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:10:05.35 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:10:05.35 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:10:25.36 spid23s Error: 1438, Severity: 16, State: 2.
<<<<<<< WITNESS SERVER >>>>>>>>
2007-09-06 14:19:55.90 spid52 The Database Mirroring protocol transport is now listening for connections. 2007-09-06 15:07:11.64 spid24s Error: 1479, Severity: 16, State: 1. 2007-09-06 15:07:11.64 spid24s The mirroring connection to "TCP://db-server-2:5022" has timed out for database "APS_SQL_DEV" after 10 seconds without a response. Check the service and network connections. 2007-09-06 15:07:43.20 Server Error: 1474, Severity: 16, State: 1. 2007-09-06 15:07:43.20 Server Database mirroring connection error 4 '64(The specified network name is no longer available.)' for 'TCP://db-server-2:5022'. 2007-09-06 15:08:06.03 spid9s Error: 1474, Severity: 16, State: 1. 2007-09-06 15:08:06.03 spid9s Database mirroring connection error 2 'Connection attempt failed with error: '10060(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)'.' for 'TCP://db-server-2:5022'.
we're running a mirrored database with High Availability for Automatic failover including a Witness instance for a web application.
When doing a manual failover on the database in Management studio, the roles are switched correctly and the database is in "Principal, Synchronized" and "Mirror, Synchronized/Restoring" mode. The web application has no problems switching servers by using client failover with the jdbc driver. There is no problem accessing the database with Management Studio.
However, if we stop the SQL service on the Principal server the role is automatically failed over to the Mirror server by the Witness. The database is then in the mode "Principal, Disconnected" which should be fine. However, accessing the database from the web application or with Management Studio yields some strange results. It is not possible to write to the database, and reading from the database works inconsistently (the web application seems like it can do it, but not from the Management Studio).
Starting the SQL service on the former Principal server makes the database go into mode "Mirror, Synchronizing/Restoring" and "Principal, Synchronizing". And it will stay that way indefinitely. There are not that many updates/transactions made to the database that can make it stay in this state, especially if you can't write to the database in the first place.
The next step taken after being stuck in this state is to stop the SQL service on the Mirror (former Principal), restart the service on the Principal (former Mirror). Accessing the database now works. The database is in mode "Principal, Disconnected". Starting the SQL service on the Mirror (former Principal) makes the database go into the normal "Principal, Synchronized" and "Mirror, Synchronized/Restoring" mode. Access to database is normal.
The same erroneous behaviour can be observed by unplugging the network cable on the Principal server, so it seems like we can only get a smooth transition by doing a manual failover.
Any ideas on what might be the problem? Has anybody experienced a similar situation?
I'd like to understand why it is not possible to automatic Failover Availability Groups using Failover Cluster Instances. I think it would be great for DR and HA. Do you understand why that limitation exists?
The link [URL] ....
SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.
I have setup a mirror configuration with a witness to be able to use the automatic failover. The principal is DBSP01, the mirror is DBSP02 and the witness is DBSP03. I have an application running an DBCP01. When the mirroring is working, the application can connect to the database on DBSP01. I disconnect dbsp01 from the network, so that DBSP02 becomes the principal. When I try to connect the application to the database on DBSP02, the login fails. Whithout the mirroring I was able to logon to DBSP02, but as soon as it is part of the mirroring, I'm not able to connect to it anymore, whatever the state of the database is. What could be the problem? Can anybody help?
I Config Ha-Alwayson on 2 test servers . In addition, was defined a listener for them.i can connect to them from the listener and in directly. I did manual Failover and it worked.However all connection to all servers (primary and secondary and listener) was breaked. I expected my connection To The listener, be stable. But How can I test the Auto failover mechanism? I run this scenario :
1- I filled all free space from the primary server else a bit. 2- And run on it a Huge Update to fill remain free space. 3- MeanWhile I Run an insert command into listener IP. (in a while Loop)
I expected :
>>> After run update or in middle of it , The primary server face to a problem. (Full Log file). And This was happened. >>> After I expected The Failover act and change Primary And Secondary.And My insert commands Continues without Break Or Continue On new server After some Seconds
But It didn't Happend.Both Of 2 Command are stoped !!!!! And auto failover didnt act. I tryed To create a manual fail on primary server . I Tried to Offline the main database in primary server.
Then
1- What is the meaning Of fail that Auto failover act about it ? 2- In which scenario I can Test It ?
In an sql authentication environment with an automatic failover in database mirroring how to you manage new logins which have been created on the principle since the start of mirroring? Since the master cannot be mirrored, and the mirror database cannot be read during mirroring (except as a snapshot) in order to find the missing logins, I assume that only after failover a script should run to create the new logins and then run sp_change_users_login . The qestions are:
1) should the script create a new login first and then run sp_change_users_login with option update_one , or should sp_change_users_login using option
Auto_Fix create the missing logins?
2) But what is the password of these users? is it initially NULL , as a consequence of sp_change_users_login? What about the SIDs?
3) Or should we bypass sp_change_users_login altogether and use
CREATE LOGIN <loginname> WITH PASSWORD = <password>, SID = <sid for same login on principal server>,...as described in http://blogs.msdn.com/chadboyd/archive/2007/01/05/login-failures-connecting-to-new-principal-after-failover-using-database-mirroring.aspx
4) What is the event that would trigger this script to run after the aitomatic failover ?
Is there a definitive MIcrosoft agreed apon and recommended method to tackle this?
we have to build high availability SQL 2012 cluster for VDI and we have two options. One option is to build a server cluster with combination of failover and mirroring and other option is to build failover cluster with AlwaysOn.We are not sure which option to chose. We have contacted Microsoft support to provide us some documents and instructions for failovermirroring combination but they have send us instructions for AlwaysOn option.
What would be best way to build high availability cluster for VDI? Also, since first option is very complicated.
I am a C++/C# developer my SQL skills are very limited. I have a database set up for mirroring and I would like to get an e-mail notification whenever an Automatic Failover occurs. Can anyone show me how to do this using SQLServer 2005? Please provide T-SQL script sample if possible!
I have setup a database mirroring session with witness - MachineA is the principal, MachineB is the mirror, and MachineC is the witness. Each SQL Server instance is hosted on its own machine. The mirroring is working correctly. If I submit data to the database on MachineA, and then unplug the network cable on MachineA, MachineB automatically becomes the principal, and I can see the data that I originally submitted to MachineA on MachineB. All the settings are showing correctly in Management Studio.
My issue is with the SQL Native Client and a front-end application that needs to make use of this database. I have setup my front-end application to use the ODBC client and specified the failover server in both the ODBC setup and the connection string. Here is the connection string that I am using :
Everything works perfectly on my front-end application when MachineA is the principal. If I unplug the network cable on MachineA, MachineB becomes the principal, and the failover occurs correctly on the database side. The problem is that my front-end application is not able to query the database on MachineB.
BUT - if I plug the network cable back in on MachineA (making the database on MachineA the mirror), the front-end application now works and can access the principal database on MachineB. I wrote a quick tester application to verify what I am seeing, and I am convinced that this is what is happening. The mirroring is working perfectly, and everything is setup correctly. The SQL Native Client is setup correctly. The problem is that the automatic failover to MachineB that is built into the SQL Native Client only works if both servers are plugged in.
In this scenario, when I plug both servers in, I know that the front-end app is definitely pulling from MachineB (since the mirror database on MachineA is in recovery mode, it's unavailable, and the front-end app displays the server that it is pulling data from).
Am I using an out-dated SQL Native Client? The version number displayed in the ODBC configuration page is 2005.90.2047.00, and is dated 4/14/2006. Has anyone experienced this issue? I'm guessing that it's a problem in the SQL Native client, since the mirroring really seems to be working correctly.
Is there any single TSQL query which provides below info.When did my AlwaysOn Availability group failed over and from which node it failed to which new node(i.e. replica)?
I'm getting an error adding Replica to SQL AlwaysOn failover cluster in the new availability group wizard. When I enter the name of the target node (secondary replica) server and press connect, I get the following:
A network-related or instance-specific error occurred while establishing a connection to SQL Server.
The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 2) The system cannot fine the file specified
The SQL Browser service is up and running on the target. I am using an Azure VM for my SQL instance. This cluster spans geographies from our on-premise site to Azure via a VPN. This is a multi-subnet cluster. I'm attempting to create a new AG from the primary replica node and the target is a node on Azure called SSASNodeAz03.
[URL]
Full error:
Connect to Server Cannot connect to ssasnodeaz03
Additional information: A network-related or instance-specific error occurred while establishing a connection to SQL Server.
The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 2) The system cannot fine the file specified
We had to failover our primary db server for maintenance to our secondary replica. The primary was rebooted during maintenance. We failed back after the maintenance and one of the databases is not synchronizing.
I checked sys.dm_hadr_database_replica_states, and it is showing that it is INITIALIZING.
It has been in this state for more than 45 mins now. The last_sent_time, last_received_time, last_hardened_time and last-redone_time are all stuck with a time stamp 45 mins ago.
They haven't changed. How do i resume this database and bring it back in sync?
I tried suspending and resuming the data movement, but hasn't worked.
I am running SQL 2014 2-node AlwaysON Availability groups, Enterprise Edition in our environment and 5 databases are part of AG.
Question is, sometimes AG is getting failed over to node2 but always our preferred node is node1 due to some business needs otherwise some of our jobs will fail.
So, what I looking for is, a sql script which can handle a situation wherein, for some reason, AG is failed over to node2, it should be able to detect if node1 is back online or not and if so, it should fail back to node1. How to do this using tsql query or stored proc or sql agent job ?
We have a requirement to build SQL environment which will give us local high availability and disaster recovery to second site. We have two sites- Site A & Site B. We are planning to have two nodes at Site A and 2 nodes at Site B. All four nodes will be part of same Windows failover cluster. We will build two SQL Cluster, InstanceA will be clustered between the nodes at Site A Server and InstanceB will be clustered between the nodes at Site B, we will enable Always On Between the InstanceA and InstanceB and will be primary owner where data will be written on InstanceA and will be replicated to InstaceB. URL....Now we want we will have instanceC on the Site B and data will be writen from the application available on Site B, will be replicated to the instance on the Site A as replica.
I'm looking at a setup where they have server1 and server2 in a mirroring relationship with automatic failover.
Server1 is the principalThey are using transactional replication to replicate asingle databse to server3 is AWS.Distribution database is on Server1All Agents (log reader, snapshot, distributor) run on Server1Server2 has not been set up for replication...My understanding is that in this set up you would normallly place the distribution database on a separate server and enable publication on the mirror, Server2.
What happens if they failover? Replication would stop, and presumably records added while the mirror is the active database would not be marked for replication?How would they recover? Failback and reinintialize
I need to use WHILE to avoid Cursor under certains conditions.
My SELECT statement is:
SELECT ref, ano, numberofyears ,nreint, naoreint,degress, tabela, tax, taxamaxima,[evactual], [evaldepact],[ereintact],nrregbt,[taxAmtAno] FROM deprec ORDER BY [ref] ASC
numberofyears= 100 /tax for exemple for a good where lifecycle is 4 years ,ex: Tax = 25% Then 100/25 = 4 years
I see this WHILE script, but i need to run :
1. for each REF + Until years < 4 in this exemple, because i have goods years depend on Percent.
the WHILE script i see is:
DECLARE @table1 TABLE (Id int not null primary key identity(1,1), col1 int ) INSERT into @table1 (col1) SELECT col1 FROM table2 SET @num_rows=@@ROWCOUNT
SET @cnt=0 WHILE @cnt<@num_rows
[Code] .....
My doubt is how to make the LOOP for each REF until Year < 4 (like my example)
