Database Reference
In-Depth Information
you can read about client connections to alwaysOn availability groups at:
http://technet.microsoft.com/en-us/library/hh510184.aspx .
Note
This behavior helps reduce the load on the primary server, although you should be careful and always monitor
the size of the redo queue. It is entirely possible for the REDO process on secondaries to fall behind and serve clients
data that is not up to date and different from the database on the primary node. It is also important to remember that
the failover process under such conditions can take a long time. Even though you would not have any data loss with a
synchronous commit, the database would not be available until the crash recovery process finished.
You should also be careful with SQL Server Agent jobs in the case of readable secondaries. Jobs are able to access
the databases on readable secondaries and read the data from there. This could lead to situations where you have the
same jobs running on multiple nodes, even though you want them to run only on the primary node.
As a solution, you can check the Role_Desc column of the sys.dm_hadr_availability_replica_states view for
one of the databases in the availability group, checking and validating if the node is primary. You can use it in every job
or, alternatively, create another job that runs every minute and enable or disable jobs based on the state of the node.
You can include SQL Server running inside a virtual machine in the Windows Azure Cloud as a member of the
availability group. This can help you add another geographically redundant node to your high availability solution.
You need to be careful with this approach, however, and make sure that Cloud-based SQL Server can handle the load.
Internet connectivity is another factor to consider. It should have enough bandwidth to transmit log records
and be stable enough to keep the Windows Azure node online and connected most of the time. Remember that
the transaction log will not be truncated when connectivity goes down and some records are not transmitted to the
secondary nodes.
AlwaysOn Availability Groups is a great alternative to database mirroring. Unfortunately, it is not supported in the
Standard Edition of SQL Server 2012-2014.
Note
you can read about alwaysOn availability groups at: http://technet.microsoft.com/en-us/library/hh510230.aspx
Log Shipping
Log shipping allows you to maintain a copy of the database on one or more secondary servers. In a nutshell, log
shipping is a very simple process. You perform log backups based on some schedule, copy those backup files to a
shared location, and restore them on one or more secondary servers. Optionally, you can have a separate server
that monitors the log shipping process, retains information about backup and restore operations, and sends alerts if
attention is required.
Figure 31-8 illustrates a log shipping configuration.
 
 
Search WWH ::




Custom Search