March 25, 2015 at 12:05 am
Comments posted to this topic are about the item Stairway to Always On Level 6: Analyse and Deploy an Always On Availability Group
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 25, 2015 at 6:45 am
Hi - Perry
Do you have documentation for backups on AlwaysOn 2012 database server.
March 25, 2015 at 9:21 am
I have not covered backups in detail as there will be varying preferences involved. I may do something post the stairway series.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 25, 2015 at 10:47 am
can you point me to any online resource in meantime...
March 25, 2015 at 3:44 pm
Are there prerequisites to location of the failover cluster nodes in AD? I have seen cases where I need to move all nodes and cluster objects to COMPUTER OU for the wizard to work. Have you seen this happen?
March 25, 2015 at 7:35 pm
No, I have not seen that situation
March 26, 2015 at 5:49 am
prince_william (3/25/2015)
Are there prerequisites to location of the failover cluster nodes in AD? I have seen cases where I need to move all nodes and cluster objects to COMPUTER OU for the wizard to work. Have you seen this happen?
have your domain admin pre stage the computer accounts in the chosen OU and ensure permissions are applied, you should not have any issues afterwards
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 26, 2015 at 5:51 am
yusufkothari (3/25/2015)
can you point me to any online resource in meantime...
Not at this present time, there are numerous scripts available
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 3, 2015 at 8:36 am
Hey Perry,
Any general recommendations on network latency vs synchronous/asychronous AOAGs? e.g. if the link between two dbs has a network latency of 10 ms, is that too long for sync? How about 100 ms, 1 sec, etc.?
I know the answer could be "it depends", but I'm hoping some ball park estimates as guidelines. So far I've failed in my search for such in Microsoft docs.
Gerald Britton, Pluralsight courses
April 22, 2016 at 9:39 am
Hi Perry, thanks for article, most useful.
I have just configured our first multi subnet AG and have a couple of questions. I note on the listener tab you have specified port 5023, is this because that's a port used in mirroring, would you not use the same port the SQL service is running under? Does it matter?
As I have multi subnets (two) I have two IP addresses for the listener resource in the cluster, the primary online and the replica showing as offline, would you expect the replica to be offline?
---------------------------------------------------------------------
April 26, 2016 at 3:26 pm
george sibbald (4/22/2016)
As I have multi subnets (two) I have two IP addresses for the listener resource in the cluster, the primary online and the replica showing as offline, would you expect the replica to be offline?
to answer my own question, yes this is correct, for the replicas the listener shows as offline within failover cluster manager
---------------------------------------------------------------------
June 22, 2016 at 11:20 am
Perry Whittle (3/25/2015)
I have not covered backups in detail as there will be varying preferences involved. I may do something post the stairway series.
Quick question on the backups... Does Always On take its own backups? Or does it rely on the backups I am setting up through other means?
I'm worried about chain breakage and whether or not the recovery/backup solution I am designing will be interfered with by Always On, or if I can just point it to my pre-existing backup location and have it use those backups.
Following that thought... I can't seem to find much information on what the Always On backup types actually mean. The way your article phrases it, it sounds as if Always On will be doing its own backups. So if I choose Prefer Secondary, the secondary instance will be getting its databases backed up but the primary instance won't, which if I have these two in Asynch mode, might miss some data in case of failure. Could you clarify?
June 22, 2016 at 11:24 am
And now a question about the Listener... I need an IP address and a Network name, I'm assuming this is a DNS record of A Name type? Or do I need to get a C Name record for the network name?
If I'm reading this correctly, an AG with 3 secondary replicas only needs 1 IP / Network name, not an IP for each replica... Yes / No / Maybe?
EDIT: Except looking at George's comments, maybe I need two IPs / Network names? I have a 4 node cluster, two nodes on Data Center A and two nodes on Data Center B. DC-A will have synchronous replicas between them and then both asynch to DC-B. Both DCs are on different subnets.
I just want to be sure I understand this before I order these items from our DNS admin.
BTW, beautifully written articles, Perry. Very detailed.
June 22, 2016 at 11:47 am
Another question. Does Always On require a quorum drive?
Windows 2012 (clustered) can do with or without a quorum drive. But you mention quorum in your article so much, I wanted to verify whether or not you knew if it was a requirement of AG.
June 23, 2016 at 3:37 am
Brandie Tarvin (6/22/2016)
Perry Whittle (3/25/2015)
I have not covered backups in detail as there will be varying preferences involved. I may do something post the stairway series.
Quick question on the backups... Does Always On take its own backups? Or does it rely on the backups I am setting up through other means?
no, AG does not take its own backups, you have to set those up in whatever is the normal way for you. If you will be using a listener and have automatic failover you may have to automate checking which node is performing your backups and enable\disable backup jobs. We use Olla's scripts on our AGs which recognise the role the node is playing and acts accordingly, which is very nice.
if I choose Prefer Secondary, the secondary instance will be getting its databases backed up but the primary instance won't, which if I have these two in Asynch mode, might miss some data in case of failure. Could you clarify?
Like any backup it will consistent at the point it was taken on the replica, so there will be no more data loss
---------------------------------------------------------------------
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply