In-flight Transaction Recovery

EFA can recover in-flight (in-progress) transactions after a service restart or high-availability failover.

Overview

After a service restart or high-availability failover, EFA can recover in-flight transactions by rolling them back or rolling them forward. In-flight transactions are those that are outstanding in the execution log after a restart or a failover.

When transactions are rolled back, the requested action is undone.
When transactions are rolled forward, the requested action is completed.

By default, this feature enables the automatic recovery of Day-1 through Dan-N operations for tenant-related configurations. You can use the efa system feature update --inflight-transaction-auto-recovery disable command to disable the feature. When the feature is enabled, the recovery strategy is as follows.

Table 1. Recovery strategy
Operation type	Commands	Strategy
Create operations	efa tenant create efa tenant epg create efa tenant po create efa tenant service bgp peer create efa tenant service bgp peer-group create efa tenant vrf create	Roll back
Delete operations	efa tenant delete efa tenant epg delete efa tenant po delete efa tenant service bgp peer delete efa tenant service bgp peer-group delete efa tenant vrf delete	Roll forward
Update with add operations, such as port-add, ctag-range-add, and vrf-add	efa tenant update efa tenant epg update efa tenant po update efa tenant service bgp peer update efa tenant service bgp peer-group update efa tenant vrf update	Roll back
Update with delete operations, such as port-delete, vrf-delete, and ctag-range-delete	efa tenant update efa tenant epg update efa tenant po update efa tenant service bgp peer update efa tenant service bgp peer-group update efa tenant vrf update	Roll forward

Consider the following expected behaviors for this feature:

During operations that take a long time, such as drift and reconcile and firmware downloads, tenant operations and recovery operations are blocked.
When multiple transactions are pending in the execution log after a restart or a failover, recovery occurs in the order in which the operations appear in the execution log.
If a service restart or high availability failover occurs during transaction recovery, then the status of those recovery operations is changed to a normal status. For example, if a restart occurs during the rollback of an EPG, the status changes to delete-pending. There is no automatic recovery of interrupted recovery transactions. You must manually verify and address the status of such operations.

Important

Day-0 and administrative operations (those for the Inventory Service and Fabric Service) are not recovered automatically. If these operations are interrupted by a service restart or a failover, you must manually redo the operations.

Examples

This example enables automatic in-flight transaction recovery.

efa system feature update --inflight-transaction-auto-recovery enable
Feature Setting Updated Successful
--- Time Elapsed: 634.557118ms ---

This example disables automatic in-flight transaction recovery.

efa system feature update --inflight-transaction-auto-recovery disable
Feature Setting Updated Successful
--- Time Elapsed: 634.557125ms ---