Making sure that messages are not lost (logging)
WebSphere MQ records all significant changes to the data controlled by the queue manager in a log.
This includes creating and deleting objects (except channels), persistent message updates, transaction states, changes to object attributes, and channel activities. The log contains the information you need to recover all updates to message queues by:
- Keeping records of queue manager changes
- Keeping records of queue updates for use by the restart process
- Enabling you to restore data after a hardware or software failure
What logs look like
A WebSphere MQ log consists of two components:
- One or more files of log data
- A log control file
There are a number of log files that contain the data being recorded. You can define the number and size, or take the system default of three files. Each of the three files defaults to 4 MB.
When you create a queue manager, the number of log files you define is the number of primary log files allocated. If you do not specify a number, the default value is used.
If you have not changed the log path, log files are created in:
/var/mqm/log/QueueMgrNameWebSphere MQ starts with these primary log files, but if the log fills, it allocates secondary log files. It does this dynamically and removes them when the demand for log space reduces. By default, up to two secondary log files can be allocated. You can change this default allocation.
The log control file
The log control file contains the information needed to monitor the use of log files, such as their size and location, the name of the next available file, and so on.
Ensure that the logs created when you start a queue manager are large enough to accommodate the size and volume of messages that your applications will handle. You will probably need to change the default log numbers and sizes to meet your requirements.
Types of logging
In WebSphere MQ, the number of files that are required for logging depends on the file size, the number of messages you have received, and the length of the messages. There are two ways of maintaining records of queue manager activities:
- circular logging
- linear logging.
Circular logging
Use circular logging if all you want is restart recovery, using the log to roll back transactions that were in progress when the system stopped.
Circular logging keeps all restart data in a ring of log files. Logging fills the first file in the ring, then moves on to the next, and so on, until all the files are full. It then goes back to the first file in the ring and starts again. This continues as long as the product is in use, and has the advantage that you never run out of log files.
WebSphere MQ keeps the log entries required to restart the queue manager without loss of data until they are no longer required to ensure queue manager data recovery, and the logs files are released for reuse.
Linear logging
Use linear logging if you want both restart recovery and media or forward recovery (recreating lost or damaged data by replaying the contents of the log).
Linear logging keeps the log data in a continuous sequence of files. Space is not reused, so you can always retrieve any record logged from the time that the queue manager was created.
As disk space is finite, you might have to think about some form of archiving. It is an administrative task to manage your disk space for the log, reusing or extending the existing space as necessary.
The number of log files used with linear logging can be very large, depending on your message flow and the age of your queue manager. However, there are a number of files that are said to be active. Active files contain the log entries required to restart the queue manager. The number of active log files is usually the same as the number of primary log files as defined in the configuration files. (See Calculating the size of the log for information about defining the number.)
The key event that controls whether a log file is termed active or not is a checkpoint. A WebSphere MQ checkpoint is a group of log records containing the information to enable a successful restart of the queue manager. Any information recorded previously is not required to restart the queue manager and can therefore be termed inactive. (See Using checkpointing to ensure complete recovery for further information about checkpointing.)
You must decide when you no longer need inactive log files. You can archive them, or you can delete them if they are no longer of interest to your operation. Refer to Managing logs for further information about the disposition of log files.
If a new checkpoint is recorded in the second, or later, primary log file, the first file becomes inactive and a new primary file is formatted and added to the end of the primary pool, restoring the number of primary files available for logging. In this way the primary log file pool can be seen to be a current set of files in an ever-extending list of log files. Again, it is an administrative task to manage the inactive files according to the requirements of your operation.
Although secondary log files are defined for linear logging, they are not used in normal operation. If a situation arises when, probably due to long-lived transactions, it is not possible to free a file from the active pool because it might still be required for a restart, secondary files are formatted and added to the active log file pool.
If the number of secondary files available is used up, requests for most further operations requiring log activity will be refused with an MQRC_RESOURCE_PROBLEM return code being returned to the application.
Both types of logging can cope with unexpected loss of power, assuming that there is no hardware failure.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.