backup queue manager

Download Backup Queue Manager

Post on 09-Mar-2015

264 views

Category:

Documents

6 download

Embed Size (px)

TRANSCRIPT

Backup Queue Manager Creating a backup queue manager ======================== 1. Create a backup queue manager for the existing queue manager using the control command crtmqm. The backup queue manager requires the following: * To have the same attributes as the existing queue manager, for example the queue manager name, the logging type, and the log file size. * To be on the same platform as the existing queue manager. * To be at an equal, or higher, code level than the existing queue manager. 2. Take copies of all the existing queue managers data and log file directories, including all subdirectories, as described in Backing up queue manager data. 3. Overwrite the backup queue manager's data and log file directories, including all subdirectories, with the copies taken from the existing queue manager. 4. Execute the following control command on the backup queue manager: strmqm -r BackupQMName This flags the queue manager as a backup queue manager within WebSphere MQ, and replays all the copied log extents to bring the backup queue manager in step with the existing queue manager. Starting a backup queue manager ======================= 1. Execute the following control command to activate the backup queue manager: strmqm -a BackupQMName The backup queue manager is activated. Now active, the backup queue manager can no longer be updated.

2. Execute the following control command to start the backup queue manager: strmqm BackupQMName 3. Restart all channels Note: stop the existing Qmgr using endmqm -w, before copying the qmgr date to backup qmgr

MQSeries Triggering Questions What is Triggering? Ans: Web Sphere MQ enables you to start an application automatically when certain conditions on a queue are met. For example, you might want to start an application when the number of messages on a queue reaches a specified number. This facility is called triggering How many ways of Triggering? EVERY: A trigger event occurs every time that a message arrives on the application queue. Use this type of trigger if you want a serving program to process only one message, then end. FIRST: A trigger event occurs only when the number of messages on the application queue changes from zero to one. Use this type of trigger if you want a serving program to start when the first message arrives on a queue, continue until there are no more messages to process, then end. DEPTH: A trigger event occurs only when the number of

messages on the application queue reaches the value of the TriggerDepth attribute.

What are the Trigger types available Explain? a. Application triggering b. Channel Triggering a) In the case of application triggering the components are Application queue: This is the message queue associated with an application Process: A process definition defines the application to be used to process messages from the application queue. Initiation queue: The queue manager moitors the application queue. If the trigger type of the application queue is set to Every then whenever a message is put to the application queue, the q manager looks into the process definition and puts a message having the application name and other details to the initiation queue Trigger monitor: The trigger monitor gets the trigger message from the initiation queue and starts the program specified. b) For channel triggering the transmission queue is monitored and when messages are put in the transmission queue, the q manager puts a message in the channel initiation queue. The channel initiator is the program which monitors the initiation queue and starts the sender MCA. For the message to reach the target queue, the channel listener has to be running in the target queue manager Channel Triggering Conditions: Trigger ON

Trigger type(first every depth) Trigger data(channel name which is to be fired) Initiation queue(SYSTEM.CHANNEL.INITQ)

Channel Triggering Background process: 1. The local queue manager places a message from an application or from a message channel agent (MCA) on the transmission queue. 2. When the triggering conditions are fulfilled, the local queue manager places a trigger message on the initiation queue. 3. The long-running channel initiator program monitors the initiation queue, and retrieves messages as they appear. 4. The channel initiator processes the trigger messages according to information contained in them. This information may include the channel name, in which case the corresponding MCA is started. 5. The channel listener running in the target q mgr starts the receiving MCA Application Triggering Conditions: * Trigger ON * Trigger type (first every depth)

* Initiation queue (SYSTEM.DEFAULT.INITIATION.QUEUE our own defined local queue) * Process (NOTEPAD) DEFINE QLOCAL (LQ) TRIGGER TRIGTYPE (EVERY) INITQ (IQ) PROCESS (NOTEPAD). DEFINE PROCESS (NOTEPAD) APPLICID (NOTEPAD.EXE) APPLTYPE (WINDOWS) Runmqtrm m QM1 q IQ BACKGROUND PROCESS:1. When ever the message comes to triggered local queue, queue manager will fire trigger message with information called trigger type and the process definition (application which is to be triggered) in to the initiation queue (IQ) (our own queue). 2. At the initiation queue a long running time program called trigger monitor will be watching (monitoring) the initiation queue. 3. Whenever the trigger message occurs in the initiation the trigger monitor will pick the information and starts the application which is defined in the process. What is a Trigger monitor? A trigger monitor is a continuously - running program that serves one or more initiation queues. When a trigger message arrives on an initiation queue, the trigger monitor retrieves the message. The trigger monitor uses the

