When you use HotStandby, if you put a server in PRIMARY ALONE state, you must be careful that it does not run out of disk space for transaction logs. In a non-HotStandby server, if you checkpoint frequently, then the transaction log does not grow large because after each checkpoint the server deletes the old transaction logs.

In particular, the non-HotStandby server deletes the logs with the data changes that occurred before the checkpoint. For more information about checkpointing, see solidDB^® Administration Guide.

However, in a HotStandby server that is operating in PRIMARY ALONE state, the server must keep the transaction logs that have accumulated since the time that the Primary lost contact with the Secondary. If the Secondary is down for a long time, the server might keep a large amount of transaction log data that it would otherwise throw away after each checkpoint. In a worst-case situation, if the Secondary cannot be brought back up in a reasonable time and there is not enough disk space to store all the transactions that occur, the Primary transaction logs can fill up all of the available disk space. When the disk is full, the server switches to read-only mode.

To prevent running out of disk space for transaction logs, you can control the log size with the parameter MaxLogSize. After the log reaches the specified total log size, the server automatically switches to the STANDALONE state at the next checkpoint. In a diskless server, the state remains PRIMARY ALONE, even though there is no disk writing at all.

If the server is set to the STANDALONE state, it no longer keeps all transactions logs since the time that the Primary lost contact with the Secondary. Without complete transaction logs, you cannot synchronize your system merely by connecting the Primary to the Secondary and allowing the Secondary to “catch up” by reading old logs. You have to copy the entire database from the Primary to the Secondary by using the copy or netcopy command.

If HAC is used, it identifies the situation described above, and leads the servers to the ACTIVE state by automatically performing the necessary actions.