After poking around in SSMS for a while I noticed that on the secondary replica there was a pause icon next to the Availability Databases. The primary had shown both were "green", but there was an option on the secondary to Resume Data Movement. I resumed the first database, and immediately the In Recovery status message was removed. A minute later it changed from Not Synchronizing to Synchronized, and everything worked as expected.
Here is a screenshot of the AG Databases after I fixed "Patch", but before fixing the test database:
Note you can also use TSQL on the secondary to resume replication on multiple database at the same time:
ALTER DATABASE [Patch] SET HADR RESUME;
ALTER DATABASE [test] SET HADR RESUME;
GO
This is completely expected. I've talked about this before but I'll recap it for you.
There could be multiples reason you are seeing this behavior. The two that most people are confused or inaccurate of how it works are how availability groups synchronize data and how queries on readable secondary replicas work.
Please note the below is ONLY pertinent for SQL 2012 and 2014, and to some extent 2016.
How Data Synchronization Works (brief overview)
There are two types of replica synchronization, synchronous and asynchronous. The way the data synchronization happens in both is exactly the same. The way that SQL Server behaves, though, is different. When synchronous is used we wait for the data to be HARDENED on the secondary replicas. This means it only needs to be acknowledged that it was successfully written to the log, not that the log block shave been successfully redone. Asynchronous does not wait for the status message and just continues.
Thus it is entirely working properly, however there seems to be a misunderstanding as to how it works. AGs ship log blocks, not transactions, thus the entire transaction may not be shipped together and may not even be redone yet.
Querying Readable Secondary Replicas
When you run a query on a secondary replica, the read committed (default) isolation level is silently mapped to snapshot isolation under the covers... whether or not you have SI or RCSI enabled for the database.
Since snapshot works by row versioning and is consistent from the beginning of the transaction, you may not be able to see new data as it comes in per how snapshot isolation works. This is entirely working as intended.
The other point to keep in mind is that just because you have the acknowledgement that the data was hardened to the log on the synchronous secondary replica does not mean that the REDO thread has redone those log blocks yet. Thus, just because you have an acknowledge on the primary doesn't mean REDO has completed on it, only that it has been hardened to the log. Additionally, if your redo thread is blocked it may take a long time (or never) to not be blocked and thus your redo queue size will grow.
In the end I can totally expect the behavior you are witnessing, however it doesn't mean that it isn't synchronous. It just means it doesn't necessarily work the way it was believe or thought to. Hopefully this clears the confusion.
Best Answer
What you're reading is referring to changing the failover mode of an availability group replica:
At this point you'll want to set the failover mode to manual. Voila!
I assume you're doing an in place upgrade by the nature of the question, so to answer your other concerns:
Removing the secondaries from the availability group would effectively do the same thing (can't fail over when there's nothing to fail over to...) but only changing the failover mode lets you keep more of the existing architecture in place without having to re-seed every replica all over again.
You also could disable the entire availability group feature in Configuration Manager, but I think that requires a restart of the service and requires you to completely setup availability groups from scratch.