Can scheduled and continous replication configurations exist side-by-side on the same master/slave servers?
Environment
We have a core sql server cluster. This cluster contains some databases that get replicated to a load-balanced sql cluster of currently 3 servers. These databases are replicated each 12 hours but will eventually be replicated every 4 hours.
Requirement
On this cluster a new database is created and we need this database to be replicated asap to the load-balanced sql cluster. A delay of seconds or minutes is allowed and writes to this database are currently and in the future low (a few per hour).
Questions
Can two different replication plans coexist side-by-side on the same environment?
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Does this create a high risk for a large existing scheduled replication job?
Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
My brainwaves
I can't imagine that this minor write activity with continuous transaction replication can create issues for the large existing replication job. I can imagine the other way around that our continuous replication will suffer twice a day due to the large replication job. We are perfectly fine with that as replication is required ASAP during regular operation.
sql-server replication transactional-replication
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
Environment
We have a core sql server cluster. This cluster contains some databases that get replicated to a load-balanced sql cluster of currently 3 servers. These databases are replicated each 12 hours but will eventually be replicated every 4 hours.
Requirement
On this cluster a new database is created and we need this database to be replicated asap to the load-balanced sql cluster. A delay of seconds or minutes is allowed and writes to this database are currently and in the future low (a few per hour).
Questions
Can two different replication plans coexist side-by-side on the same environment?
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Does this create a high risk for a large existing scheduled replication job?
Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
My brainwaves
I can't imagine that this minor write activity with continuous transaction replication can create issues for the large existing replication job. I can imagine the other way around that our continuous replication will suffer twice a day due to the large replication job. We are perfectly fine with that as replication is required ASAP during regular operation.
sql-server replication transactional-replication
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
Environment
We have a core sql server cluster. This cluster contains some databases that get replicated to a load-balanced sql cluster of currently 3 servers. These databases are replicated each 12 hours but will eventually be replicated every 4 hours.
Requirement
On this cluster a new database is created and we need this database to be replicated asap to the load-balanced sql cluster. A delay of seconds or minutes is allowed and writes to this database are currently and in the future low (a few per hour).
Questions
Can two different replication plans coexist side-by-side on the same environment?
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Does this create a high risk for a large existing scheduled replication job?
Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
My brainwaves
I can't imagine that this minor write activity with continuous transaction replication can create issues for the large existing replication job. I can imagine the other way around that our continuous replication will suffer twice a day due to the large replication job. We are perfectly fine with that as replication is required ASAP during regular operation.
sql-server replication transactional-replication
Environment
We have a core sql server cluster. This cluster contains some databases that get replicated to a load-balanced sql cluster of currently 3 servers. These databases are replicated each 12 hours but will eventually be replicated every 4 hours.
Requirement
On this cluster a new database is created and we need this database to be replicated asap to the load-balanced sql cluster. A delay of seconds or minutes is allowed and writes to this database are currently and in the future low (a few per hour).
Questions
Can two different replication plans coexist side-by-side on the same environment?
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Does this create a high risk for a large existing scheduled replication job?
Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
My brainwaves
I can't imagine that this minor write activity with continuous transaction replication can create issues for the large existing replication job. I can imagine the other way around that our continuous replication will suffer twice a day due to the large replication job. We are perfectly fine with that as replication is required ASAP during regular operation.
sql-server replication transactional-replication
sql-server replication transactional-replication
asked Aug 22 '13 at 15:37
Ramon SmitsRamon Smits
1062
1062
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Can two different replication plans coexist side-by-side on the same environment?
Yes, you can create many publishers for the same articles that replicates to different subscribers.
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Yes, if you are replicating a new database or subset of data to other server, it should be fine.
You need to think about if the distributor server is same on the publisher server or you are having a different distribution server.
When distributor and publishers share the same server instance, then it is highly likely that you will hit a performance bottleneck, depending on how much data you are replicating (all data vs subset of data) and your network latency between your publisher databases and subscriber databases.
Does this create a high risk for a large existing scheduled replication job? Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
As I mentioned in above answer, it depends on how much data you are replicating and the amount of transactions happening on publisher database. Better to follow your DBA recommendations if he/she has proper stats or baseline that will show the current behavior.
I think the distributer is running on the publisher as I've never heard something like it in our production network. Replication is a performance hit but we want to use it to make our public web infrastructure highly available. It isn't that a lot of writes are done on this database. As I said we are talking about a few writes each hour.
– Ramon Smits
Aug 23 '13 at 6:43
We as in (dev/devops) do not have any rights to do anything on the production databases so we have to follow dba but in this case I cannot imagine that continuous transactional replication would create such a performance hit on our system. Our dba says that when this replication job would fail that the other scheduled replication job would fail as well. That doesn't make any sense to me.
– Ramon Smits
Aug 23 '13 at 6:49
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2f48545%2fcan-scheduled-and-continous-replication-configurations-exist-side-by-side-on-the%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Can two different replication plans coexist side-by-side on the same environment?
Yes, you can create many publishers for the same articles that replicates to different subscribers.
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Yes, if you are replicating a new database or subset of data to other server, it should be fine.
You need to think about if the distributor server is same on the publisher server or you are having a different distribution server.
When distributor and publishers share the same server instance, then it is highly likely that you will hit a performance bottleneck, depending on how much data you are replicating (all data vs subset of data) and your network latency between your publisher databases and subscriber databases.
Does this create a high risk for a large existing scheduled replication job? Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
As I mentioned in above answer, it depends on how much data you are replicating and the amount of transactions happening on publisher database. Better to follow your DBA recommendations if he/she has proper stats or baseline that will show the current behavior.
I think the distributer is running on the publisher as I've never heard something like it in our production network. Replication is a performance hit but we want to use it to make our public web infrastructure highly available. It isn't that a lot of writes are done on this database. As I said we are talking about a few writes each hour.
– Ramon Smits
Aug 23 '13 at 6:43
We as in (dev/devops) do not have any rights to do anything on the production databases so we have to follow dba but in this case I cannot imagine that continuous transactional replication would create such a performance hit on our system. Our dba says that when this replication job would fail that the other scheduled replication job would fail as well. That doesn't make any sense to me.
– Ramon Smits
Aug 23 '13 at 6:49
add a comment |
Can two different replication plans coexist side-by-side on the same environment?
Yes, you can create many publishers for the same articles that replicates to different subscribers.
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Yes, if you are replicating a new database or subset of data to other server, it should be fine.
You need to think about if the distributor server is same on the publisher server or you are having a different distribution server.
When distributor and publishers share the same server instance, then it is highly likely that you will hit a performance bottleneck, depending on how much data you are replicating (all data vs subset of data) and your network latency between your publisher databases and subscriber databases.
Does this create a high risk for a large existing scheduled replication job? Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
As I mentioned in above answer, it depends on how much data you are replicating and the amount of transactions happening on publisher database. Better to follow your DBA recommendations if he/she has proper stats or baseline that will show the current behavior.
I think the distributer is running on the publisher as I've never heard something like it in our production network. Replication is a performance hit but we want to use it to make our public web infrastructure highly available. It isn't that a lot of writes are done on this database. As I said we are talking about a few writes each hour.
– Ramon Smits
Aug 23 '13 at 6:43
We as in (dev/devops) do not have any rights to do anything on the production databases so we have to follow dba but in this case I cannot imagine that continuous transactional replication would create such a performance hit on our system. Our dba says that when this replication job would fail that the other scheduled replication job would fail as well. That doesn't make any sense to me.
– Ramon Smits
Aug 23 '13 at 6:49
add a comment |
Can two different replication plans coexist side-by-side on the same environment?
Yes, you can create many publishers for the same articles that replicates to different subscribers.
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Yes, if you are replicating a new database or subset of data to other server, it should be fine.
You need to think about if the distributor server is same on the publisher server or you are having a different distribution server.
When distributor and publishers share the same server instance, then it is highly likely that you will hit a performance bottleneck, depending on how much data you are replicating (all data vs subset of data) and your network latency between your publisher databases and subscriber databases.
Does this create a high risk for a large existing scheduled replication job? Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
As I mentioned in above answer, it depends on how much data you are replicating and the amount of transactions happening on publisher database. Better to follow your DBA recommendations if he/she has proper stats or baseline that will show the current behavior.
Can two different replication plans coexist side-by-side on the same environment?
Yes, you can create many publishers for the same articles that replicates to different subscribers.
Is it possible to setup a second replication routine for this scenario (continuous transaction replication) besides the current replication schema for the existing databases?
Yes, if you are replicating a new database or subset of data to other server, it should be fine.
You need to think about if the distributor server is same on the publisher server or you are having a different distribution server.
When distributor and publishers share the same server instance, then it is highly likely that you will hit a performance bottleneck, depending on how much data you are replicating (all data vs subset of data) and your network latency between your publisher databases and subscriber databases.
Does this create a high risk for a large existing scheduled replication job? Our DBA says that this replication scenario creates a high risk for the existing replication configuration (2x a day).
As I mentioned in above answer, it depends on how much data you are replicating and the amount of transactions happening on publisher database. Better to follow your DBA recommendations if he/she has proper stats or baseline that will show the current behavior.
answered Aug 22 '13 at 16:10
KinKin
53.7k481190
53.7k481190
I think the distributer is running on the publisher as I've never heard something like it in our production network. Replication is a performance hit but we want to use it to make our public web infrastructure highly available. It isn't that a lot of writes are done on this database. As I said we are talking about a few writes each hour.
– Ramon Smits
Aug 23 '13 at 6:43
We as in (dev/devops) do not have any rights to do anything on the production databases so we have to follow dba but in this case I cannot imagine that continuous transactional replication would create such a performance hit on our system. Our dba says that when this replication job would fail that the other scheduled replication job would fail as well. That doesn't make any sense to me.
– Ramon Smits
Aug 23 '13 at 6:49
add a comment |
I think the distributer is running on the publisher as I've never heard something like it in our production network. Replication is a performance hit but we want to use it to make our public web infrastructure highly available. It isn't that a lot of writes are done on this database. As I said we are talking about a few writes each hour.
– Ramon Smits
Aug 23 '13 at 6:43
We as in (dev/devops) do not have any rights to do anything on the production databases so we have to follow dba but in this case I cannot imagine that continuous transactional replication would create such a performance hit on our system. Our dba says that when this replication job would fail that the other scheduled replication job would fail as well. That doesn't make any sense to me.
– Ramon Smits
Aug 23 '13 at 6:49
I think the distributer is running on the publisher as I've never heard something like it in our production network. Replication is a performance hit but we want to use it to make our public web infrastructure highly available. It isn't that a lot of writes are done on this database. As I said we are talking about a few writes each hour.
– Ramon Smits
Aug 23 '13 at 6:43
I think the distributer is running on the publisher as I've never heard something like it in our production network. Replication is a performance hit but we want to use it to make our public web infrastructure highly available. It isn't that a lot of writes are done on this database. As I said we are talking about a few writes each hour.
– Ramon Smits
Aug 23 '13 at 6:43
We as in (dev/devops) do not have any rights to do anything on the production databases so we have to follow dba but in this case I cannot imagine that continuous transactional replication would create such a performance hit on our system. Our dba says that when this replication job would fail that the other scheduled replication job would fail as well. That doesn't make any sense to me.
– Ramon Smits
Aug 23 '13 at 6:49
We as in (dev/devops) do not have any rights to do anything on the production databases so we have to follow dba but in this case I cannot imagine that continuous transactional replication would create such a performance hit on our system. Our dba says that when this replication job would fail that the other scheduled replication job would fail as well. That doesn't make any sense to me.
– Ramon Smits
Aug 23 '13 at 6:49
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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%2f48545%2fcan-scheduled-and-continous-replication-configurations-exist-side-by-side-on-the%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