I am really stuck on this, if anyone has some insight into this problem
any help would appreciated...
I'll try to explain what is happening the best I can:
We have a server running Windows Advanced Server 2000 (SP4) w/ SQL
server 2000 (SP3a) (from now on Server A). I have a publication on this
machine with dynamic filters (Changing the HOST_NAME()). The
publication is sending the snapshots to another machine (desktop
machine). The Mobile agent is in the same machine as the snapshots.
The mobile application is syncing fine when hitting Server A. The sync
is done Asynchronously.
Then we have Server B. Running Windows Server 2003 (SP1) w/ SQL 2000
(SP4), same publication w/ dynamic filter however the snapshots and the
mobile agent are in this server.
The mobile application will sync the 1st time but any subsequent syncs
will not work. I check on the Replication monitor and it tells me that
the Merge was a success but the mobile application will not execute the
download table callback, it will execute the Sync callback 5 times and
not proceed in executing the download table callback.
If I change the configuration on the mobile app to point to Server A
the sync will work just fine but, if I change it back to Server B the
sync will work once then it will stop working.
Anyone have some suggestions for troubleshooting?
Update on the situation, it turns out the Sync works fine, what's
going on is that when I sync to Server A, the average sync time is 3
minutes for 2000 rows, on Server B it's taking 45 minutes to sync 1000
rows, any ideas on how to improve/troubleshoot the situation?
I also ran profiler but I have no clue what to search for. In profiler
I couln't find any issues or unless I am not looking for the right
things. Can someone tell me what I can look for in profiler if there
is anything to look for?
Specs for Server A:
CPU: 2 Pentium 3 (550 MHz each)
RAM: 3 GBs
OS: Server 2000 Advanced (SP4)
SQL 2000 SP3
Specs for Server B:
CPU: 2 Xeon Dual-Core (2.8 GHz each)
RAM: 4 GBs
OS: Server 2003 (SP1)
SQL 2000 SP4
Showing posts with label appreciated. Show all posts
Showing posts with label appreciated. Show all posts
Monday, March 19, 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)