Дополнительные средства администрирования
Очередь недоставленных сообщений и восстановление данных
Практически все события, за исключением обработки non persistent сообщений, фиксируются в различных лог файлах WebSphere MQ. Существует два вида лог файлов. В первый записываются сообщения об ошибках, а во второй все изменения состояния объектов менеджера, включая обработанные persistent сообщения. Файл ошибок имеет формат, который легко прочитать с помощью любого текстового редактора. В него записываются события, связанные со стартом или остановкой менеджера и каналов, ошибки установки соединения, ошибки приема или отправки сообщений, например с некорректным форматом или ошибки конвертации, связанные с кодовой страницей. Одним словом, все события, связанные с обеспечением деятельности всех менеджеров очередей, созданных на данном компьютере. Расположение этих файлов задается при первоначальной установке WebSphere MQ. Например, для платформы Windows по умолчанию они расположены в каталоге C:\Program Files\IBM\WebSphere MQ\Errors и имеют название amqerrXX.LOG, где ХХ – номер файла. Второй тип файлов имеет специальный формат и представляет собой журнал изменений свойств объектов. Кроме этого в него записываются все persistent сообщения, обработанные менеджером очередей. Для каждого локального менеджера создаются свои файлы. Например, для менеджера очередей QM_Win2000 на платформе Windows они расположены в C:\Program Files\IBM\WebSphere MQ\log\QM_Win2000\active\ и имеют имя s000000X.log, где X – номер файла. Напомним, что существует два вида логирования сообщений и изменений свойств объектов – линейный и круговой. Линейный вид логирования, в отличие от кругового, позволяет как записывать, так и восстанавливать состояние менеджера в определенный момент времени. Запись образа объектов менеджера производится с помощью команды rcdmqobj . Синтаксис команды имеет вид:
rcdmqobj -m QmgrName -t ObjectType GenericObjName
где:
QmgrName – имя менеджера.
ObjectType – тип объекта. Может принимать значения nl или namelist для списка кластеров, prcs или p rocess для процессов, q или queue для всех типов очередей, ql или qlocal для локальных очередей, qa или qalias для alias очередей, qr или qremote для удаленных локальных очередей, qm или qmodel для модельных очередей, qmgr для менеджера, * или all для всех объектов.
Встречаются ситуации, когда необходимо удалить файл очереди, содержащий сообщения. Это необходимо, например, при заполнении свободного пространства дисковой системы (тома), выделенной под WebSphere MQ на UNIX платформах. В этом случае WebSphere MQ сообщит, что объект данной очереди поврежден. Восстановить поврежденные как сознательно, так и в результате сбоя дисковой системы, объекты при условии линейного логирования, можно с помощью команды rcrmqobj . Синтаксис команды имеет вид:
rcrmqobj -m QmgrName -t ObjectType GenericObjName
где:
QmgrName – имя менеджера;
В результате выполнения этой команды восстанавливаются не только очереди, но и persistent сообщения в очередях. Это возможно благодаря тому, что для каждого объекта менеджера ведется запись изменений его состояния, и так называемые точки checkpoint . Команда rcrmqobj повторяет все события, которые были с поврежденным объектом от последнего checkpoint до конца лог файла. Поскольку not persistent сообщения в файл не записываются, то они и не восстанавливаются.
При использовании кругового логирования поврежденные объекты следует удалить, а затем создать заново.
Кроме технических ошибок бывают еще и логические ошибки, связанные с неправильными настройками объектов. Если в локальной удаленной очереди указано неверное имя удаленного менеджера или очереди назначения, то сообщения все равно будут доставлены на менеджер, расположенный по адресу, указанному в канале отправителе, который использует соответствующую трансмиссионную очередь. Для обработки ошибочных или недоставленных сообщений существует специальная очередь недоставленных сообщений, которая указывается в атрибуте менеджера Dead-letter Queue в закладке Extended. Изменим пример из лекции 5, в котором при создании на менеджере QM_Win2000 локальной удаленной очереди Win2000_HPUX.RQ будет неправильно указана очередь, в которую нужно доставить сообщения:
ALTER QREMOTE ('Win2000_HPUX.RQ') +
XMITQ('Win2000_HPUX.TQ') +
RNAME('Win2000_AIX.Q') +
RQMNAME('QM_HPUX')Очереди назначения Win2000_AIX.Q на менеджере QM_HPUX не существует, однако сообщение все равно будет доставлено на этот менеджер в очередь DEAD_LETTER. Его можно просмотреть с помощью WebSphere MQ Explorer (рис. 7.1).
Просмотрев свойства сообщения, в закладке Dead-Letter Header можно увидеть код ошибки 2085, который говорит о том, что в заголовке сообщения существует неизвестный объект. В поле Destination Queue можно увидеть, что очередью назначения является несуществующая очередь Win2000_AIX.Q. Из данной ситуации есть три выхода:
-
Создать очередь Win2000_AIX.Q на менеджере QM_HPUX и перенаправить сообщение из DEAD_LETTER в нее с помощью команды:
runmqdlq DEAD_LETTER QM_Win2000
Далее ввести команду:
ACTION(RETRY)
и нажать <Ctrl+d> (для платформы Windows <Ctrl+z> <Enter> и еще раз <Ctrl+z> <Enter> ) и выйти из команды runmqdlq нажав <Ctrl+c>. В результате выполнения данной команды WebSphere MQ попытается заново инициировать помещение сообщения с указанными атрибутами из очереди DEAD_LETTER. Этот способ следует применять в случае переполнения существующей очереди назначения. Напомним, что если количество
сообщений в очереди превышает ее атрибут Maximum Queue Depth, то вновь поступающие сообщения также будут помещаться в очередь недоставленных сообщений.
-
Перенаправить сообщение в другую очередь, например в Win2000_HPUX.Q. В данном случае синтаксис команды runmqdlq будет выглядеть следующим образом:
runmqdlq DEAD_LETTER QM_Win2000
Далее ввести:
ACTION(FWD) FWDQ('Win2000_HPUX.Q') HEADER(NO)и нажать Ctrl+d. Сообщения из очереди DEAD_LETTER будут помещены в очередь Win2000_HPUX.Q.
-
Удалить сообщение из DEAD_LETTER, исправить свойства локальной удаленной очереди Win2000_HPUX.RQ на менеджере QM_Win2000:
ALTER QREMOTE ('Win2000_HPUX.RQ') RNAME('Win2000_HPUX.Q')и послать сообщение заново.
Второй способ можно использовать, когда переполнена как очередь назначения, так и очередь недоставленных сообщений. Если это не удается, то можно поступить следующим образом. Назначить в качестве очереди недоставленных сообщений новую очередь и перестартовать менеджер. Вновь поступающие сообщения будут помещаться уже в нее. Однако следует не допускать переполнения очередей недоставленных сообщений. Кроме этого, следует отметить, что простое перекладывание сообщения из очереди недоставленных сообщений в очередь назначения не даст нужного результата, поскольку недоставленные сообщения имеют свой собственный (MQDEAD) формат.
Иногда встречается случай, когда после перезагрузки менеджера очередей пропадают сообщения из трансмиссионной (transmission) очереди, несмотря на то, что ее атрибут Default Persistence установлен в persistent. В таком случае следует проверить этот атрибут в соответствующей локальной удаленной (remote) очереди и также установить его в persistent.