About the High Level State of TimesTenClassic Objects

The TimesTen Operator keeps track of the high level state of TimesTenClassic objects in replicated and non-replicated configurations. For replicated TimesTenClassic objects, the high level state describes the TimesTen databases in an active standby pair. Since each TimesTen database in a non-replicated configuration is independent, the high level state for non-replicated TimesTenClassic object describes the health of the replicas of TimesTen databases. For example, if all replicas for the TimesTenClassic object are up and running and functioning properly, the high level state is AllReplicasReady. Use kubectl get events or kubectl get ttc to monitor the state of TimesTenClassic objects.

The following table shows the high level states for TimesTenClassic objects and indicates if the state is supported for replicated or non-replicated objects or both:

State	Replicated Objects	Non-Replicated Objects
ActiveDown	Y	N
ActiveTakeover	Y	N
AllReplicasReady	N	Y
BothDown	Y	N
ConfiguringActive	Y	N
Failed	Y	Y
Initializing	Y	Y
ManualInterventionRequired	Y	Y
NoReplicasReady	N	Y
Normal	Y	N
Reexamine	Y	Y
SomeReplicasReady	N	Y
StandbyCatchup	Y	N
StandbyDown	Y	N
StandbyStarting	Y	N
WaitingForActive	Y	N

ActiveDown

If the TimesTen Operator detects that TimesTen in the Pod containing the active database has failed, then the TimesTenClassic object immediately enters the ActiveDown state.

The unreachableTimeout timeout value controls how long the state of the Pod containing the active database can be Unknown before the TimesTenClassic object's state becomes ActiveDown.

When the TimesTenClassic object's state becomes ActiveDown, the standby database immediately becomes the active, and the state of the TimesTenClassic object becomes StandbyDown.

ActiveTakeover

When the TimesTenClassic object is in the Normal state, and the standby database goes down, the state briefly changes to ActiveTakeover.

When AWT cache groups are used, the standby is normally responsible for pushing updates from TimesTen to Oracle Database. However, if the standby fails, the active database takes over this responsibility. This occurs during the ActiveTakeover state.

AllReplicasReady

For a non-replicated TimesTenClassic object, all replicas are ready and available. The TimesTen databases are up and running and functioning properly.

BothDown

Neither the active nor the standby database is functioning properly. The TimesTen Operator attempts to bring up the pair of databases.

If both Pods in the active standby pair fail, the TimesTen Operator uses the information in TimesTenClassicStatus to minimize data loss. See About the BothDown State.

ConfiguringActive

When the TimesTenClassic object is in the WaitingForActive state, and when the database that should be the active database comes up, the TimesTenClassic object enters the ConfiguringActive state. The TimesTen Operator then configures this database to be the active. Once the database is configured as the active, the TimesTenClassic object enters the StandbyDown state. See About the BothDown State.

Failed

If a problem occurs while Initializing a TimesTenClassic object, the object transitions to the Failed state. Once in this state, the TimesTen Operator does not attempt to repair the object. You must delete it. Use the kubectl get events command to determine the cause of the problem and then recreate the object.

Initializing

After you create a TimesTenClassic object, the TimesTen Operator creates the Kubernetes StatefulSets and Secrets that are required for the TimesTenClassic object. As the TimesTen Pods are starting up, the TimesTen Operator assigns the initializing state to the TimesTenClassic object.

ManualInterventionRequired

When a TimesTenClassic object enters the ManualInterventionRequired state, the TimesTen Operator takes no further action for the object. It does not query the TimesTen agents associated with the object to determine the state of TimesTen and it does not command TimesTen to do anything.

For replicated TimesTenClassic objects, see About the ManualInterventionRequired State for Replicated Objects and About Bringing Up One Database.

NoReplicasReady

For a non-replicated TimesTenClassic object, there are no replicas ready or available. TimesTen databases are not running.

Normal

For replicated objects, the Normal state indicates that TimesTen databases are up and running and functioning properly.

Reexamine

When a TimesTenClassic object is in the ManualInterventionRequired state, you can specify the .spec.ttspec.reexamine datum to cause the TimesTen Operator to take over management of the object. The TimesTen Operator moves the object to the Reexamine state. The Operator then examines the state of TimesTen.

For a replicated TimesTen Classic object, the TimesTen Operator does the following:

If you correctly repaired TimesTen, the Operator moves the TimesTenClassic object to either the Normal or StandbyDown state, depending on the nature of your repair.
If you did not correctly repair TimesTen, the Operator moves the TimesTenClassic object to the ManualInterventionRequired state.

For a non-replicated TimesTenClassic object, the TimesTen Operator does the following:

If you correctly repaired TimesTen, the Operator moves the TimesTenClassic object to the AllReplicasReady state.
If you did not correctly repair TimesTen, the Operator moves the TimesTenClassic object to the ManualInterventionRequired state.

SomeReplicasReady

For a non-replicated TimesTenClassic object, some but not all replicas are ready and available.

StandbyCatchup

This state is entered after the StandbyStarting state. During the StandbyStarting state, the standby copies the active database to the standby Pod. When the duplicate process is complete, the state changes from StandbyStarting to StandbyCatchup. See StandbyStarting. In the StandbyCatchup state, the duplicate process has completed. Transactions that ran during this duplicate process must now be copied over to the standby. Thus the StandbyCatchup state is the state when the newly created standby catches up to any transactions that ran on the active while the duplicate operation was running. Applications can continue to use the active without restriction.

StandbyDown

The active database is functioning properly, but the standby database is not. The TimesTen Operator automatically attempts to restart and reconfigure the standby database. Applications can continue to use the active database without restriction.

StandbyStarting

The standby is duplicating the database from the active. The StandbyStarting state is complete when the duplicate operation completes. The StandbyCatchup state is then entered. See StandbyCatchup. Applications can continue to use the active without restriction.

WaitingForActive

When the TimesTenClassic object is in the BothDown state, if the TimesTen Operator can determine which database contains the most up-to-date data, the TimesTenClassic object enters the WaitingForActive state. The object remains in this state until the Pod that contains the database is running, and the TimesTen agent within the tt container (within that Pod) is responding to the TimesTen Operator. See About the BothDown State.