INSERTquery is executed 10 times on the “test” database.
SELECT COUNT(*) AS '# of transaction logs' FROM fn_dblog(null, null)
WHERE database_id=6 AND is_local=1
SELECT replica_id, replica_server_name
(SELECT replica_id FROM sys.dm_hadr_database_replica_states WHERE database_id=6 AND is_local=1)
SELECT COUNT(*) AS '# of entries in testt1 table' FROM testt1
INSERTclause 10 times.
INSERT INTO testt1 (NAME, ID) VALUES ('John Smith', 1)
INSERTexecutions. The increase of entries in the ‘test’ database also reflects that 10 rows are inserted into the table.
ALTER AVAILABILITY GROUP TIWENAG2 FORCE_FAILOVER_ALLOW_DATA_LOSS
FORCE_FAILOVER_ALLOW_DATA_LOSSon the secondary replica on the secondary AG (TIWENVM4), the database is synced even though the previous forwarder is currently unavailable, as the global primary keeps track of the unsynchronized part of transaction logs of the secondary replica on the secondary AG.
FORCE_FAILOVER_ALLOW_DATA_LOSS, there’s no data loss during the failover.
FORCE_FAILOVER_ALLOW_DATA_LOSSand the previous primary replica (in this case, TIWENVM3) is brought back, data movement will not resume automatically and needs to be resumed manually. This behavior is by design and not limited to the distributed AG scenario but applies whenever failover with
FORCE_FAILOVER_ALLOW_DATA_LOSSis performed. This is because there might be difference and even conflicts between the previous primary replica and the new primary replica, and user needs to manually choose which version to keep.
FORCE_FAILOVER_ALLOW_DATA_LOSSin the secondary AG doesn’t cause data loss, it’s not guaranteed that there’ll be no data loss when using this option to perform failover in a distributed AG. For example, if the primary AG is lost, there might be data loss when a force failover is performed in the secondary AG. This behavior is expected, and the cases that might cause data loss are not limited to this example.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.