Show TOC

Summary: High AvailabilityLocate this document in the navigation structure

If you are using TREX productively, the system has to be available for as much of the time as possible. Planned downtimes for maintenance and unplanned downtimes because of software errors should be reduced.

This section summarizes how to make searching and indexing highly available. The depicted measures are made on TREX server side and for the connection between TREX and the application. Measures that affect other software components or the hardware (highly available file servers, redundant network connection and so on) are not depicted.

High Availability for Searching

Searching is highly available in a system with master and slave servers. If a slave host goes down, TREX forwards search queries to the other slave hosts.

It can take up to a minute to switch to another slave host. During this phase TREX search queries may not be answered. An error message may be returned.

Note

If you have one master and two slave hosts, you can shut down one of the hosts for maintenance purposes (either the master or one of the slave hosts).

Measures on TREX side

  • Each master host has at least two slave hosts.
  • Each index is available on at least two slave hosts.
  • In systems with an HTTP connection: There are at least two Web servers.
  • In systems with an RFC connection: See RFC Connection inConnection to the Application.

Measure on the application side

Type of Application Measure

Java application

The Java client recognizes at least two name servers.

ABAP application

See RFC Connection inConnection to the Application.

High Availability for Indexing (Only with Queue Server)

If indexing takes place using queue servers, you can make indexing highly available. High availability means the following:

  • The application can send indexing requests to TREX.
  • The system automatically switches to a backup index or queue server if a master index or queue server goes down (failover). Failover is not possible in the following cases:
    • If there are network problems
    • If a file server goes down
    • If there are communication problems (application sends a request and receives no answer)

The switch to a backup index or queue server takes between 15 seconds and one minute. During this phase the system stores indexing requests in a cache and sends them to the backup server after the switch.

Measures on TREX side

  • There are at least two master name servers.
  • Each master index server has a backup index server (its own or one that it shares with the other master index servers).
  • Each master queue server has a backup queue server (its own or one that it shares with the other master queue servers).
  • If the integration of the delta index takes place using the Python scheduler: The Python scheduler is running on all hosts that are configured as master name servers.
  • If index replication takes place using the Python scheduler: The Python scheduler is running on all hosts that are configured as master name servers.
  • In systems with an HTTP connection: There are at least two Web servers.
  • In systems with an RFC connection: See RFC Connection inConnection to the Application.

Measure on the application side

Type of Application Measure

Java application

The Java client recognizes at least two name servers.

ABAP application

See RFC Connection inConnection to the Application.