Single Server (Replica) Availability Group
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}
up vote
6
down vote
favorite
First time caller, long time listener.
I have a situation where I need to stand up a single server Availability Group for around 2 months (i.e. move DBs to a new server, rebuild the current server, and add the rebuilt current server to the AG). Both servers are physical and have roughly the same specs. Windows Server 2016, SQL Server 2014.
My thought was to stand up the AG with the listener now so that when the current server is rebuilt and added to the group, we wouldn't need to add the listener then and update all of our apps/clients (i.e. that would force two migrations, one to the new server, one for the new listener).
I've tested this situation on a few test servers and its working as expected. I also can't foresee a reason not to do this, but I thought it would be worth the community ask since we're talking about Production DBs. My question is has anyone tried this and had any issues? Would anyone recommend against this solution. Thanks.
sql-server availability-groups
asked Nov 15 at 2:28
Select 'DBA'
334
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
6
down vote
favorite
First time caller, long time listener.
I have a situation where I need to stand up a single server Availability Group for around 2 months (i.e. move DBs to a new server, rebuild the current server, and add the rebuilt current server to the AG). Both servers are physical and have roughly the same specs. Windows Server 2016, SQL Server 2014.
My thought was to stand up the AG with the listener now so that when the current server is rebuilt and added to the group, we wouldn't need to add the listener then and update all of our apps/clients (i.e. that would force two migrations, one to the new server, one for the new listener).
I've tested this situation on a few test servers and its working as expected. I also can't foresee a reason not to do this, but I thought it would be worth the community ask since we're talking about Production DBs. My question is has anyone tried this and had any issues? Would anyone recommend against this solution. Thanks.
sql-server availability-groups
asked Nov 15 at 2:28
Select 'DBA'
334
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
6
down vote
favorite
up vote
6
down vote
favorite
First time caller, long time listener.
I have a situation where I need to stand up a single server Availability Group for around 2 months (i.e. move DBs to a new server, rebuild the current server, and add the rebuilt current server to the AG). Both servers are physical and have roughly the same specs. Windows Server 2016, SQL Server 2014.
My thought was to stand up the AG with the listener now so that when the current server is rebuilt and added to the group, we wouldn't need to add the listener then and update all of our apps/clients (i.e. that would force two migrations, one to the new server, one for the new listener).
I've tested this situation on a few test servers and its working as expected. I also can't foresee a reason not to do this, but I thought it would be worth the community ask since we're talking about Production DBs. My question is has anyone tried this and had any issues? Would anyone recommend against this solution. Thanks.
sql-server availability-groups
asked Nov 15 at 2:28
Select 'DBA'
334
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
First time caller, long time listener.
I have a situation where I need to stand up a single server Availability Group for around 2 months (i.e. move DBs to a new server, rebuild the current server, and add the rebuilt current server to the AG). Both servers are physical and have roughly the same specs. Windows Server 2016, SQL Server 2014.
My thought was to stand up the AG with the listener now so that when the current server is rebuilt and added to the group, we wouldn't need to add the listener then and update all of our apps/clients (i.e. that would force two migrations, one to the new server, one for the new listener).
I've tested this situation on a few test servers and its working as expected. I also can't foresee a reason not to do this, but I thought it would be worth the community ask since we're talking about Production DBs. My question is has anyone tried this and had any issues? Would anyone recommend against this solution. Thanks.
sql-server availability-groups
sql-server availability-groups
asked Nov 15 at 2:28
Select 'DBA'
334
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 15 at 2:28
Select 'DBA'
334
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 15 at 2:28
Select 'DBA'
334
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 15 at 2:28
Select 'DBA'
334
asked Nov 15 at 2:28
Select 'DBA'
334
334
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Select 'DBA' is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
7
down vote
accepted
First time caller, long time listener.
Ha! Love it! Welcome :)
I've tested this situation on a few test servers and its working as expected.
You are correct, it should work without many if any issues. Since clustering will now be part of the scenario you don't get a free single node lunch... you're still beholden to any cluster or AG level issues that may arise (I'm not saying they will, just that it's now in the issues list).
My question is has anyone tried this and had any issues?
I have, in fact, tried this. It does work, the 2-months part does give me a little bit of uneasiness... but assuming the configuration doesn't drift, you should be alright.
You can also pre-stage a listener by creating a DNS entry with the same name so connection strings don't change, use a network appliance or hardware load balancer, etc. The largest issue is enabling the Always On manager and the service restart required for it, in my opinion. All else (except the listener unless you do the DNS/HLB thing) should or can be transparent.
Would anyone recommend against this solution.
I only have the reservations of getting used to the single server performance characteristics and then adding in a synchronous replica or such afterwards. Since the single node AG won't have sync_commit waits and such, you really won't be in for much of a shock... though this could change once the other node is added. Just something to think about.
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
Sean, thank you for the detailed response. I've been using AGs for a number of years, and this answer touches on many important topics that everyone should consider. The staged DNS alias is a very good idea too.
– Select 'DBA'
Nov 16 at 13:41
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
accepted
First time caller, long time listener.
Ha! Love it! Welcome :)
I've tested this situation on a few test servers and its working as expected.
You are correct, it should work without many if any issues. Since clustering will now be part of the scenario you don't get a free single node lunch... you're still beholden to any cluster or AG level issues that may arise (I'm not saying they will, just that it's now in the issues list).
My question is has anyone tried this and had any issues?
I have, in fact, tried this. It does work, the 2-months part does give me a little bit of uneasiness... but assuming the configuration doesn't drift, you should be alright.
You can also pre-stage a listener by creating a DNS entry with the same name so connection strings don't change, use a network appliance or hardware load balancer, etc. The largest issue is enabling the Always On manager and the service restart required for it, in my opinion. All else (except the listener unless you do the DNS/HLB thing) should or can be transparent.
Would anyone recommend against this solution.
I only have the reservations of getting used to the single server performance characteristics and then adding in a synchronous replica or such afterwards. Since the single node AG won't have sync_commit waits and such, you really won't be in for much of a shock... though this could change once the other node is added. Just something to think about.
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
Sean, thank you for the detailed response. I've been using AGs for a number of years, and this answer touches on many important topics that everyone should consider. The staged DNS alias is a very good idea too.
– Select 'DBA'
Nov 16 at 13:41
add a comment |
up vote
7
down vote
accepted
First time caller, long time listener.
Ha! Love it! Welcome :)
I've tested this situation on a few test servers and its working as expected.
You are correct, it should work without many if any issues. Since clustering will now be part of the scenario you don't get a free single node lunch... you're still beholden to any cluster or AG level issues that may arise (I'm not saying they will, just that it's now in the issues list).
My question is has anyone tried this and had any issues?
I have, in fact, tried this. It does work, the 2-months part does give me a little bit of uneasiness... but assuming the configuration doesn't drift, you should be alright.
You can also pre-stage a listener by creating a DNS entry with the same name so connection strings don't change, use a network appliance or hardware load balancer, etc. The largest issue is enabling the Always On manager and the service restart required for it, in my opinion. All else (except the listener unless you do the DNS/HLB thing) should or can be transparent.
Would anyone recommend against this solution.
I only have the reservations of getting used to the single server performance characteristics and then adding in a synchronous replica or such afterwards. Since the single node AG won't have sync_commit waits and such, you really won't be in for much of a shock... though this could change once the other node is added. Just something to think about.
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
Sean, thank you for the detailed response. I've been using AGs for a number of years, and this answer touches on many important topics that everyone should consider. The staged DNS alias is a very good idea too.
– Select 'DBA'
Nov 16 at 13:41
add a comment |
up vote
7
down vote
accepted
up vote
7
down vote
accepted
First time caller, long time listener.
Ha! Love it! Welcome :)
I've tested this situation on a few test servers and its working as expected.
You are correct, it should work without many if any issues. Since clustering will now be part of the scenario you don't get a free single node lunch... you're still beholden to any cluster or AG level issues that may arise (I'm not saying they will, just that it's now in the issues list).
My question is has anyone tried this and had any issues?
I have, in fact, tried this. It does work, the 2-months part does give me a little bit of uneasiness... but assuming the configuration doesn't drift, you should be alright.
You can also pre-stage a listener by creating a DNS entry with the same name so connection strings don't change, use a network appliance or hardware load balancer, etc. The largest issue is enabling the Always On manager and the service restart required for it, in my opinion. All else (except the listener unless you do the DNS/HLB thing) should or can be transparent.
Would anyone recommend against this solution.
I only have the reservations of getting used to the single server performance characteristics and then adding in a synchronous replica or such afterwards. Since the single node AG won't have sync_commit waits and such, you really won't be in for much of a shock... though this could change once the other node is added. Just something to think about.
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
First time caller, long time listener.
Ha! Love it! Welcome :)
I've tested this situation on a few test servers and its working as expected.
You are correct, it should work without many if any issues. Since clustering will now be part of the scenario you don't get a free single node lunch... you're still beholden to any cluster or AG level issues that may arise (I'm not saying they will, just that it's now in the issues list).
My question is has anyone tried this and had any issues?
I have, in fact, tried this. It does work, the 2-months part does give me a little bit of uneasiness... but assuming the configuration doesn't drift, you should be alright.
You can also pre-stage a listener by creating a DNS entry with the same name so connection strings don't change, use a network appliance or hardware load balancer, etc. The largest issue is enabling the Always On manager and the service restart required for it, in my opinion. All else (except the listener unless you do the DNS/HLB thing) should or can be transparent.
Would anyone recommend against this solution.
I only have the reservations of getting used to the single server performance characteristics and then adding in a synchronous replica or such afterwards. Since the single node AG won't have sync_commit waits and such, you really won't be in for much of a shock... though this could change once the other node is added. Just something to think about.
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
answered Nov 15 at 2:47
Sean Gallardy
14.6k22346
14.6k22346
Sean, thank you for the detailed response. I've been using AGs for a number of years, and this answer touches on many important topics that everyone should consider. The staged DNS alias is a very good idea too.
– Select 'DBA'
Nov 16 at 13:41
add a comment |
Sean, thank you for the detailed response. I've been using AGs for a number of years, and this answer touches on many important topics that everyone should consider. The staged DNS alias is a very good idea too.
– Select 'DBA'
Nov 16 at 13:41
Sean, thank you for the detailed response. I've been using AGs for a number of years, and this answer touches on many important topics that everyone should consider. The staged DNS alias is a very good idea too.
– Select 'DBA'
Nov 16 at 13:41
Sean, thank you for the detailed response. I've been using AGs for a number of years, and this answer touches on many important topics that everyone should consider. The staged DNS alias is a very good idea too.
– Select 'DBA'
Nov 16 at 13:41
add a comment |
Select 'DBA' is a new contributor. Be nice, and check out our Code of Conduct.
Select 'DBA' is a new contributor. Be nice, and check out our Code of Conduct.
Select 'DBA' is a new contributor. Be nice, and check out our Code of Conduct.
Select 'DBA' is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f222591%2fsingle-server-replica-availability-group%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
