August 30, 2006 at 6:06 am
Hi,
I find it difficult to figure out how design my redundant databases. I have two servers, both are running some custom applications and one instance of SQL Server 2005 each. On the client, I can select which server to work with. If one server fails the client will fail over manually or automatically to the other server. Therefore, I need to keep the data on the two servers synchronized. I tried merge replication, but there was a latency of about 2-5 seconds, which I cannot afford. If one server goes down it could leave the other one with a different set of data which will make the client behave differently after the failover.
I also looked at database mirroring. I haven't tried it yet but as far as I understood, it uses the instance on the second server as a standby instance. I guess there is some latency here as well? Also, I dont want the applications on the server to use the instance on the other server. All applications on the server must use only the local instance.
I'm thinking of clustering, but I have no experience in that.
My goal is to have two SQL Server 2005 running completely synchronized. What is the best solution for that? Actually, I'm not interested in failover on the SQL Server level since that is taken care of by other applications, I'm only interested in making sure that the data are exactly the same on both servers at any given time.
August 31, 2006 at 6:59 am
Take a look at Peer Replication in BOL...
Peer-to-peer transactional replication is designed for applications that might read or modify the data at any of the databases participating in replication. For example, an online shopping application is well suited to peer-to-peer replication: application performance can be improved by spreading out queries that read data across multiple databases. Additionally, if any of the servers hosting the databases are unavailable, an application can be programmed to route traffic to the remaining servers, which contain identical copies of the data. Read performance is improved because activity can be spread across all nodes. Aggregate update, insert, and delete performance for the topology is similar to a single node, because ultimately all changes are propagated to all nodes.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply