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