Transcript lesson25
High-Availability Methods Lesson 25 Skills Matrix Skill Matrix Redundancy • Redundancy means having another copy of your database somewhere. – This can be a backup copy. – This can be a replicated copy. – This can be a mirrored copy. High Availability • You’ll get the following high-availability features with Enterprise Edition: – Replication – Distributed transactions – Failover clustering – Multiple instances (up to 50) – Log shipping – Database snapshots – Database mirroring High Availability • You’ll get the following high-availability features with Standard Edition: – Replication – Distributed transactions – Failover clustering (maximum two nodes) – Multiple instances (up to 16) – Log shipping – Database mirroring (synchronous with automatic failover only) Database Mirroring • Database mirroring allows you to create an exact copy of a database on a different server and implement high availability on the user database. • Database mirroring is a software solution, implemented on a database-per-database basis, and involves two copies of a database, with only one accessible by the user. Database Mirroring • Mirroring is a process that looks similar to log shipping; however, it involves a direct process between two separate instances of SQL Server. • Updates made to a database on the first server, called the principal server, are copied over, or are mirrored, to the target server, called the mirror server. • The process involves applying any transaction from the principal to the mirror. Principal Server • Principal server is your primary database, and as such will be your starting point in a databasemirroring session. • Every transaction that will be applied to this database will be transferred to the mirror using a process similar to distributed transactions. • When a database mirroring session starts, the mirror server asks the principal server’s transaction log for all transactions, based on the latest log sequence number. Mirror and Standby Server • The mirror is the database that will receive the copies from the principal server – This assumes that a persistent connection between the mirror and the principal exists. • The process of database mirroring is really one of maintaining a standby server (which means the mirrored database is not accessible by users) that you can easily switch over to in case of the principal server failing. Synchronous Mode • In synchronous mode, every transaction applied to the principal will also be committed (or hardened) on the mirror server before another transaction can begin. • You can consider this to be similar to distributed transactions, which means a transaction on the principal will be released only when it is also committed on the mirror. • Once it receives an acknowledgment from the mirror server, the principal will notify the client that the statement has completed. Asynchronous Mode • In asynchronous mode, the principal server sends log information to the mirror server, without waiting for an acknowledgment from the mirror server. • This means transactions commit without waiting for the mirror server to commit, or harden, the log file. • This mode allows the principal server to run with minimum transaction latency, and prohibits use of automatic failover. Preparing for Database Mirroring • To prepare for database mirroring, you need to perform three configuration steps: 1. Configure the security and communication between the instances. 2. Create the mirror database. 3. Establish a mirror session. Preparing for Database Mirroring Configuring Security and Communication between Instances • To establish a database mirror connection, SQL Server uses endpoints to specify the connection between servers. • You have to use a CREATE ENDPOINT statement. • Of course, in this communication, SQL Server performs authentication over the endpoints (mirror endpoint services), and you can achieve this by using Windows Authentication or certificate-based authentication. Creating the Mirror Database • To create a mirror database, you have to restore the full backup of a principal, including all other types of backup (transaction logs) you created on the principal, before you can establish a session. • It is important, however, that you use the NORECOVERY option when restoring from backup so the backup database will remain in a nonusable state. • The mirror database needs to have the same name as the principal database. Establishing a Mirror Session • Your next step in setting up database mirroring is to set up the mirror session on the database by identifying the mirroring partners. • On the principal database and on the mirror, you need to identify which partners are involved in database mirroring. Configuring a Witness Server • If you care about automatic failover, you should enable a witness server. • The witness server does nothing but monitor the status of the participants. • The good news is that you can have SQL Server Express Edition running on an old desktop computer participate as a witness in database mirroring. Operating Modes • To support database mirroring, you have different operating modes for specifying a transaction safety level. • The mode you use will impact how transactions are managed between the principal and mirror; also, you can choose whether to have automatic or manual failover with a potential loss of data. • Specifically, database mirroring works in three modes: – High availability – High protection – High performance High Availability • In this mode, the database transaction safety is set to FULL, and you will use a witness server to monitor the availability of the principal and mirror. • In this mode, every transaction applied to the principal will also be applied to the mirror. • When the connection to the principal fails, clients will be reconnected to the mirror automatically, after an automatic role transfer occurs. High Protection • In the absence of a witness server, database mirroring will run in high protection mode, which still allows every transaction applied to the principal to be applied to the mirror. • If the principal goes down, you can then manually force roles to switch, although a data loss can occur. High Performance • High-performance mode is also called asynchronous mode. • The chance of data loss is high since it is not guaranteed that the transactions applied to the principal are also applied to the mirror at the moment the principal fails. Switching Roles • A mirror database is a failover database for the principal, and that is what database mirroring is about. • So, when the principal server fails, you want to switch roles over to the mirror, and from then on specify that the mirror should become the primary. • You have three options for role switching: – Automatic failover – Manual failover – Forced service Log Shipping • Log shipping has existed in several releases of SQL Server. • To implement, you take a backup of a transaction log and restore that log onto another server, thus maintaining a standby server that can be used as a read-only server for different purposes, such as for Reporting Services or as your data engine to populate a data warehouse running SQL Server Analysis Services. Log Shipping • Log shipping consists of two servers: – The primary server in a log shipping configuration has the primary database you want to back up and restore on another server. – The secondary server hosts the database that maintains a copy of your primary database; and, of course, it is common that a server can maintain and host multiple copies of primary databases coming from multiple servers. Configuring Log Shipping • You can configure log shipping from within SQL Server Management Studio or by using the corresponding stored procedures. 1. To initialize log shipping, right-click the database you want to use as the primary database, and from the Tasks menu, select the Transaction Log Shipping option. 2. Then, click the Enable This As a Primary Database in a Log Shipping Configuration at the top of this properties page. 3. The next step is to specify the transaction log backup location and backup settings. Log Shipping Recovery Options • The last step in configuring log shipping is to configure the recovery mode on the Restore Transaction Log tab of the Secondary Database Setting dialog box. • For this recovery option, you have two options: – No Recovery Mode – Standby Mode No Recovery Mode • No Recovery Mode: If you choose No Recovery Mode, you will not be able to read from the database, and it will be a hot standby server that you will switch to when an error occurs. Standby Mode • If you choose the Standby Mode option, you will disconnect users from the secondary database while you perform a restore. In this mode, the database will return in a read-only mode after a restore operation is completed, and the database will then be accessible for you to, for example, populate your data warehouse environment or reporting services. Changing Roles • To perform a role change from the primary server to the secondary server, you need to perform an initial role change to be able to make future role changes. You can do this by following these steps: 1. Manually fail over from the primary server to the secondary server. 2. Disable the log shipping backup jobs on the initial primary server. 3. Configure log shipping on the secondary server (using the wizard). Database Snapshot • With a database snapshot, you have the ability to create a snapshot of your data, even before users start working with the data. • The cool features of database snapshots are the following: – Recovering from dropped objects – Recovering essentially any DML statement, such as insert/delete/update – Performing data comparisons Creating a Snapshot • There is no graphical interface for creating a database snapshot. • This means you have to switch to a database query window to initiate a snapshot of a database. Clustering • Clustering is a technology which uses the Windows Cluster Services to provide multiple server nodes each providing SQL Server services using a central shared database on shared disk drives typically setup in a SAN. • Clustering technology is based on Microsoft Cluster Services (MSCS). • This is often the first choice for administrators who desire a highly available database server. Clustering Clustering • Clustering operates at the SQL Server instance level, meaning that all the instance services are protected from a hardware failure. • In the event of a disaster, all databases, logins, jobs, and other server-level services move to the secondary server. • A failover cluster works by having various resources—in this case, including SQL Server— installed on the cluster’s nodes. Clustering • A node is any Windows server participating in the cluster. • At any given time, only one node can own a particular resource and use it to provide services to clients. • In the event of a disaster, the service fails over to another node that activates its copy of that service and begins responding to clients. • Disk resources are shared among all nodes, eliminating the need to keep a separate copy of any data for the resource synchronized on multiple nodes. Clustering • The following are some requirements to implement a cluster: – WSC-certified hardware – Shared disk resources such as a SAN – Geographic limitations – Additional network configuration – Additional costs Summary • In this lesson, you learned about several highavailability options and how to implement them. • Database mirroring uses TCP communication so that you can create an exact copy of a database at a remote location. • It also allows you to automatically switch over when implemented with a witness that monitors the connection and initiates the mirror to take over from the principal database. Summary • You also learned how to work with log shipping, which takes a copy of the transaction log and “ships” it to a remote destination. • To switch over to the remote standby server, you manually need to follow certain steps to perform the switch. • The standby server, however, has the capability to be used as a read-only server that you can use to populate a data warehouse, for ad hoc querying, or for reporting capabilities. Summary • Another effective method to implement is database snapshots. • This takes a “picture” of data and saves only the changes to the snapshot from the moment you take the initial snapshot. • Snapshots enable you to revert from user mistakes, but they do not provide fault tolerance. Summary • Consider fail-over clustering when your application absolutely must survive any catastrophe. • Place the servers in different buildings should one burn. • Route networks in such a manner that a back hoe tearing one line in two won’t disrupt an alternate path. • The weak link proves to be the common data store. Summary for Certification Examination • Familiarize yourself with the concept of database mirroring. Understand general terms, such as principal, mirror, and witness server. • If you want to invoke automatic failover, you can achieve this only by having a witness. • Database mirroring uses endpoints that communicate with each other using TCP. • You also need to know how you can manually force a mirror to take over the role of the principal server. Summary for Certification Examination • Understand log shipping. Know how to implement and use log shipping on a database—and keep in mind that this is implemented using transaction log backups. • The ability to specify the schedule on the transaction log backup, and when to restore initially, determines the latency between the recovery and failover strategy. • Log shipping is a manual failover process and allows you to have a hot standby server or readonly server that can be used for different purposes. Summary for Certification Examination • Understand database snapshots. In a database snapshot, it is important to remember that the snapshot does not implement high availability; it only records data changes to a snapshot database. • When retrieving data from a snapshot, the data will be partially read from the production database and so will get only the changed data pages from the snapshot. Summary for Certification Examination • Understand fail-over clustering. • This is a Windows Server solution available to SQL Server (and all other applications). • A heartbeat transmits between participating servers. When the heartbeat is not detected, automatic fail-over occurs. • This usually happens sufficiently rapidly that users don’t notice.