Mirroring:-
The Mirror database is not accessible for read or write access.
Replication:-
The Subscriber Database (backup site) is open to reads and writes.
B.)
Mirroring:-
Information flow will be only one way (from Principal to Mirror Server)
Replication:-
Changes can be merged, bi-directional changes can be made, so the information can flow from Publisher to Subscriber and the other way around.
C.)
Mirroring:-
In case of failure of the Principal Database, the Mirror Database will take over the control and will act as Principal and applications can be redirected automatically to connect to this new Principal Server. Very little downtime. No code change required in the application.
Replication:-
In case of failure on Publisher, applications need to be re-directed to the Subscriber manually (in case you really want to do that), requires code change in the app or the connection string.
D.)
Mirroring:-
Almost everything inside the DB is replicated to the DR site, Schema changes can be replicated easily.
Replication:-
You have the option to replicate selected set of tables/SP/functions inside the DB, Schema changes can give some hiccups.
In Short, Mirroring is a good tool for DR (Disaster Recovery) with very little downtime, but the drawback is that the DR site will *not* be accessible to users, whereas Replication can be used to Merge Data between two Servers, can act as a good tool for Reporting purposes as the backup site is accessible to the users, can also act a DR solution.
It all depends on what you need, what are the business requirements , which will help you to choose the right topology in your environment. You can go through SQL Books Online for more details about Mirroring and Replication.
No comments:
Post a Comment