SQL Server简单冗余

Question

I am quite a rookie here and would like to ask all you experts out here on the preferred method of configuring two SQL Servers (2008 R2 and above) for a simple redundancy with the following characteristics:

1. There are 2 computers. Each will have its own SQL Server, and also its own windows service writing timestamped data regularly to the DB. This service already has its own simple switchover/failover algorithm.

2. For the behaviour of the databases, once the primary server goes offline, the backup computer's service will take over to write data to the backup database. The clients will know that since the primary is down, it will reconnect to the backup for data retrieval.

3. Now, when the primary gets back online, the service in this computer will start to write data to database, while the service in the backup computer will stop.

4. From here, a suitable synchronisation plan is required to ensure that the data from the backup database will be synched, or transferred back to the primary database for integrity. In fact, even when the primary is not offline, both databases should be synched as well.

From my descriptions above, I have gone through several texts and arrived at 3 possible candidate methods:

1. Merge Replication
2. Mirroring
3. Additional Customised Programming - really, the last resort, but if needed to I will have to get my hands dirty on this

As a late entrant to recent MS technologies after a long hiatus, I was initially a bit lost. I could not find a clear indication while reading those texts, on whether the methods supports behaviour (4) as described above.

As I understand, method (2) will not work in our case because after failover, the Backup DB becomes the "Principal", and the Primary DB becomes the "Mirror DB". From what I have read, the Mirror DB is offline and not able to be accessed. Kindly note the windows service behaviour in (3) above.

As for method (1), I am confused as to how it will (or will not) work. For example, I understand the concept of Publishing and Subscribing, so the Primary DB will be configured as the publisher, and the Backup DB will be the subscriber. In order to merge, the Backup DB will also need to be configured as the publisher and vice versa. In this case, imagine that the service in the Primary is writing data to the DB, then it gets published to the Backup DB. Then, again the Backup DB will publish this back to the Primary DB (all based on triggers). It seems like an infinite loop here.

I hope my assumptions are fairly correct. What am I missing?

Note: Those servers will only be arriving in a week's time, so I have nothing to test on right now. Can only prepare theoretically.

Thanks and Regards.

Answer 1

If you really need credibility without investing a lot of time, I would suggest to go with the standard solution which is database mirroring . Automatic failover works with having a witness machine which handles the database communication and therefore the client application would not even know if such a failure occurs on the database server. Therefore, your worries about point (3) would not

However, this architecture leaves you with a single point of failure, the witness . If the witness fails, you have to use redundancy strategy. The advantage is that this new recovery process, will not include the database recovery process itself.

Hope I helped!

Answer 2

Merge Replication is viable. In Merge Replication, you publish to the subscriber. Any changes made at the subscriber are made at the publisher when synchronization takes place. If the publisher goes offline, then the changes at the subscriber will be copied to the publisher when it comes back online and syncs.