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