information in the trigger message. It issues a command to start the corresponding application/channel command used for the running trigger monitor On Server side: runmqtrm -m QMName -q Initiation QueueName On Client side: runmqtmc -m QMName -q Initiation QueueName

Queue Manager Clusters and MQ Clustering => CLUSTERING Clustering is a way to logically group WebSphere MQ queue managers - reduced system administration due to fewer channel, remote queue, and transmission queue definitions - increased availability and workload balancing. => Basic Cluster setup > Step-1 Determine which queue manager should hold full repositories A full repository contains a complete set of information about every queue manager and object in the cluster You will need at least one, preferably two

> Step-2 Alter the queue manager definitions to add repository definitions ALTER QMGR REPOS(cluster_name) > Step-3 Define the CLUSRCVR channels Every queue manager in the cluster needs a CLUSRCVR with a conname pointing to itself. DEFINE CHANNEL(channel_name) CHLTYPE(CLUSRCVR) TRTYPE(TCP) CONNAME(my_ip_name_or_address(port)) CLUSTER(cluster_name) > Step-4 Define the CLUSSDR channels Define one CLUSSDR to a full repository queue manager. The channel name must match that of the CLUSRCVR on the full repository DO NOT define a CLUSSDR to point to a partial repository. DEFINE CHANNEL(channel_name) CHLTYPE(CLUSSDR) TRPTYP(TCP) CONNAME(remote_ip_name_or_address(port)) CLUSTER(cluster_name) > Step-5 Define a cluster queue DEFINE QLOCAL(qname) CLUSTER(cluster_name) Other queue managers in the cluster can send message to it without making remote-queue definitions for it. Only the local queue manager can read messages from an instance of the cluster queue You can use a sample program to test putting messages to clustered queues

=> Cluster Commands DISPLAY QMGR REPOS REPOSNL QMID AMQ8408: Display Queue Manager details. QMNAME(QM1) QMID(QM1_2005-07-12_17.14.38) REPOS(QMCLUS)REPOSNL( ) QMID is an internally generated unique name that consists of the queue manager name plus the time the queue manager was created DISPLAY CLUSQMGR(*) ALL Display cluster Queue manager details dis chstatus(*) all Display channel status details DISPLAY QCLUSTER(*) ALL It displays information about clustered queues only. A cluster queue will not be displayed on a partial repository until an application has opened it. DISPLAY QUEUE(*) CLUSINFO This command displays information about queues with TYPE(QCLUSTER) => Work load balancing When a cluster contains more than one instance of the same queue, workload balancing determines the best queue manager to route a message to - At its simplest, workload management results in a roundrobin effect MQ V6 has additional parameters that can be used to influence the results of the algorithm.

- Queues: CLWLPRTY, CLWLRANK, CLWLUSEQ - Queue Managers: CLWLUSEQ, CLWLMRUC - Channels: CLWLPRTY, CLWLRANK, CLWLWGHT, NETPRTY For workload balancing to occur: - open the queue with the MQOO_BIND_NOT_FIXED open option - open with the default MQOO_BIND_AS_Q_DEF and with DEFBIND(NOTFIXED) set in the queue definition - Leave MQMD.ObjectQMgrName blank to allow the queue manager to chose the queue instance - To force the message to a specific instance of the clustered queue, specify that queue managers name in ObjectQmgrName => Namelists in clusters - A queue manager may be a member of more than one cluster. List those clusters in a NAMELIST. - You can alter a full repository QMGR to use REPOSNL(namelist) rather than REPOS. - For channels and queues, you can specify CLUSNL(namelist) rather than specifying the CLUSTER parameter. => REFRESH CLUSTER - REFRESH CLUSTER removes and rebuilds locally held information about a cluster. - REFRESH CLUSTER(clustername) REPOS(NO) - REFRESH CLUSTER(clustername) REPOS(YES), also refreshes information about full repository queue managers and may not be issued from a full repository. - REFRESH CLUSTER(*)

=> RESET CLUSTER RESET CLUSTER is issued from a full repository queue manager. It forcibly removes a queue manager or specific QMID from a cluster. - RESET CLUSTER(clustername) QMNAME(qmname) ACTION(FORCER

Recommended

View more >