Hello All,
I would greatly appreciate some help on this issue. I am very stuck and
struggling.
Basicall I have a SQL 2000 Server, that is the publisher for a merge
replication. This merge replication, is to replicate to handhelds, that via
a mobile application, insert into the tables. The handhelds seem to be
operating fine. The publisher is not however. When I try and insert records
into the tables via web interface, I keep getting:
The identity range managed by replication is full and must be updated by a
replication agent.
So I've read for hours online searching for this issue, tons of people have
hit it, but nobody has a solid answer. Most people just hack crap together
that works, or sometimes works.
Basically how I configured it in the beginning was, each subscriber, and
publisher got 200 identities, using automatic identity range management.
Then the website started to hit problems. So I read some articles, some
people said to set the identity ranges to something high that may never get
hit. So I changed them to 60,000. This doesn't seem to work either. Every
day now, sometimes twice a day, I'm getting range is full errors.
Sometimes I can temporarily fix this by calling stored procedures manually
via:
Sometimes works:
EXEC sp_adjustpublisheridentityrange "PublicationName"
Works more often:
DBCC CHECKIDENT ('TableName', RESEED)
But right now, I have one of our customer databases that neither of these
are working.
I would very much appreciate any help on this. It seems theres many myths
about merge replication not working well at all, and its a huge pain to
manage, if you are even able to make it work. I would greatly appreciate
some help as I'm very stuck. Perhaps contact with a MS rep would be great as
well but not very likely I'm sure.
Perhaps theres some tables I can look up that has values of settings that
could of gotten messed up, that I could show to someone who understands them,
and trouble shoot there if that exists.
Thanks all for listening.
Take care,
Simon
As a side note,
I just looked at the tables constraints, and it says this:
([VID] > 21100 and [VID] < 21200)
Is this correct? Is this an issue that I configured it originally for 200
ranges, then changed it to 60,000 ranges?
Also on one table that all the stored procedures don't work, there are 2
constraints on one table for inserts and both are from replication. This
sounds bad. Something is messed up I think?
Thanks,
Simon
"Si" wrote:
> Hello All,
> I would greatly appreciate some help on this issue. I am very stuck and
> struggling.
> Basicall I have a SQL 2000 Server, that is the publisher for a merge
> replication. This merge replication, is to replicate to handhelds, that via
> a mobile application, insert into the tables. The handhelds seem to be
> operating fine. The publisher is not however. When I try and insert records
> into the tables via web interface, I keep getting:
> The identity range managed by replication is full and must be updated by a
> replication agent.
> So I've read for hours online searching for this issue, tons of people have
> hit it, but nobody has a solid answer. Most people just hack crap together
> that works, or sometimes works.
> Basically how I configured it in the beginning was, each subscriber, and
> publisher got 200 identities, using automatic identity range management.
> Then the website started to hit problems. So I read some articles, some
> people said to set the identity ranges to something high that may never get
> hit. So I changed them to 60,000. This doesn't seem to work either. Every
> day now, sometimes twice a day, I'm getting range is full errors.
> Sometimes I can temporarily fix this by calling stored procedures manually
> via:
> Sometimes works:
> EXEC sp_adjustpublisheridentityrange "PublicationName"
> Works more often:
> DBCC CHECKIDENT ('TableName', RESEED)
> But right now, I have one of our customer databases that neither of these
> are working.
> I would very much appreciate any help on this. It seems theres many myths
> about merge replication not working well at all, and its a huge pain to
> manage, if you are even able to make it work. I would greatly appreciate
> some help as I'm very stuck. Perhaps contact with a MS rep would be great as
> well but not very likely I'm sure.
> Perhaps theres some tables I can look up that has values of settings that
> could of gotten messed up, that I could show to someone who understands them,
> and trouble shoot there if that exists.
> Thanks all for listening.
> Take care,
> Simon
Showing posts with label greatly. Show all posts
Showing posts with label greatly. Show all posts
Monday, March 12, 2012
Friday, March 9, 2012
Merge replication et al - please help a newbie...
Hi,
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For optimal performance use bi-directional transactional replication. While
merge replication will work it adds latency to each DML and the syncs will
take typically over a minute - so your exposure to data loss is greater.
With bi-directional transactional replication it could be seconds.
Note that you really should be using clustering for this.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<almurph@.altavista.com> wrote in message
news:1156779259.621228.78930@.i3g2000cwc.googlegroups.com...
> Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
> have a web application on a server (lets call it server "A"). Its
> talking to a DB server (lets call it server "B"). We want to backup
> server "B" so that in the event "B" fallsover - the backup server (lets
> call it "C") will kick in and carry on from where "B" left off. When
> "B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
> switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
> with "B" and everything will be grand again.
> After looking at various failover models from transactional
> replication to log shipping I think that merge replication will do the
> trick (because I think it will fulfill all the requirements). The boss
> does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
> to set or watch out for before we begin this process? Any user
> experiences/advice much much appreciated.
> Thanking you,
> Al.
>|||Thanks Hilary,
I heard about translational replication but *not* bi-directional
replication. I take it "works both ways" if you take my meaning. That
is, if B fails and C records some transactions it will sync those back
to B if and when B comes online again. I thought that transactional
replication would not do this.
I know I should be clustering but its expensive and I have buydget
limitations.
Thanks though for your feedback.
Al.|||On 29 Aug 2006 03:25:42 -0700, almurph@.altavista.com wrote:
>Thanks Hilary,
> I heard about translational replication but *not* bi-directional
>replication. I take it "works both ways" if you take my meaning. That
>is, if B fails and C records some transactions it will sync those back
>to B if and when B comes online again. I thought that transactional
>replication would not do this.
> I know I should be clustering but its expensive and I have buydget
>limitations.
> Thanks though for your feedback.
Bidirectional was in SQL2K but the wizards wouldn't do it, you had to
read BOL and script your own commands. Don't know if the SQL2005
wizard is smarter. There are of course the usual complications for
identity fields and such, for replication. You can easily spend more
company money on your time setting up and managing replication, than
you might spend on clustering. Though, the bidirectional replication
looks pretty elegant, from about 10,000 feet of altitude.
J.
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For optimal performance use bi-directional transactional replication. While
merge replication will work it adds latency to each DML and the syncs will
take typically over a minute - so your exposure to data loss is greater.
With bi-directional transactional replication it could be seconds.
Note that you really should be using clustering for this.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<almurph@.altavista.com> wrote in message
news:1156779259.621228.78930@.i3g2000cwc.googlegroups.com...
> Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
> have a web application on a server (lets call it server "A"). Its
> talking to a DB server (lets call it server "B"). We want to backup
> server "B" so that in the event "B" fallsover - the backup server (lets
> call it "C") will kick in and carry on from where "B" left off. When
> "B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
> switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
> with "B" and everything will be grand again.
> After looking at various failover models from transactional
> replication to log shipping I think that merge replication will do the
> trick (because I think it will fulfill all the requirements). The boss
> does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
> to set or watch out for before we begin this process? Any user
> experiences/advice much much appreciated.
> Thanking you,
> Al.
>|||Thanks Hilary,
I heard about translational replication but *not* bi-directional
replication. I take it "works both ways" if you take my meaning. That
is, if B fails and C records some transactions it will sync those back
to B if and when B comes online again. I thought that transactional
replication would not do this.
I know I should be clustering but its expensive and I have buydget
limitations.
Thanks though for your feedback.
Al.|||On 29 Aug 2006 03:25:42 -0700, almurph@.altavista.com wrote:
>Thanks Hilary,
> I heard about translational replication but *not* bi-directional
>replication. I take it "works both ways" if you take my meaning. That
>is, if B fails and C records some transactions it will sync those back
>to B if and when B comes online again. I thought that transactional
>replication would not do this.
> I know I should be clustering but its expensive and I have buydget
>limitations.
> Thanks though for your feedback.
Bidirectional was in SQL2K but the wizards wouldn't do it, you had to
read BOL and script your own commands. Don't know if the SQL2005
wizard is smarter. There are of course the usual complications for
identity fields and such, for replication. You can easily spend more
company money on your time setting up and managing replication, than
you might spend on clustering. Though, the bidirectional replication
looks pretty elegant, from about 10,000 feet of altitude.
J.
Merge replication et al - please help a newbie...
Hi,
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For one thing, there is a separate replication newsgroup you might
want to try:
microsoft.public.sqlserver.replication
For a few hints, replication is always about 10x more difficult than
it looks, especially in recovery after problems, and I'd give serious
consideration to transactional replication instead, of course
depending on your database side, transaction rate, etc.
J.
On 28 Aug 2006 08:34:11 -0700, almurph@.altavista.com wrote:
>Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
>have a web application on a server (lets call it server "A"). Its
>talking to a DB server (lets call it server "B"). We want to backup
>server "B" so that in the event "B" fallsover - the backup server (lets
>call it "C") will kick in and carry on from where "B" left off. When
>"B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
>switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
>with "B" and everything will be grand again.
> After looking at various failover models from transactional
>replication to log shipping I think that merge replication will do the
>trick (because I think it will fulfill all the requirements). The boss
>does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
>to set or watch out for before we begin this process? Any user
>experiences/advice much much appreciated.
>Thanking you,
>Al.
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For one thing, there is a separate replication newsgroup you might
want to try:
microsoft.public.sqlserver.replication
For a few hints, replication is always about 10x more difficult than
it looks, especially in recovery after problems, and I'd give serious
consideration to transactional replication instead, of course
depending on your database side, transaction rate, etc.
J.
On 28 Aug 2006 08:34:11 -0700, almurph@.altavista.com wrote:
>Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
>have a web application on a server (lets call it server "A"). Its
>talking to a DB server (lets call it server "B"). We want to backup
>server "B" so that in the event "B" fallsover - the backup server (lets
>call it "C") will kick in and carry on from where "B" left off. When
>"B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
>switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
>with "B" and everything will be grand again.
> After looking at various failover models from transactional
>replication to log shipping I think that merge replication will do the
>trick (because I think it will fulfill all the requirements). The boss
>does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
>to set or watch out for before we begin this process? Any user
>experiences/advice much much appreciated.
>Thanking you,
>Al.
Merge replication et al - please help a newbie...
Hi,
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For one thing, there is a separate replication newsgroup you might
want to try:
microsoft.public.sqlserver.replication
For a few hints, replication is always about 10x more difficult than
it looks, especially in recovery after problems, and I'd give serious
consideration to transactional replication instead, of course
depending on your database side, transaction rate, etc.
J.
On 28 Aug 2006 08:34:11 -0700, almurph@.altavista.com wrote:
>Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
>have a web application on a server (lets call it server "A"). Its
>talking to a DB server (lets call it server "B"). We want to backup
>server "B" so that in the event "B" fallsover - the backup server (lets
>call it "C") will kick in and carry on from where "B" left off. When
>"B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
>switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
>with "B" and everything will be grand again.
> After looking at various failover models from transactional
>replication to log shipping I think that merge replication will do the
>trick (because I think it will fulfill all the requirements). The boss
>does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
>to set or watch out for before we begin this process? Any user
>experiences/advice much much appreciated.
>Thanking you,
>Al.
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For one thing, there is a separate replication newsgroup you might
want to try:
microsoft.public.sqlserver.replication
For a few hints, replication is always about 10x more difficult than
it looks, especially in recovery after problems, and I'd give serious
consideration to transactional replication instead, of course
depending on your database side, transaction rate, etc.
J.
On 28 Aug 2006 08:34:11 -0700, almurph@.altavista.com wrote:
>Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
>have a web application on a server (lets call it server "A"). Its
>talking to a DB server (lets call it server "B"). We want to backup
>server "B" so that in the event "B" fallsover - the backup server (lets
>call it "C") will kick in and carry on from where "B" left off. When
>"B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
>switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
>with "B" and everything will be grand again.
> After looking at various failover models from transactional
>replication to log shipping I think that merge replication will do the
>trick (because I think it will fulfill all the requirements). The boss
>does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
>to set or watch out for before we begin this process? Any user
>experiences/advice much much appreciated.
>Thanking you,
>Al.
Merge replication et al - please help a newbie...
Hi,
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For optimal performance use bi-directional transactional replication. While
merge replication will work it adds latency to each DML and the syncs will
take typically over a minute - so your exposure to data loss is greater.
With bi-directional transactional replication it could be seconds.
Note that you really should be using clustering for this.
--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<almurph@.altavista.com> wrote in message
news:1156779259.621228.78930@.i3g2000cwc.googlegroups.com...
> Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
> have a web application on a server (lets call it server "A"). Its
> talking to a DB server (lets call it server "B"). We want to backup
> server "B" so that in the event "B" fallsover - the backup server (lets
> call it "C") will kick in and carry on from where "B" left off. When
> "B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
> switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
> with "B" and everything will be grand again.
> After looking at various failover models from transactional
> replication to log shipping I think that merge replication will do the
> trick (because I think it will fulfill all the requirements). The boss
> does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
> to set or watch out for before we begin this process? Any user
> experiences/advice much much appreciated.
> Thanking you,
> Al.
>|||Thanks Hilary,
I heard about translational replication but *not* bi-directional
replication. I take it "works both ways" if you take my meaning. That
is, if B fails and C records some transactions it will sync those back
to B if and when B comes online again. I thought that transactional
replication would not do this.
I know I should be clustering but its expensive and I have buydget
limitations.
Thanks though for your feedback.
Al.|||On 29 Aug 2006 03:25:42 -0700, almurph@.altavista.com wrote:
>Thanks Hilary,
> I heard about translational replication but *not* bi-directional
>replication. I take it "works both ways" if you take my meaning. That
>is, if B fails and C records some transactions it will sync those back
>to B if and when B comes online again. I thought that transactional
>replication would not do this.
> I know I should be clustering but its expensive and I have buydget
>limitations.
> Thanks though for your feedback.
Bidirectional was in SQL2K but the wizards wouldn't do it, you had to
read BOL and script your own commands. Don't know if the SQL2005
wizard is smarter. There are of course the usual complications for
identity fields and such, for replication. You can easily spend more
company money on your time setting up and managing replication, than
you might spend on clustering. Though, the bidirectional replication
looks pretty elegant, from about 10,000 feet of altitude.
J.
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For optimal performance use bi-directional transactional replication. While
merge replication will work it adds latency to each DML and the syncs will
take typically over a minute - so your exposure to data loss is greater.
With bi-directional transactional replication it could be seconds.
Note that you really should be using clustering for this.
--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<almurph@.altavista.com> wrote in message
news:1156779259.621228.78930@.i3g2000cwc.googlegroups.com...
> Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
> have a web application on a server (lets call it server "A"). Its
> talking to a DB server (lets call it server "B"). We want to backup
> server "B" so that in the event "B" fallsover - the backup server (lets
> call it "C") will kick in and carry on from where "B" left off. When
> "B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
> switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
> with "B" and everything will be grand again.
> After looking at various failover models from transactional
> replication to log shipping I think that merge replication will do the
> trick (because I think it will fulfill all the requirements). The boss
> does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
> to set or watch out for before we begin this process? Any user
> experiences/advice much much appreciated.
> Thanking you,
> Al.
>|||Thanks Hilary,
I heard about translational replication but *not* bi-directional
replication. I take it "works both ways" if you take my meaning. That
is, if B fails and C records some transactions it will sync those back
to B if and when B comes online again. I thought that transactional
replication would not do this.
I know I should be clustering but its expensive and I have buydget
limitations.
Thanks though for your feedback.
Al.|||On 29 Aug 2006 03:25:42 -0700, almurph@.altavista.com wrote:
>Thanks Hilary,
> I heard about translational replication but *not* bi-directional
>replication. I take it "works both ways" if you take my meaning. That
>is, if B fails and C records some transactions it will sync those back
>to B if and when B comes online again. I thought that transactional
>replication would not do this.
> I know I should be clustering but its expensive and I have buydget
>limitations.
> Thanks though for your feedback.
Bidirectional was in SQL2K but the wizards wouldn't do it, you had to
read BOL and script your own commands. Don't know if the SQL2005
wizard is smarter. There are of course the usual complications for
identity fields and such, for replication. You can easily spend more
company money on your time setting up and managing replication, than
you might spend on clustering. Though, the bidirectional replication
looks pretty elegant, from about 10,000 feet of altitude.
J.
Subscribe to:
Comments (Atom)