Lets summarise some important learnings about SQL MI and failover groups.

1. when you add a database to a failover group the secondary database has the same edition / compute tier as the primary.
2. From the last blog post, storage sizes should be the same too!
3. Your secondary must be empty else setup will fail.
4. You will have read / write and read only listener. Use the R /W endpoint for the main app and read only endpoint for reads – you will get a better experience.
5. When setting up failover groups, a process called seeding takes place. There are limits to how fast this can happen, Microsoft states roughly for Managed Instance a seeding process rate of 360 GB / hour, however this does depend on the networking infrastructure you have such as the Express Route link you have.
6. By default, this is automatic failover mode, that is once the GRACE period has expired. So if the robots cannot heal the machines within the grace period then expect the failover to take place.
   1. Minimum grace period is 1 hour!
7. The failover of the read-only listener is disabled by default. you can enable failover for the read-only listener by configuring the AllowReadOnlyFailoverToPrimary property. In that case, the read-only traffic will be automatically redirected to the primary if the secondary is not available.
8. Always use the Paired Data Centre for best performance – where possible, for example UK South and UK West for your primary and secondary servers.
9. If you delete a database on the primary server, it will be dropped from the secondary.
10. The VNETs for the servers involved in replication ,must be able to talk to each other – Global VNET peering is now supported https://azure.microsoft.com/en-gb/updates/global-virtual-network-peering-support-for-azure-sql-managed-instance-now-available/

If not, you will get the following

"InstanceFailoverGroupIncorrectNetworkingConfiguration",
        "message": "Failover group creation failed because the primary server's replication traffic cannot reach the secondary server. Please verify that connectivity between the VNets of the primary and secondary managed servers has been established."

11. The VNETs should not have overlapping addresses. If you do not follow this you will get the following error when trying to setup connectivity.

12. Network Security Groups (NSG) such that ports 5022 and the range 11000~12000 are open inbound and outbound for connections from the subnet of the other managed instance. This is to allow replication traffic between the instances.

13.Important workflow must be followed when upgrading / downgrading the database!

When upgrading start with all of the secondary databases first, and then upgrade the primary. When downgrading, do the opposite, WHY? to avoid the problem where the secondary at a lower SKU gets overloaded and must be re-seeded which will impact your experience.

I will try and keep this list updated as I go. Anything I have missed that is important let me know.