The latest update contains some new features and important bug fixes that increase the reliability of the database server.
At this point it should be mentioned again that the current server can also be used together with older clients such as 5.5 or 5.6 (with all client versions from 4.7).
Shorter update interval
Previously, there was a standard interval of 60 seconds between two update events in which changed data was written from the cache to the database. Shortening this interval to 30 seconds leads to a better distribution of write operations over time. The I/O volume per update event is reduced, resulting in fewer heavy load peaks on the storage unit.
Acceleration of cache recovery
The reading of the cache content after opening the database has been accelerated. By combining I/O operations, an increase in speed by a factor of 3 to 10 is achieved in most cases. Update events now also take place during a longer read-in process; previously the cache recovery blocked the updates.
Preload the cache
If no valid .cache file is found for the cache restore, the entire database can optionally be read into the buffer. This option must be set separately in the database configuration of the server (the option is switched off by default). If the buffer is smaller than the database content, segments with a higher access probability (tree roots and nodes) are primarily loaded into the buffer. This option is useful if either the cache is similar in size to the database or the cache size is several gigabytes – in this case, filling the cache through normal database operations can take hours or days.
Hot standby synchronization
Update events are now also active during HSB synchronization. As the database is in read-only mode during synchronization, the update data is written to the current .tl file (just like during a backup event). This improvement is particularly important for a longer synchronization to avoid data loss in the event of a server failure during this process.
If a synchronization is started directly after opening the database, the cache recovery is also carried out at the same time, as the entire database is read anyway.
With an HSB configuration, the database is now always opened in read-only mode first. Only after checking the synchronization status is the database switched to write mode. This avoids unnecessary synchronization processes that could occur if the database was immediately switched to read-only mode after being opened in read-write mode.
Error correction during rollback
With all previous 5.7 server versions, the error entry “Transaction log file TL? has no valid blocks” could occur after opening an incomplete database during rollback, even though valid data is available in the .tl file. In extreme cases, database errors could be detected during the subsequent diagnosis with Recover or data loss could occur. This error should therefore be classified as critical. To avoid such a situation, we recommend updating all installed 5.7 servers to version 5.7.07.