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 with database mirroring to ensure the availability of your database.

 See also