Transaction Handling after Failover or Restart

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.
This feature is disabled by default. You can use the efa system feature update --inflight-transaction-auto-recovery enable command to enable automatic recovery of Day-1 through Day-N operations for tenant-related configurations. When you enable this feature, 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 are blocked. This blockage applies also to recovery operations.
  • 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

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 ---