xConnect Shards in Availability Group

Question

I have a client running 9.3 OnPrem. They set up availability group (AG) listeners for their SQL servers and included the xConnect collection databases in the group. The Shards are in the AG, and it appears to be quite upsetting for the application. The logs are filled with the error below, and (we think) it is causing some performance impacts to page loads. There is also functionality that depends on xConnect that does not appear to be working due to the database errors.

I have a member of our Managed Services team telling me that the Shards should not be added to an AG, as it tends to be redundant (overkill) and a waste of performance. I'm wondering if this is the case, and what sort of alternatives there are for HA/DR strategies if the Shards cannot be replicated.

2020-04-10 12:12:28.429 -05:00 [Error] The target database, 'sc_Xdb.Collection.Shard0', is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group. For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online.

Answer 1

Googling around doesn't appear to get the exact article to pop-up, but it looks like there is documentation on how to handle "Always On" for the xConnect shards:

https://doc.sitecore.com/developers/93/platform-administration-and-architecture/en/walkthrough--configuring-always-on-for-the-xdb-collection-database.html

Step 1: Synchronize the collection_user logins for both the primary and the secondary databases.

Step 2 (this is the really important one): Update Sitecore.Xdb.Collection.ShardMapManager.__ShardManagement.ShardsGlobal table.

The ShardMapManager database is used to inform xConnect on how to read/write data to the collection shards. By default, it is pointing directly at the database server to which Sitecore was deployed. The ServerName column for the shards should be changed to the availability group listener (e.g. tcp:Shard0Listener, 5025)

Step 3 (you probably already did this): Update your collection database connection string to point to the listener.