There are several requirements for setting up a tenant mirroring and/or read-only scale-out system.
Place the primary database, mirror database, and arbiter server on three different hosts. If the primary becomes unavailable because of hardware or software failure, then the mirror negotiates with the arbiter to assume the role of primary.
Although databases can run on the cloud partners, for improved performance, especially in clouds with a high volume of activity, consider running tenant databases on separate hosts.
A cloud server can only run one database copy of a specific tenant database at a time.
A cloud server can be assigned a role in a cloud high availability or tenant mirroring system. You can assign a cloud server multiple roles in various tenant mirroring systems. For example, a cloud server can act as an arbiter for one tenant, a mirror for another tenant, and a primary for yet another tenant.
Application designers should consider that if a role switch occurs for a mirrored tenant database, then tenant applications must reconnect to the database.
Autostart databases cannot be involved in a mirroring or read-only scale-out system.
When a tenant database is involved in a mirroring or read-only scale-out system, all of its database copies must run on cloud servers that are of the same major and minor version. In a mirroring system, the arbiter server must also be of the same major and minor version as primary, mirror, and any scale-out database copies.
To ensure the availability of the read-write database, use mirroring with a tenant read-only scale-out system. In a mirroring system the primary and mirror databases can switch roles at anytime. As a result, when a read-only scale-out is used with mirroring, the read-write database of the read-only scale-out system consists of both the primary and mirror databases of the tenant mirroring system.