solidDB Help : Configuring and administering : Configuring and administering HotStandby : Special considerations for using solidDB with HotStandby : Running out of space for transaction logs
  
Running out of space for transaction logs
If a HotStandby (HSB) server is running in PRIMARY ALONE state, you must be careful that the server does not run out of disk space for transaction logs. In a non-HSB server, if you checkpoint frequently, then the transaction log does not grow large because after each checkpoint the server deletes the old transaction logs (that contain changes that occurred before the checkpoint). For more information about checkpointing, see Logging and checkpointing.
However, in an HSB server that is operating in PRIMARY ALONE state, the server must keep the transaction logs that have accumulated since the time that the primary server lost contact with the secondary server. If the secondary server is down for a long time, the server might keep a large amount of transaction log data that it would otherwise delete after each checkpoint. In a worst-case situation, if the secondary server 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 server 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 HotStandby.MaxLogSize. After the log reaches the specified total log size, the server automatically switches to STANDALONE state at the next checkpoint. In a diskless server, the state remains as PRIMARY ALONE, even though there is no disk writing at all.
If the server is set to STANDALONE state, the server no longer keeps all transactions logs since the time that the primary server lost contact with the secondary server. Without complete transaction logs, you cannot synchronize your system merely by connecting the primary server to the secondary server and allowing the secondary server to "catch up" by reading old logs. You have to copy the entire database from the primary server to the secondary server by using the netcopy command, see Copying a primary database to a secondary database over the network.
If a High Availability Controller (HAC) is used, the HAC identifies the issue, and resolves the situation by automatically performing the necessary actions.
Go up to
Special considerations for using solidDB with HotStandby