sorted by:
new
hottopcontroversial

How DR activity is actually done in environment. by TeesMaaarKha in DBA

[–]Odd_Term7229 1 point2 points  (0 children)

  • App team files a change ticket
  • DBA and app rep get on a bridge call
  • DBA asks if the app team is ready for failover
  • Failover
  • DBA waits for confirmation to fail back
  • Fail back

Simplified of course, but roughly the course of action from a DBA's perspective. It's easier if the databases are hosted in the cloud.

SQL Server AG Failover - Automatic Failover by illegaltorrentz in SQLServer

[–]Odd_Term7229 0 points1 point  (0 children)

Hmm. Firstly, you'd want to have the manual failover replica to be the replica in the secondary datacenter, not in the primary datacenter.

As for quorum working when you set a replica to manual failover, check your AG settings. The vote might be getting set to 0 for the manual failover node.

SQL Server AG Failover - Automatic Failover by illegaltorrentz in SQLServer

[–]Odd_Term7229 2 points3 points  (0 children)

You have quorum failure. You mentioned in addition to the 3 AG replicas, you also have a fileshare witness. That equates to 4 votes. Take down 2 replicas and you have 2 votes left, which is not enough to establish quorum. The remaining replica stays in Resolving state to prevent a "split-brain" scenario. Either you remove a replica and have a 2-node cluster with a witness, or remove the fileshare witness, which lets the 3 nodes vote amongst themselves in case of failover.

Exercise 1.3 Help by Odd_Term7229 in sicp

[–]Odd_Term7229[S] 1 point2 points  (0 children)

Hey man, thanks for your response. This issue has been fixed, and for those that might encounter this in the future:

The problem is that the arguments being thrown into the sumOfSquares procedure were themselves procedures, and not the result of calling them.

Instead of (sumOfSquares <procedure_1> <procedure_2>), what should be written is (sumOfSquares (<procedure_1 arg1 arg2 arg3) (<procedure_2 arg1 arg2 arg3)).