About the ManualInterventionRequired State

When a TimesTenClassic object enters the ManualInterventionRequired state, the Operator takes no further action for this object. It does not query the TimesTen agents associated with the object to determine the state of TimesTen and does not command TimesTen to do anything. It is important for you to address why the TimesTenClassic object is in this state.

If your TimesTenClassic object is in the ManualInterventionRequired state and it is not the result of it first being in the BothDown state, perform the operations necessary to manually repair one of the databases. Then, perform the steps to bring up this database. These steps are covered in About Bringing Up One Database later in this chapter.

If, however, the TimesTenClassic object is in the ManualInterventionRequired state as a result of it first being in the BothDown state:

  • It may be unclear which database, if either, is suitable to be the new active. There may be transactions that have committed on the active database and not on the standby database, and simultaneously there may be transactions that have committed on the standby database and not on the active database.

  • You need to manually examine both databases and may need to reconcile the data before you can choose which database should be the new active.

  • If you can reconcile the data, and can manually fix one of the databases, then you can perform the steps to bring up one database. These steps are covered in About Bringing Up One Database later in this chapter. If you cannot reconcile the data, contact Oracle Support for further assistance.

In order for you to direct the Operator to move the TimesTenClassic object out of the ManualInterventionRequired state, you must either:

  • Bring up exactly one database: The Operator treats this database as the active database. All of these conditions must be met:

    • The TimesTen agent in the container is running.

    • The TimesTen the instance in the container is running.

    • The TimesTen database is loaded.

    • There is no replication scheme in the database.

    • The replication agent is not running.

    • The replication state is IDLE.

    If these conditions are met, the Operator moves the TimesTenClassic object to the StandbyDown state. If any of these conditions are not met, the TimesTenClassic object remains in the ManualInterventionRequired state. Note that when no replication scheme exists in the database, the Operator will still create the appropriate replication scheme based on how it is defined in the TimesTenClassic object definition. See About Bringing Up One Database for an example of how you can direct the Operator to take action once one database is up and running.

  • Bring up both databases: In this case, you must configure the active standby pair. Specifically, each database must meet all of the following conditions:

    • The TimesTen agent in the container is running.

    • The TimesTen instance in the container is running.

    • The database is loaded.

    • The replication scheme is defined in both databases.

    • The replication agents are started and are running.

    • One database must be in the ACTIVE state and the other database must be in the STANDBY state.

    If these conditions are met, the Operator moves the TimesTenClassic object to the Normal state. If any of these conditions are not met, the TimesTenClassic object remains in the ManualInterventionRequired state.

If you cannot bring up either database, the TimesTenClassic object remains in the ManualInterventionRequired state.

You direct the Operator to examine the databases by specifying the .spec.ttspec.reexamine datum. Every .spec.ttspec.pollingInterval, the Operator examines the value of .spec.ttspec.reexamine. If the value has changed since the last iteration for this TimesTenClassic object, the Operator examines the state of the TimesTen containers for this object. See TimesTenClassicSpecSpec for more information on the .spec.ttspec.pollingInterval and the .spec.ttspec.reexamine datum.

The examination of the databases is performed exactly one time after you change the .spec.ttspec.reexamine value. If the required conditions were not met, you may again attempt to meet them. You must then modify the .spec.ttspec.reexamine value again to cause the Operator to reexamine the databases.

Note that whenever a TimesTenClassic object changes state, a Kubernetes Event is created. You can monitor these events with the kubectl describe command to be informed of such state transitions.