Can scheduled and continous replication configurations exist side-by-side on the same master/slave...
Given the mapping a = 1, b = 2, ... z = 26, and an encoded message, count the number of ways it can be decoded
Was Opportunity's last message to Earth "My battery is low and it's getting dark"?
Why Doesn't It Completely Uninstall?
Can I legally make a website about boycotting a certain company?
How do I avoid the "chosen hero" feeling?
Can you wish for more wishes from an Efreeti bound to service via an Efreeti Bottle?
Question: "Are you hungry?" Answer: "I feel like eating."
In the Lost in Space intro why was Dr. Smith actor listed as a special guest star?
Log to console in a Lightning Web Component
How to play songs that contain one guitar when we have two or more guitarists?
Did the characters in Moving Pictures not know about cameras like Twoflower's?
What is the reason behind this musical reference to Pinocchio in the Close Encounters main theme?
simplicial objects in a model category
Can a planet be tidally unlocked?
Are encryption algorithms with fixed-point free permutations inherently flawed?
How do I split ammo?
How can I make my enemies feel real and make combat more engaging?
Found a major flaw in paper from home university – to which I would like to return
Why do we interpret the accelerated expansion of the universe as the proof for the existence of dark energy?
Can I combine Divination spells with Arcane Eye?
How can a kingdom keep the secret of a missing monarch from the public?
Manager has noticed coworker's excessive breaks. Should I warn him?
Are all power cords made equal?
If I have Haste cast on me, does it reduce the casting time for my spells that normally take more than a turn to cast?
Can scheduled and continous replication configurations exist side-by-side on the same master/slave servers?
Backup VLDB replicated database in SQL Server?MySQL replication risks for the masterStreaming Replication Failover - how to point second slave at new master?Replication monitoring refresher for distribution job affecting performancemissing indexes on distributor databasePrevent SQL Server publisher from running out of disk spaceAutomatic MYSQL failoverHelp preparing for MySQL Master Slave ReplicationCan I create a replication table with extra column only on subscription side?Replication stalling on one subscriber
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♦ 6 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♦ 6 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♦ 6 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♦ 6 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