Monday, 20 October 2008

High Availability System (P.A.S.S) - Log Shipping & Replication - SQL Server 2008

Log shipping

Similar to database mirroring, log shipping offers increased database availability and database protection by maintaining a warm standby database on another instance of SQL Server 2008. Unlike database mirroring, log shipping can maintain one or more warm standby databases, and the standby database can be used for reporting purposes. However, log shipping failover is not seamless or automatic you must perform several manual steps, using Transact-SQL, to successfully complete a failover. Clients and applications using the database must be manually redirected from the primary database to the secondary database after manually bringing the secondary database online.

Replication

In SQL Server, there are many types of replication, allowing organisations to copy databases or portions of the database, known as articles, from one SQL Server instance to another SQL Server instance. Replication can be used for data distribution, synchronization, fault tolerance, disaster recovery, load balancing, reporting or testing. Replication uses a publish-subscribe model; in this model, a primary server, referred to as the publisher, distributes data to one or more secondary servers, or subscribers.

The high-availability replication option in SQL Server is called peer-to-peer transactional replication. When using peer-to-peer transactional replication, all participants in the replication topology are peers. There isn't a hierarchy as with normal transactional replication, and data can be updated on all databases configured in the peer-to-peer replication topology. Therefore, one of the advantages of peer-to-peer replication is that if one of the peers is unavailable, traffic can be redirected to another peer as a form of high availability. In addition, because all peers are updatable and support bidirectional replication, this model can be used for load balancing clients across multiple SQL Server instances.

It is wise to make sure that only one node of a peer-to-peer implentation is written to prevent conflicts on happening i.e lost data due to two nodes overwriting the same row in a table. Peer-to-peer replication in SQL Server 2008 introduces the option to enable conflict detection across a peer-to-peer topology. This option helps prevent the issues that are caused from undetected conflicts, including inconsistent application behavior and lost updates. By enabling this option, by default a conflicting change is treated as a critical error that causes the failure of the Distribution Agent. In the event of a conflict, the topology remains in an inconsistent state until the conflict is resolved manually and the data is made consistent across the topology.

Peer-to-peer replication is supported on both the Enterprise and Standard editions.

No comments: