Rejoining Old Primary as Secondary in SQL Server Always On Availability Group Post Forced Failover

Encountering synchronization issues after a forced failover in a three-node SQL Server Always On Availability Group setup.

I am facing a challenge in a SQL Server Always On Availability Group setup with a three-node configuration. Initially, node-1 was the primary node, and nodes-2 and -3 were secondary nodes.

A network failure occurred, causing node-1 to disconnect from the other two nodes. To address this, I performed a forced failover to node-2 using the command ALTER AVAILABILITY GROUP AG_NAME FORCE_FAILOVER_ALLOW_DATA_LOSS. Consequently, node-2 became the new primary node, and write operations continued.

Meanwhile, node-1, unaware of the forced failover, also continued its write operations independently.

Upon recovery from the network failure, attempting to rejoin node-1 to the availability group as a secondary node using the standard commands (ALTER AVAILABILITY GROUP [AG_NAME] SET (ROLE = SECONDARY); and ALTER DATABASE [AG_DB_NAME] SET HADR RESUME;) did not resolve the synchronization issue as outlined in the https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/perform-a-forced-manual-failover-of-an-availability-group-sql-server?view=sql-server-ver16#FollowUp:%7E:text=After%20a%20forced%20failover%2C%20all,the%20synchronous%2Dcommit%20secondary%20databases.:~:text=After%20a%20forced%20failover%2C%20all,on%20the%20new%20primary%20database.https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/perform-a-forced-manual-failover-of-an-availability-group-sql-server?view=sql-server-ver16#FollowUp:%7E:text=After%20a%20forced%20failover%2C%20all,the%20synchronous%2Dcommit%20secondary%20databases.:~:text=After%20a%20forced%20failover%2C%20all,on%20the%20new%20primary%20database.

While it is acceptable to lose data on the old primary node, I am seeking a solution to rejoin it to the new primary without resorting to a fresh node approach, which involves dropping the entire database. Considering the substantial data size (5-6TB), such an approach is not feasible.

Any recommendations or solutions to address this issue would be highly appreciated. Thank you.