The root node is the only database server that accepts both read and write requests. Once you start additional copy nodes, the root database server sends transaction log pages to the copy nodes in the tree that are defined as its children, provided that they are connected and ready to receive transaction log pages. The pages are normally sent without waiting for a response; however, the root database server occasionally requests an acknowledgement to ensure that the copy node does not receive more asynchronous requests than it can handle.

When the copy node receives pages, it writes them to disk and then sends them to its children (if it has any).

The parent detects if a child node becomes unavailable, and if this happens, the parent stops pushing transaction log pages to the child. If the child is restarted, it requests the transaction log pages that it does not have, and then the parent resumes pushing transaction log pages to the child. The child notifies its parent of changes in the status of the copy node, and the status information eventually makes its way up through the tree to the root database server.

If the root database server becomes unavailable, all of the children in the scale-out system continue running, but they no longer receive updates from the primary database server. Any connections to the copy nodes may retrieve data that is stale. When the root database server becomes available again, its children re-establish connections and resume receiving transaction log pages.

If a copy node encounters a problem, such as an incompatible or mismatched transaction log, the database is stopped. The database server running the problem database also shuts down unless there are other databases running on it.

You can use scale-out in conjunction with database mirroring if you want to ensure the availability of your database. See Read-only scale-out in a database mirroring system.

To set up a scale-out system, it is recommended that you create two definitions with the CREATE MIRROR SERVER statement for the database server that is acting as the root node: one definition for the partner role and one definition for the primary role. In a scale-out system, you must define one partner server. The name that is specified in the partner server definition is used in connection strings and when starting the database server. The database server defined as the primary server is the default parent for copy nodes in the scale-out system. If there is no primary server defined, then you must specify the parent for each copy node that is added to the system.

When you use read-only scale-out, it is recommended that the application connects to the root database server, and the root database server uses information from the application's connection string, together with status and load information from the copy nodes, to determine which node the application should connect to. You can choose to have the application connect to the copy node that is least heavily loaded using the NodeType=COPY connection parameter. Specifying this causes the root database server to redirect the client to that node. See Connect to copy nodes.

If an application makes and drops several such connections within a short period of time, the connection is pooled and the root database server is not asked which copy server to use. This behavior reduces the load on the root database server, but may not give expected behavior. The application can specify that its connections are not to be pooled to ensure that the root server determines which copy node to connect to on each connection. See Connection pooling and read-only scale-out.