Misunderstanding #1: After server failover, ongoing transactions continue to be executed
Of course this is wrong!
Each failover is accompanied by some form of recovery. However, if the transaction being executed does not have a Commit, the connection is disconnected because the server or instance crashes, SQL Server cannot re-establish the transaction context on the Server after the Failover and continue executing the transaction-whether you are using a cluster, image, log transmission or SAN replication method.
For a Failover cluster, when a Failover occurs, one SQL Server instance is started on the node of another failover cluster. Databases on all instances must go through the Recovery phase-that is, all transactions without a Commit will be rolled back.
For database images, logs from the master server are continuously transferred to the backup server for Redo operations. When the backup storage is switched to the primary server, the transaction log of the original backup storage is changed to the Recovery mode, which makes it as if the original backup storage experienced a crash, after that, all connections will be directed to the original backup storage.
For transaction log transfer, transaction logs are regularly backed up and transferred to the secondary server. when the primary server crashes, the DBA restores the secondary server and goes online. however, the final step is to execute the rediscovery step, that is, to roll back the uncommitted transactions.
For SAN replication, the I/O of the local SAN is copied to the Remote SAN for replay. When a Failover occurs, the system will connect to the Remote SAN, but the database still needs to perform the rediscovery step, this is very similar to the Failover cluster.
The "unique" technology enables ongoing transactions to continue execution after failover using virtualization technology with real-time migration features, the connection itself does not know that the object to be connected has changed to another physical server.
However, no matter which technology is used, if the "connection" fails, the ongoing transactions will be lost, so this part of the work to deal with such problems needs to implement some "re-Execute" function with code in the program.