Storing persistent application status

We can store persistent status information relating to applications along with other queue manager data.

Each IBM MQ queue manager has a dedicated filesystem for its persistent state, which includes both its queue data and recovery log. In an RDQM configuration the filesystem is backed by a logical volume that is replicated between the Linux systems (nodes). The filesystem includes a userdata directory that we can use to store persistent status information for the applications. So, when a replicated data queue manager moves to run on another node in your RDQM configuration, you have application context available as well as queue manager context. See Directory content on Unix and Linux Systems.

If you choose to store application state in the userdata directory, we must be aware that data written to this location might consume the available disk space allocated to the queue manager. We must ensure that sufficient disk space remains available for the queue manager to write queue data, logs, and other persistent state information.

The userdata directory has mqm user and group ownership, and it is world readable so users can access it without needing to be in the IBM MQ administrator group (that is, mqm). We cannot modify the permissions of the userdata directory, but we can create content in it with whatever ownership and permissions you require.

During an RDQM queue manager failover the queue manager is ended, and its filesystem is unmounted on its current RDQM node. The filesystem is then mounted and the queue manager restarted on another node in the RDQM configuration. A filesystem cannot be unmounted if a process has an open handle for one of its files. To ensure a queue manager failover can complete, if the queue manager filesystem cannot be unmounted then processes that have an open file handle are sent a SIGTERM signal, followed by a SIGKILL if the open handles are not released. Your applications must be designed to respond correctly to SIGTERM. If applications or processes are configured as a queue manager service then, during a managed failover, they can be ended during queue manager shutdown before the filesystem is unmounted. If an application or process is not configured as a queue manager service, or an unmanaged failover occurs, such as a loss of quorum, then it is likely that signals will be sent to release the filesystem.

Parent topic: Create a disaster recovery RDQM