Storage Systems - SQL Server 2012 Internals and Troubleshooting - page 92

Remote Data Replication
Both SAN and NAS array controllers offer external data replication. This feature enables two or
more array controllers to synchronize data. Vendors provide either a real-time or a point-in-time
data migration framework.
Real-time frameworks replicate changes as they are written to the array. This replication is
performed synchronously or asynchronously. Synchronous data replication is extremely sensitive
to latency and is therefore not used over great distances.
Synchronous Replication
When SQL Server writes changes to either the data or the log, remember that both the user database
and the log i les must be replicated; a synchronous replication system writes the I/O to its battery-
backed data cache. The array then sends the I/O to its replication partner. The partner writes the
I/O to its own cache and then sends a successful acknowledgment to the source array.
At this point, based on proprietary caching algorithms, the storage arrays write the data from their
cache to disk, and a success acknowledgment is sent to the SQL Server. As you can see, this pro-
cess adds latency to the entire write process. Distance directly translates to latency. If the systems
are asked to handle too much replicated data, or are placed too far apart, the database will slow
considerably.
Asynchronous Replication
Rather than wait for a single change to be committed to both arrays, asynchronous replication sends
a stream of changes between the arrays. As I/O is successfully written to cache, the source array
returns a success acknowledgment to SQL Server. This way, changes are written without slowing the
SQL Server processes.
The primary array sends changes to the remote array in a group. The remote array receives the
group of changes, acknowledges the successful receipt, and then writes the changes to physical
media. Each vendor offering asynchronous remote replication has a property method for ensuring
successful delivery and recovering from communication issues between the arrays.
From a BCDR prospective, the drawback to implementing asynchronous replication is the poten-
tial for some data loss. Because the write I/O is instantly acknowledged on the source array, some
amount of data is always in transit between the arrays. Most unplanned failover events will result
in transit data being lost. Due to the design of SQL server lost data does not mean that the remote
database is corrupt.
NOTE All of these replication technologies must provide the capability to keep
I/O exchanges intact. If only part of a write is delivered and written to a log i le
or data page, it is considered torn . A torn I/O is not recoverable by SQL Server
DBCC. For this reason, SQL Server requires storage arrays to maintain atomic
I/O. The SQL Server team offers a compliance program called SQL Server I/O
Reliability. This program requires storage vendors to guarantee that they are fully
compliant with all SQL Server data integrity standards.