You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This topic introduces the [!INCLUDE[ssHADR](../../../includes/sshadr-md.md)] concepts that are central for configuring and managing one or more availability groups in [!INCLUDE[ssCurrent](../../../includes/sscurrent-md.md)]. For a summary of the benefits offered by availability groups and an overview of [!INCLUDE[ssHADR](../../../includes/sshadr-md.md)] terminology, see [Always On Availability Groups (SQL Server)](../../../database-engine/availability-groups/windows/always-on-availability-groups-sql-server.md).
@@ -49,15 +49,15 @@ ms.author: mathoma
49
49
50
50
![Availability group with five replicas](../../../database-engine/availability-groups/windows/media/aoag-agintrofigure.gif"Availability group with five replicas")
51
51
52
-
## <aname="AvDbs"></a> Availability Databases
52
+
## <aname="AvDbs"></a> Availability databases
53
53
To add a database to an availability group, the database must be an online, read-write database that exists on the server instance that hosts the primary replica. When you add a database, it joins the availability group as a primary database, while remaining available to clients. No corresponding secondary database exists until backups of the new primary database are restored to the server instance that hosts the secondary replica (using RESTORE WITH NORECOVERY). The new secondary database is in the RESTORING state until it is joined to the availability group. For more information, see [Start Data Movement on an Always On Secondary Database (SQL Server)](../../../database-engine/availability-groups/windows/start-data-movement-on-an-always-on-secondary-database-sql-server.md).
54
54
55
55
Joining places the secondary database into the ONLINE state and initiates data synchronization with the corresponding primary database. *Data synchronization* is the process by which changes to a primary database are reproduced on a secondary database. Data synchronization involves the primary database sending transaction log records to the secondary database.
56
56
57
57
> [!IMPORTANT]
58
58
> An availability database is sometimes called a *database replica* in [!INCLUDE[tsql](../../../includes/tsql-md.md)], PowerShell, and SQL Server Management Objects (SMO) names. For example, the term "database replica" is used in the names of the Always On dynamic management views that return information about availability databases: **sys.dm_hadr_database_replica_states** and **sys.dm_hadr_database_replica_cluster_states**. However, in SQL Server Books Online, the term "replica" typically refers to availability replicas. For example, "primary replica" and "secondary replica" always refer to availability replicas.
59
59
60
-
## <aname="AGsARsADBs"></a> Availability Replicas
60
+
## <aname="AGsARsADBs"></a> Availability replicas
61
61
Each availability group defines a set of two or more failover partners known as availability replicas. *Availability replicas* are components of the availability group. Each availability replica hosts a copy of the availability databases in the availability group. For a given availability group, the availability replicas must be hosted by separate instances of [!INCLUDE[ssNoVersion](../../../includes/ssnoversion-md.md)] residing on different nodes of a WSFC cluster. Each of these server instances must be enabled for Always On.
62
62
63
63
A given instance can host only one availability replica per availability group. However, each instance can be used for many availability groups. A given instance can be either a stand-alone instance or a [!INCLUDE[ssNoVersion](../../../includes/ssnoversion-md.md)] failover cluster instance (FCI). If you require server-level redundancy, use Failover Cluster Instances.
@@ -67,20 +67,21 @@ ms.author: mathoma
67
67
> [!NOTE]
68
68
> When the role of an availability replica is indeterminate, such as during a failover, its databases are temporarily in a NOT SYNCHRONIZING state. Their role is set to RESOLVING until the role of the availability replica has resolved. If an availability replica resolves to the primary role, its databases become the primary databases. If an availability replica resolves to the secondary role, its databases become secondary databases.
The availability mode is a property of each availability replica. The availability mode determines whether the primary replica waits to commit transactions on a database until a given secondary replica has written the transaction log records to disk (hardened the log). [!INCLUDE[ssHADR](../../../includes/sshadr-md.md)] supports two availability modes-*asynchronous-commit mode* and *synchronous-commit mode*.
The availability mode is a property of each availability replica. The availability mode determines whether the primary replica waits to commit transactions on a database until a given secondary replica has written the transaction log records to disk (hardened the log). [!INCLUDE[ssHADR](../../../includes/sshadr-md.md)] supports two availability modes-*asynchronous-commit mode* and *synchronous-commit mode*.
72
73
73
74
-**Asynchronous-commit mode**
74
75
75
-
An availability replica that uses this availability mode is known as an *asynchronous-commit replica*. Under asynchronous-commit mode, the primary replica commits transactions without waiting for acknowledgement that an asynchronous-commit secondary replica has hardened the log. Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making some data loss possible.
76
+
An availability replica that uses this availability mode is known as an *asynchronous-commit replica*. Under asynchronous-commit mode, the primary replica commits transactions without waiting for acknowledgment that an asynchronous-commit secondary replica has hardened the log. Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making some data loss possible.
76
77
77
78
-**Synchronous-commit mode**
78
79
79
80
An availability replica that uses this availability mode is known as a *synchronous-commit replica*. Under synchronous-commit mode, before committing transactions, a synchronous-commit primary replica waits for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log. Synchronous-commit mode ensures that once a given secondary database is synchronized with the primary database, committed transactions are fully protected. This protection comes at the cost of increased transaction latency.
80
81
81
82
For more information, see [Availability Modes (Always On Availability Groups)](../../../database-engine/availability-groups/windows/availability-modes-always-on-availability-groups.md).
82
83
83
-
## <aname="FormsOfFailover"></a> Types of Failover
84
+
## <aname="FormsOfFailover"></a> Types of failover
84
85
Within the context of a session between the primary replica and a secondary replica, the primary and secondary roles are potentially interchangeable in a process known as *failover*. During a failover the target secondary replica transitions to the primary role, becoming the new primary replica. The new primary replica brings its databases online as the primary databases, and client applications can connect to them. When the former primary replica is available, it transitions to the secondary role, becoming a secondary replica. The former primary databases become secondary databases and data synchronization resumes.
85
86
86
87
Three forms of failover exist-automatic, manual, and forced (with possible data loss). The form or forms of failover supported by a given secondary replica depends on its availability mode, and, for synchronous-commit mode, on the failover mode on the primary replica and target secondary replica, as follows.
@@ -105,15 +106,15 @@ ms.author: mathoma
105
106
106
107
For more information, see [Failover and Failover Modes (Always On Availability Groups)](../../../database-engine/availability-groups/windows/failover-and-failover-modes-always-on-availability-groups.md).
You can provide client connectivity to the primary replica of a given availability group by creating an availability group listener. An *availability group listener* provides a set of resources that is attached to a given availability group to direct client connections to the appropriate availability replica.
110
111
111
112
An availability group listener is associated with a unique DNS name that serves as a virtual network name (VNN), one or more virtual IP addresses (VIPs), and a TCP port number. For more information, see [Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)](../../../database-engine/availability-groups/windows/listeners-client-connectivity-application-failover.md).
112
113
113
114
> [!TIP]
114
115
> If an availability group possesses only two availability replicas and is not configured to allow read-access to the secondary replica, clients can connect to the primary replica by using a [database mirroring connection string](../../../database-engine/database-mirroring/connect-clients-to-a-database-mirroring-session-sql-server.md). This approach can be useful temporarily after you migrate a database from database mirroring to [!INCLUDE[ssHADR](../../../includes/sshadr-md.md)]. Before you add additional secondary replicas, you will need to create an availability group listener the availability group and update your applications to use the network name of the listener.
115
116
116
-
## <aname="ActiveSecondaries"></a> Active Secondary Replicas
117
+
## <aname="ActiveSecondaries"></a> Active secondary replicas
117
118
[!INCLUDE[ssHADR](../../../includes/sshadr-md.md)] supports active secondary replicas. Active secondary capabilities include support for:
118
119
119
120
-**Performing backup operations on secondary replicas**
@@ -126,7 +127,7 @@ ms.author: mathoma
126
127
127
128
If an availability group currently possesses an availability group listener and one or more readable secondary replicas, [!INCLUDE[ssNoVersion](../../../includes/ssnoversion-md.md)] can route read-intent connection requests to one of them (*read-only routing*). For more information, see [Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)](../../../database-engine/availability-groups/windows/listeners-client-connectivity-application-failover.md).
128
129
129
-
## <aname="SessionTimeoutPerios"></a> Session-Timeout Period
130
+
## <aname="SessionTimeoutPerios"></a> Session-timeout period
130
131
The session-timeout period is an availability-replica property that determines how long connection with another availability replica can remain inactive before the connection is closed. The primary and secondary replicas ping each other to signal that they are still active. Receiving a ping from the other replica during the timeout period indicates that the connection is still open and that the server instances are communicating. On receiving a ping, an availability replica resets its session-timeout counter on that connection.
131
132
132
133
The session-timeout period prevents either replica from waiting indefinitely to receive a ping from the other replica. If no ping is received from the other replica within the session-timeout period, the replica times out. Its connection is closed, and the timed-out replica enters the DISCONNECTED state. Even if a disconnected replica is configured for synchronous-commit mode, transactions will not wait for that replica to reconnect and resynchronize.
@@ -136,16 +137,16 @@ ms.author: mathoma
136
137
> [!NOTE]
137
138
> In the resolving role, the session-timeout period does not apply because pinging does not occur.
138
139
139
-
## <aname="APR"></a> Automatic Page Repair
140
+
## <aname="APR"></a> Automatic page repair
140
141
Each availability replica tries to automatically recover from corrupted pages on a local database by resolving certain types of errors that prevent reading a data page. If a secondary replica cannot read a page, the replica requests a fresh copy of the page from the primary replica. If the primary replica cannot read a page, the replica broadcasts a request for a fresh copy to all the secondary replicas and gets the page from the first to respond. If this request succeeds, the unreadable page is replaced by the copy, which usually resolves the error.
141
142
142
143
For more information, see [Automatic Page Repair (Availability Groups: Database Mirroring)](../../../sql-server/failover-clusters/automatic-page-repair-availability-groups-database-mirroring.md).
143
144
144
-
## <aname="RelatedTasks"></a> Related Tasks
145
+
## <aname="RelatedTasks"></a> Related tasks
145
146
146
147
-[Getting Started with Always On Availability Groups (SQL Server)](../../../database-engine/availability-groups/windows/getting-started-with-always-on-availability-groups-sql-server.md)
Copy file name to clipboardExpand all lines: docs/integration-services/service/integration-services-ssis-in-a-cluster.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -122,7 +122,7 @@ For those customers who conclude that the advantages of configuring the [!INCLUD
122
122
123
123
4. Change the value of the **StorePath** element to the fully-qualified path of the **Packages** folder created on the shared disk in a previous step.
124
124
125
-
5.Update the value of **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\SSIS\ServiceConfigFile** in the Registry to the fully-qualified path and file name of the service configuration file on the shared disk.
125
+
5.On each node, update the value of **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\SSIS\ServiceConfigFile** in the Registry to the fully-qualified path and file name of the service configuration file on the shared disk.
126
126
127
127
### To bring the Integration Services service online
When migrating from an older version of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] to [!INCLUDE[ssSQL14](../../includes/sssql14-md.md)] or newer, and [upgrading the database compatibility level](../../relational-databases/databases/view-or-change-the-compatibility-level-of-a-database.md) to the latest available, a workload may be exposed to the risk of performance regression. This is also possible to a lesser degree when upgrading between [!INCLUDE[ssSQL14](../../includes/sssql14-md.md)] and any newer version.
0 commit comments