MQ sets all queues
ManagementImportant changes to the data controlled by the device to the log. This includes creating and deleting objects (except channels), persistent message updates, transaction statuses, modifying object attributes, and channel activities. The log contains the information required to restore updates to all message queues through the following operations:
1. record changes made by the queue manager
2. Record of the queue update used by the restart process
3. Ability to recover data after hardware and software faults
What is a log?
The webspheremq log contains two components:
1. One or more log files
2. Log Control File
There are many log files containing the data to be recorded. You can define the quantity and size, or use three system default files.
In WebSphere MQ windows, all three files are 1 MB by default. In WebSphere mq unix, all three files are 4 MB by default.
When creating a queue manager, you define the number of log files as the number of allocated master log files. If no value is specified, the default value is used.
In WebSphere MQ windows, if the Log Path is not changed, create a log file in this directory:
C: Program filesibmwebsphere mqlog <qmgrname>
In WebSphere mq unix, if the Log Path is not changed, create a log file in this directory:
/Var/MQM/log/qmname
WebSphere MQ starts with these main log files, but when the logs are full, the log files will be allocated. It completes this operation dynamically and removes them when it requires less log space. By default, a maximum of two log files can be allocated.
Log control file:
1. The log control file contains the information required to monitor the use of log files, such as their size and location, and the name of the next available file.
Note: Make sure that the logs created when the queue manager is started are large enough to accommodate the size and amount of messages to be processed by the application. You may need to change the default log count and size to meet your requirements.
Determine whether the queue manager should use a loop or a linear log record. You need to estimate the log size required by the queue manager. The Log Size is determined by the following log configuration parameters:
Logfilepages
Size of each master and secondary log file in a 4 K page unit
Logprimaryfiles
Pre-allocated master log files
Logsecondaryfiles
Number of log files that can be created the next day (used when the main log file is full)
Displays the amount of data that the queue manager records for various logs. Most Queue Manager operations require the minimum log space. However, when a persistent message is put into the queue, all message data must be written into the log so that it can restore the message. Generally, the log size depends on the number and size of persistent messages to be processed by the queue manager.
Operation size
Add 750 bytes of persistent message + message length
For large messages, the segments are separated into 15700 bytes. Each segment can have an overhead of 300 bytes.
Get 260 bytes of message
Synchronization point: Submit 750 bytes
Synchronization point: Roll back 1000 bytes + 12 bytes (each get or put to be rolled back)
Create an object in 1500 bytes
Delete 300 bytes of an object
Change attribute 1024 bytes
Recording Media image 800 bytes + image
The image is separated into 260 bytes. Each segment has an overhead of 300 bytes.
Checkpoint: 750 bytes + 200 bytes (The unit of work for each activity)
Other data can be recorded for any uncommitted put or retrieved (cached for performance reasons.
Note:
1. When the queue manager is started, you can change the number of main and next-day files.
2. You cannot change the log file size. You must confirm the size before creating the queue manager.
3. The number and size of the main log files determine the amount of pre-allocated log space when the queue manager is created. Organize the space into a small number of large log files instead of a large number of small log files.
4. The total number of master and secondary log files cannot exceed 63 of the long-term running transactions. It limits the number of log spaces available for the queue manager to restart and restore. The volume of log space required for media recovery by the queue manager does not share this limit.
5. When cyclic logging is used, the queue manager reuse the primary log space. This means that the log of the queue manager can be smaller than the amount of data that needs to be recorded by the queue manager you estimate. When the log file is full, the queue manager allocates a log file (up to the limit) and the next primary log file in the sequence is unavailable.
6. The main log file can be used for reuse during the checkpoint. Because the log space is reduced, the queue manager considers the Primary and Secondary log space before using the check point.
If you do not define more master log files than the secondary log files, the queue manager can allocate the secondary log files before using the check point. This allows the winner log file to be reused.
Log Record type
In WebSphere MQ, the number of files required for logging depends on the file size, the number of messages you receive, and the message length. There are two ways to maintain the queue manager activity records: loop logging and linear logging.
Cyclic Logging
If you only want to restart the recovery, use the cyclic log record and use the log rollback system to stop ongoing transactions.
Loop logs keep all restart data in the log file loop. The log records are filled with the first file in the ring, then moved to the next file, and so on until all the files are full. Then it returns to the first file in the ring and starts logging again. As long as the product is in use, it will continue and has the advantage of never using up log files.
WebSphere MQ retains the log entries required to restart the queue manager without losing data until they are no longer needed to ensure data recovery in the queue manager. :) Linear Logging
If you want to restart recovery and media or Forward Recovery (re-create lost or corrupted data through replay log Content), use linear logging.
Linear log records store log data in consecutive file sequences. It does not reuse space, so you can always retrieve any recorded records from the time when the queue manager was created.
Because the disk space is limited, you may need to consider some form of archiving. Manage the disk space of the task management log and reuse or expand the existing space if necessary.
The number of log files used together with linear logging can be very large, depending on your message stream and the life of your queue manager. However, many files are active. The activity file contains the log entries required to restart the queue manager. The number of active log files is usually the same as the number of master log files defined in the configuration file.
Checkpoint is a key event that controls whether a log file is active. The WebSphere MQ checkpoint is a set of logs that contain information about the successful restart of the queue manager. Restarting the queue manager does not require any previously recorded information, so it can be called inactive.
You must determine when non-inactive log files are no longer needed. If you are not interested in them, you can compress or delete them.
If the new checkpoint is recorded in the secondary log file or later recorded in the primary log file, the first file becomes inactive, in addition, the new master file is formatted and added to the end part of the master pool, and the number of available master files is restored. In this method, the master log file pool can be considered as the current file set in the log file extension list. It also manages the management tasks of inactive files according to your operation requirements.
Although the secondary log files are defined for linear logs, they are not used in normal operations. If this happens (possibly due to the long service life of the transaction), it is impossible to release the file from the active pool, because it may still need to be restarted, the file is formatted and added to the active Log File pool.
If the number of available files is used up, most of the requests that require further operations of log activity will be rejected with the return code of mqrc_resource_problem returned to the application.
Both types of log records can cope with unexpected power outages (assuming there is no hardware fault ).
The queue manager rolls back the transactions that consume too much log space. Applications that use this method to roll back their transactions cannot perform subsequent mqput or mqget operations. The two operations specify the synchronization point under the same transaction. In this status, the mqrc_backed_out is returned if you try to put or retrieve the message at the synchronization point. Next, this application can send mqcmit, which returns mqrc_backed_out or mqback and starts a new transaction. A transaction that consumes too much log space is rolled back, its log space is released, and the queue manager continues to operate normally.
If the log is filled, amq7463 is sent. In addition, if logs are filled due to the long-term running of transactions that have protected the space to be released, the message amq7465 is sent.
Finally, if the log writing speed is faster than that of the asynchronous internal processing process, the message amq7466 is sent. If you see this message, increase the number of log files or reduce the data volume to be processed by the queue manager.
What happens when the disk is full
The log record component of the queue manager can handle full disk and full log files. If the disk containing logs is full, the queue manager sends the amq6708 message and generates an error record.
Log files are created at the maximum size, rather than extended when logs are written to them. This means that the disk space can be used up only when new files are created, and the disk space cannot be used up when logs are written to logs. WebSphere MQ always knows how much space is available in existing log files and manages the space in these files.
If you fill in the drive containing these log files, some disk space may be released. If you use linear logs, there may be some inactive log files in this log directory, and these files can be copied to another drive or device. If you still have used up disk space, check whether the log configuration in the queue manager configuration file is correct. You can reduce the number of primary or secondary log files so that logs do not occupy too much space. You cannot change the log file size of the existing queue manager. The queue manager assumes that all log files are of the same size.
Manage log files
If you use cyclic logging, make sure that there is sufficient space in the configuration system to save these log files (see "WebSphere MQ log default" and "Queue Manager Log "). The disk space used by logs (including the space of the files to be created (if required) is not increased to a size that exceeds the configured size.
If you use linear logs, log files are added continuously when data is recorded, and the disk space used increases over time. If the data rate to be recorded is high, the new log file will quickly consume disk space.
After a period of time, the old log files that are logged linearly are no longer needed when you restart the queue manager or perform media recovery for any corrupted objects. The queue manager periodically sends a message pair to indicate which log files are required:
* Message amq7467 provides the oldest log file name required to restart the queue manager. This log file and all newer log files must be available during the queue manager restart.
* The message amq7468 provides the oldest log file name required for media restoration.
Any log files older than these files do not need to be online. You can copy them to an archive medium (such as a tape for disaster recovery) and remove them from the active log directory. Any log files required for media recovery (not restart) can also be detached into a compressed file.
If no log file is found, an amq6767 operator message is sent. Enable the queue manager to use log files and all subsequent log files, and retry this operation.
Note:
When restoring media, all necessary log files in the log file directory must be available at this time. Make sure that you use the conventional media image of any object and you may want to use it for restoration to avoid retaining all necessary log files and consuming disk space.
When running the rcdmqimg command, messages amq7467 and amq7468 may also be sent. For more information about this command, see rcdmqimg (recording media images ).
Log File Location
When selecting the location of the log file, remember that this operation will be seriously affected if WebSphere MQ cannot format the new log due to the lack of disk space.
If you use cyclic logs, make sure that there is at least enough space on the drive for the configured primary log file. At least one log file is retained. If the log grows, it is needed.
If you use linear logs, a considerable amount of space is allowed. When you record data, the space consumed by logs is continuously increased.
It is best to place log files and Queue Manager data in different disk drives. This is beneficial to performance. You can also store log files in multiple disk drives in the image arrangement. This protects the drive that contains this log to avoid faults. If there is no image, it will force you to return to the last one of your WebSphere MQ System
Backup.
