Simultaneous SQL client aborts may trigger database restart
Details
| Detail name | Value |
|---|---|
| Changelog Number | 5023 |
| Type | Bug |
| Status | Open |
| Affected Versions | EXASOL 6.0.0, Exasol 6.1.0, Exasol 6.2.0, Exasol 7.1.0 |
Description
In very rare cases, the database is restarted due to a failed internal consistency check. This problem only seems to occur when multiple SQL client processes are aborted simultaneously. This can be done by the user (eg, client abort or query timeout) or by the database itself (eg, to meet some internal conditions such as memory usage limitations). The frequency of this problem depends on the number of database nodes and the number of SQL Client abortions per hour. This problem has not yet been reproduced and is very rare.
Workaround:
Currently, the dbram consistency check is executed after every SQL process abort within a server process of the database. If this check fails, the database reports an error and triggers a restart for security reasons (avoid data corruption).
A refinement of this consistency check has been implemented. This partial check will be executed after each SQL process cleanup (not only after a SQL process abort) inside the SQL process itself. If this new check fails, the SQL process is aborted immediately and an automatic recovery mechanism tries to clean this process properly in the database. In this way, the restart of the database can be prevented if the recovery mechanism is successful.
This workaround can be activated manually with the command line parameter "-checkSlbClient=1". This command line parameter is available beginning with the following versions: Exasol 6.1.11, Exasol 6.2.9, Exasol 7.0.0
