BufferToDiskMin
The task of BufferToDiskMin is to make a minimum usage of the hard drive disc capacity and still guarantee a sufficient protection from data loss.
Buffer behavior depending on the connection status
This section describes the behavior of the buffer process with BufferToDiskMin depending on the actually connection status to the database.
Normal mode
If the connection to the database is established, the data blocks are buffered in RAM for a short term and then they are written immediately into the database.
Connection interruption between the RDB manager and the database
The data are buffered in RAM until there is enough memory space in RAM. After reaching the limit of space in RAM, new data are buffered on hard drive disc only.
Connection establishment between RDB manager and the database
The buffered data blocks are written in the same order into the DB, in which they were buffered. That means, that at first the oldest data from RAM are written into the database and not till then the data from the local HDD.
Breakdown of the RDB manager
If the cause for a breakdown was for example a software error, which shut down the RDB manager correctly, BufferToDiskMin starts a process which writes the saved data blocks from RAM onto HDD. The data are displaced from the RAM into a created buffer dictionary on the HDD in what way no data get lost.
If the cause for a breakdown was a power failure, hardware error or something like that, what shuts down the RDB manager abrupt, is a data loss unavoidable. The whole data blocks from RAM cannot be saved.
Re-start of the RDB manager after breakdown
If after re-start of the RDB manager also the connection to the database is re-established, the RDB manager checks whether the data blocks had been saved on the HDD just in time. In that case they will be written into the database.
In the event of a crash of a redundant RDB, the data is buffered on both systems. Thus the data are not written twice into the database, the passive RDB checks the first and the last entry in a block. If both are already present in the database, they are not written again to the database. If one of the entries is misssing, the block is written into the database. This procedure is precessed only if the RDB is passive and blocks were present on the hard disc at the start of the RDB. This mode is executed until all - available at the start of the RDB - disc buffers have been processed.
If the RDB is re-started without a connection to the database, the data blocks are buffered the same principle like in case of a breakdown, till the connection can be re-established.
Indicator of the buffer behavior
The following figure shows you the interplay of RAM and the local HDD during a data transmission. In the internal data point bufferToDiskIndicator you can see which buffer behavior is actually used.
bufferToDiskIndicator = 0
Buffered data blocks can be worked off fast enough and written in the database. As soon as there are free blocks in the memory, the indicator is set to 0. If there are more free data blocks in the memory as on the HDD, the indicator will be also set to 0.
Causal: stable connection; no necessity to save data onto HDD
bufferToDiskIndicator = 1
Data blocks cannot be stored in cause of a lack of memory in RAM and are saved on HDD.
Causal: data flow, database disconnection
bufferToDiskIndicator = 2
Buffered data blocks are written into the database in chronological order.
Causal: DB connection is re-established
