|
Защита данных - Failover Clusters
Основы баз данных OpenEdge
Защита данных
Стратегия резервного копирования (backup)
Востановление базы данных
After-imaging
Обеспечение безопасности
Auditing
Репликация данных
Failover Clusters
Обзор
Программное обеспечение и аппаратные средства
Инсталляция
Конфигурирование
Безопасность
Исполнение
Логирование
Необходимые кластерные компоненты
Сетевые решения
Концепция и терминология
Ресурсы и зависимости
Сбой и процедура восстановления
Политики «аварийного переключения»
Использование интерфейса команды PROCLUSTER
Включение базы данных в кластер
Исключение базы данных из кластера
Старт базы данных в кластере
Останов базы данных в кластере
Завершение работы кластерной базы данных
Isalive и looksalive
Результат активации для базы данных OpenEdge
Рассмотрение специфических платформ
Использование AdminServer для включения кластера
Использование стандартных команд для включения кластера
Использование Windows Cluster Administrator
Аварийное отключение кластера
Команды управления кластером в UNIX
Распределенная обработка транзакций
Распределенные транзакции
Механизм Two-phase commit и клиенты ABL
Поддержка Java Transaction API (JTA)
Поддержка и мониторинг базы данных
Команды запуска и останова
Параметры запуска баз данных
Утилиты OpenEdge RDBMS
Виртуальные системные таблиц (VST)
Failover Clusters, поддерживается операционными системами и аппаратно не зависимыми решениями для обеспечения автоматической обработки сбойных ситуаций в базах данных OpenEdge.
Далее, для удобства, Failover Clusters будем называть просто кластер.
Обзор
Кластер представляет собой тип параллельной или распределенной системы, состоящей из связанных друг с другом компьютеров. Другими словами, кластер связывает несколько серверных системных узлов в единую, мощную систему, способную одновременно поддерживать большое количество выполняемых задач. Если в кластере один из серверных узлов неожиданно выходит из строя или отключается для проведения модернизации или обслуживания, то выполняемая им работа автоматически подхватывается исправным узлом или узлами при минимальном перерыве в работе. Данный процесс называется «аварийным переключением» или «failover» и призван обеспечить конечным пользователям максимально бесперебойный доступ к критичным бизнес-приложениям. Доступ к дисковому пространству не маловажный фактор при использовании кластера. Для обеспечения работы полноценного кластера, базы данных должны находиться на разделяемых ресурсах – дисковые накопители внешних дисковых подсистем (Disc Storage). Такое устройство должно быть доступно для любого из узлов кластера, например, если для одного из узлов будет отключено питание, то разделяемый ресурс по прежнему будет доступен другим узлам, тем самым обеспечивая доступность базы данных.
Failover Cluster поддерживает интерфейс командной строки (PROCLUSTER). Этот интерфейс прост в использовании, и не зависим от программной или аппаратной платформы. Что упрощает администрирование баз OpenEdge в кластерной среде.
Кластер OpenEdge не заменяет кластерное программное обеспечение операционной системы. Наоборот, требуется чтобы кластер операционной системы был правильно сконфигурирован как программно, так и аппаратно.
Операционная система интегрирует специфические компоненты кластерной технологии для контроля ресурсов системы и производит «аварийное переключение» на другой узел если текущий не доступен. Кластер OpenEdge плотно интегрируется в кластерную среду программного обеспечения, чтобы правильно определяться как ресурс кластера. Поведение ресурсов кластера в момент сбоя может быть заранее определенно.
Failover Cluster устраняет нежелательное время простоя и обеспечивает непрерывность работы ресурсов кластера.
Программное обеспечение и аппаратные средства
Каждый поставщик операционной системы определяет аппаратные требования для своих технологий кластеризации. Корпорация Progress Software рекомендует использовать эти технологии, т.е. технологии кластеризации поддерживаемые вашей операционной системой. Далее описаны минимальные требования к кластеризации и поддерживаемые версии.
AIX (32-bit and 64-bit)
IBM software:
- AIX5L V5.2.
- HACMP 5.3 cluster manager.
HPUX (32-bit and 64-bit)
HP software:
- HPUX 11.i or later.
- HP mc/ServiceGuard 11.x or later.
HPUX (Itanium 2)
HP software:
- HPUX 11.23 or later.
- HP mc/ServiceGuard 11.x or later.
HP Tru64
HP software:
- Tru64 UNIX Version 5.1b or later.
- TruCluster Version 5.1 or later installed.
SUN Solaris Sparc (32-bit and 64-bit)
SUN software:
- SUN Solaris Sparc 9.
- SUN Cluster Version 3.0.
Windows
Microsoft software:
- WinServer 2003 Enterprise.
Чтобы использовать Failover Cluster, кластер должен иметь как минимум следующие настроенные ресурсы:
- Разделяемые дисковые накопители
- Адрес IP
- Кластерное имя
Инсталляция
До включения базы данных OpenEdge в кластер, на каждом узле должна быть установлена лицензия OpenEdge Enterprise, и путь инсталляции должен быть одинаковым для всех узлов. При обновлении версии OpenEdge база данных должна быть исключена из кластера, и включена заново после обновления.
Конфигурирование
Чтобы Failover Clusters работал правильно, необходимо установить переменные среды окружения соответствующие вашей операционной системе.
AIX
- В переменную PSC_CLUSTER_PATH сохраните путь к директории установки OpenEdge
- JREHOME – каталог в котором установлена Java
- PATH – добавьте $PSC_CLUSTER_PATH/bin
- LIBPATH – добавьте $PSC_CLUSTER_PATH/lib, $PSC_CLUSTER_PATH/bin, $JREHOME/lib, $JREHOME/jre/bin, and $JREHOME/jre/classic
- DLC - путь к директории установки OpenEdge
HPUX
- В переменную PSC_CLUSTER_PATH сохраните путь к директории установки OpenEdge
- PATH – добавьте $PSC_CLUSTER_PATH/bin
- SHLIB_PATH – добавьте $PSC_CLUSTER_PATH/lib и $PSC_CLUSTER_PATH/bin
- DLC - путь к директории установки OpenEdge
- Только для 32 битного HPUX, установите JDKHOME в system profile.
Установите переменную JDKHOME в /etc/profile так, чтобы Java могла быть должным образом сконфигурирована для поддержки SQL Java Stored Procedures и Java Triggers. JDKHOME должен указывать на каталог, в котором установлен JDK.
HP Tru64
- В переменную PSC_CLUSTER_PATH сохраните путь к директории установки OpenEdge
- PATH – добавьте $PSC_CLUSTER_PATH/bin
- Добавьте в LD_LIBRARY_PATH - $PSC_CLUSTER_PATH/lib и $PSC_CLUSTER_PATH/bin
- DLC - путь к директории установки OpenEdge
- Измените $DLC/bin/java_env так, чтобы он указывал на правильную установку SQL Java Stored Procedures и Java Triggers
Для изменения $DLC/bin/java_env выполните следующее:
1. Сформируйте резервную копию скрипта
2. Откройте скрипт и перейдите на строку “OSF1”
3. Измените переменные среды так чтобы они указывали на соответствующую установку Java пакетов.
4. Сохраните изменения
SUN Solaris Sparc
- В переменную PSC_CLUSTER_PATH сохраните путь к директории установки OpenEdge
- PATH – добавьте $PSC_CLUSTER_PATH/bin
- Добавьте в LD_LIBRARY_PATH - $PSC_CLUSTER_PATH/lib и $PSC_CLUSTER_PATH/bin
- DLC - путь к директории установки OpenEdge
Windows
Если устанавливаемые другие продукты перезапишут файл procluster.bat, будет сохранен файл procluster.bak. Если procluster.bat перезаписывается, будет выдано следующее сообщение об ошибке:
'pscluster' is not recognized as an internal or external command,
operable program or batch file
Для решения этой проблемы восстановите файл procluster.bat из файла procluster.bak.
Безопасность
OpenEdge соответствует модели безопасности определенной поставщиками операционной системы, в плане того, что пользователи могут создавать и изменять права доступа к различным каталогам и устройствам, и имеют права запускать и останавливать ресурсы, например, базы данных.
Исполнение
На работу базы данных не влияет ее использование в составе кластера. Так же время «аварийного переключения» зависит от кластерной среды и может изменяться.
Логирование
PROCLUSTER формирует журнал событий по адресу $PSC_CLUSTER_PATH/PSCluster.log для Unix и %PSC_CLUSTER_PATH%\PSCluster.log для Windows. В журнал пишется выполнение команд PROCLUSTER, поэтому скорость роста файла не большая, к тому же он может быть удален в любое время по усмотрению пользователя.
Необходимые кластерные компоненты
Следующий рисунок отображает компоненты обычного кластера. Для Failover Clusters, OpenEdge требует как минимум две основные конфигурации, использующие общую архитектуру памяти, например SCSI, и дополнительную сетевую систему с кластерными взаимосвязями. База данных должна находиться на разделяемых дисковых массивах, доступных из любой конфигурации.
Если необходимо изменить структуру базы данных, или при перенести ее в новое общее хранилище, с этой задаче легко справится кластерный интерфейс командной строки – PROCLUSTER. Если необходимо заменить общий ресурс, используйте PROCLUSTER для остановки базы данных и запуска ее на новом общем ресурсе.
OpenEdge кластер не только интегрируется в кластер операционной системы, но и значительно расширяет функциональные возможности OpenEdge. При включении базы данных в кластер, в мастер блок записывается соответствующая информация. Когда у вас имеется включенный и защищенный кластер базы данных, все команды перенаправляются через операционного кластерного менеджера – pscluster. Это необходимо, чтобы кластер операционной системы знал о действиях OpenEdge и мог принять меры для «аварийного переключения». На рисунке показываются эти связи.
Сетевые решения
Кластер понимает виртуальную модель сервера. Подключения к базе данных должны происходить через кластерный псевдоним и IP адрес, отличный от имени и IP отдельного узла кластера. На рисунке с описанными кластерными компонентами, указан физический уровень кластера, в котором IP адрес кластера указан – 192.168.0.01 (это IP адрес виртуального сервера). В кластере, клиенты подключаются к базе данных именно через этот IP адрес, а не адрес конкретного узла. В сущности, для пользователей существует только один сервер – это виртуальный сервер кластера. На указанном ниже рисунке отображается как пользователи подключаются к виртуальному серверу с IP адресом 192.168.1.01. В пределах этого кластера может существовать несколько узлов с отдельными IP адресами, но клиенты не должны знать о них, и не должны отдельно к ним подключаться, в противном случае кластер может работать не корректно.
Кластерные компоненты виртуальной сети
Концепция и терминология
Кластер способен легко автоматизировать многие ручные процедуры по обслуживанию баз данных в момент сбоев. Для использования возможностей кластера, ниже будет описана терминология и концепции использования кластеризации.
Ресурсы и зависимости
Кластерный ресурс это база данных и все ее зависимости. Зависимость это дополнительные ресурсы требуемые базой данных для нормального функционирования. Зависимости ресурса базы данных включают APW, AIW, BIW, физические диски на которых расположена база в сети и прочее. Ресурсы должны входить в состав кластера. PROCLUSTER регистрирует такие ресурсы в кластерной среде. Необходимо зарегистрировать базу данных как ресурс, тем не менее, не нужно регистрировать зависимости базы данных.
Сбой и процедура восстановления
Сложность кластерных операций в том, чтобы определить порядок автоматического восстановления группы ресурсов OpenEdge. Группа ресурсов состоит из ресурсов и их зависимостей. Чтобы определять как каждый ресурс должен восстанавливаться при аварийном переключении, для каждого из них имеются failover – политики. Failover – политики определяют порядок восстановления ресурса или группы ресурсов во время сбоя.
Политики «аварийного переключения»
Существуют следующие политики «аварийного переключения»:
- IsAliveInterval – интервал опроса приложения методом IsAlive, для определения что приложение все еще «живо». Этот интервал определен в 60 секунд.
- LooksAliveInterval - интервал опроса приложения методом LooksAlive, для определения что появилось «живое» приложение. Этот интервал определен в 5 секунд.
- CheckInterval – Количество времени в течении которого будут производиться попытки перезапуска базы данных на текущем узле. Период установлен в 900 секунд.
- FailureReportThreshold – количество неудачных попыток в течении CheckInterval, прежде чем сигнализировать о сбое. Установлен как 3.
- Retries – количество попыток старта приложения перед началом «аварийного переключения». Установлено – 3.
- Delay – время ожидания перед началом «аварийного переключения» в секундах. Это время позволяет операционной системе при необходимости выполнить различные операции. По умолчанию время ожидания – 0 секунд.
- FailBack – указатель на необходимость возврата приложения на исходный узел после его восстановления. По умолчанию имеет статус False.
- AutoStart – указатель на автоматический запуск приложения без участия оператора. По умолчанию – True.
Использование интерфейса команды PROCLUSTER
PROCLUSTER обеспечивает дружественный пользовательский интерфейс позволяющий управлять базой данных в кластере.
Включение базы данных в кластер
Как только база данных создана и размещена на общем ресурсе, ее можно определить как ресурс кластера. При включении базы в кластер, она должна находиться в остановленном состоянии. Включить базу данных в кластер можно следующей командой:
procluster db-name enable [-pf params-file] [AI][BI][APW=n][WDOG]
Здесь необходимо указать полный путь к базе данных. База должна быть размещена на общем диске в ходящем в состав ресурсов кластера, и этот диск должен быть доступен для текущего узла. Файл параметров должен содержать все параметры необходимые для старта базы. Файл параметров должен:
- Иметь тоже имя что и база – db-name.pf
- Находиться в том же каталоге где и база
- Содержать параметр –cluster
Если файл параметров не соответствует этим требованиям, база данных не сможет запуститься.
Когда происходит включение базы данных в ресурс с помощью PROCLUSTER, кластер выполняет следующее:
- Проверяет структуру базы данных и генерирует регистрационный файл
- Записывает факт регистрации в журнал событий базы данных (.lg)
- Выполняет определенную кластерную регистрацию
Кластерная база данных:
- Не может быть запущена без определенного протокола.
- Не может быть удалена без предварительного исключения из кластера.
- Не может быть изменена структура базы без перерегистрации в кластере.
Когда PROCLUSTER завершит необходимые операции, будет выдано следующее сообщение:
The cluster REGISTER command was successful. (10532)
Так же в журнал событий базы данных (.lg) будет записана следующая информация:
xx.xx.xx prostrct cluster session begin for userid on CON:. (451)
xx.xx.xx prostrct cluster session end. (334)
Для проверки, что база данных создана и доступна в качестве ресурса кластера, в Windows используется Cluster Administrator, для проверки что база данных доступна по указанному полному пути в Virtual Server Group. Под Unix можно использовать соответствующую операционную команду для отображения объектов кластера, такую как caa_stat у HP Tru64. В списке перечисленных объектов база данных будет отображаться с UUID. Следующий пример отображает результат команды caa_stat:
db_nameE3B35CEF-0000-0000-DC17-ABAD00000000
Где текст, это UUID созданного нового ресурса. Для получения более подробной информации обратитесь к документации вашей операционной системы.
Примечание: PROCLUSTER ENABLE зарегистрирует базу данных как ресурс кластера, даже если будут присутствовать ошибки в момент регистрации. Для исправления ошибок, необходимо отменить регистрацию командой PROCLUSTER DISABLE, и повторно использовать PROCLUSTER ENABLE для перерегистрации без ошибок.
Исключение базы данных из кластера
Если база данных зарегистрирована в качестве ресурса кластера и необходимо удалить ее из ресурсов, выполните следующую команду:
procluster db-name disable
Здесь, необходимо указать полный путь к исключаемой из ресурсов базы данных. Исключение базы данных отключает любую другую ее зависимость определенную при регистрации.
При удалении базы данных из ресурсов кластера, происходит следующее:
- Если база данных запущена, она останавливается
- Удаляется ресурс из кластера.
- Удаляет группу ресурсов, если удаляемый ресурс был последним в группе
Используйте Cluster Administrator в Windows или команды операционной системы для Unix, для получения списка объектов кластера, чтобы убедиться, что база данных исключена из этого списка.
Старт базы данных в кластере
Если база данных включена в кластер запустить ее можно введя следующую команду:
procluster db-name start
Здесь необходимо указать полный путь к базе данных.
Примечание: PROCLUSTER открывает файл параметров –pf db-name.pf для добавления к команде proserve для запуска базы данных. Если файл параметров не будет найден, запуск базы будет не возможен.
Для проверки запуска базы данных используйте параметры isalive и looksalive с командой PROCLUSTER.
Останов базы данных в кластере
Для нормальной остановки работы кластерной базы данных используйте следующую команду:
procluster db-name stop
Кластер определяет базу данных по db-name. База данных обязательно должна быть членом кластера. Обязательно должен быть указан полный путь к базе данных. Проверить остановку базы данных можно используя параметры isalive и looksalive с командой PROCLUSTER.
При остановке базы данных с помощью PROCLUSTER происходит следующее:
- База останавливается
- Уведомляет кластерную группу, что произошел нормальный останов и «аварийное переключение» не требуется.
Примечание: PROCLUSTER равнозначно может использовать на ровне с PROSHUT и AdminServer, для останова базы данных.
Завершение работы кластерной базы данных
Для вынужденного завершения работы кластерной базы данных используйте команду:
procluster db-name terminate
Для вынужденного отключения кластер использует db-name. База данных должна быть членом кластера. Имя базы данных должно содержать полный путь.
Isalive и looksalive
Параметры Isalive и looksalive запрашивают кластерного менеджера о состоянии базы данных. Isalive это более точный параметр, так опрашивает именно активную кластерную систему. Looksalive, на системах с кэшированием кластерного состояния, запрос будет происходить именно к кэш вместо активной системы, а так как всё таки существует вероятность не соответствия, это запрос можно считать менее надежным.
Для определения действует ли ресурс используйте команду:
procluster db-name looksalive
Команда возвратит следующий текс со статусом базы данных:
Resource: db-name State: Looks Alive
Статус Looks Alive будет возвращен только в случае если база активирована и запущена. Все остальные состояния базы возвращают следующую запись:
Resource: db-name State: Not Alive
Для определения актуального состояния используйте следующую команду:
procluster db-name isalive
Команда вернет следующую строку если база данных отвечает положительно:
Resource: db-name State: Is Alive
Все остальные статусы базы будут отображаться следующим образом:
Resource: db-name State: Not Alive
Результат активации для базы данных OpenEdge
Добавление OpenEdge в кластерный ресурс создает файл <dbname>Resources.cluster. Например, имя базы данных sports2000.db, имя файла кластерного ресурса будет – sports2000Resources.cluster. Это текстовый файл, содержащий имена ресурсов зависимых от ресурса базы данных. Если для базы данных не было запущено вспомогательных процессов, таки как AIW, APW, BIW, WDOG, файл будет пустым. В противном случае, он будет содержать имена зависимых ресурсов, зарегистрированных кластерным менеджером. Нельзя самостоятельно редактировать или удалять этот файл. Failover Cluster работает с этим файлом и удаляет его при исключении (disable) базы данных из кластера.
UUID файл базы данных (только для HPUX 32\64)
Кроме файла .cluster, под HPUX, создается UUID файл. Он содержит перевод имени процесса в регистрационной кластерное имя. Файл называется <dbname>.uuid. Например, для базы sports2000.db, файл будет иметь имя sports2000.uuid.
Изменение структуры базы данных
При изменении структуры кластерной базы данных с помощью команды PROSTRCT, кластер выполняет следующее:
- Автоматически определяет, что ресурс должен быть включен
- Переводит ресурс в offline если он работает
- Автоматически отключает и включает ресурс
PROSTRCT автоматически обновляет список кластерных ресурсов в кластерном менеджере.
После окончания изменений, необходимо в ручную запустить базу данных с помощью PROCLUSTER.
Добавление экстентов в группу томов или другую систему отличную от базы данных (только для AIX)
На AIX для добавления экстентов в базу данных расположенных в другой системе, потребуются дополнительные шаги. После изменения экстентов с помощью PROSTRCT, будет создан файл с именем PSC_CLUSTER_REG.TMP в директории scripts, размещенной в вашей инсталляционной директории. Этот файл должен быть просмотрен и запущен.
Просмотр файла необходим для того чтобы удостовериться, что все пути к добавляемым экстентам прописаны правильно. Эта информация находится в конце файла с заголовком Database Dependency. Если есть неправильные пути, необходимо выполнить следующие действия:
1. отредактируйте файл PSC_CLUSTER_REG.TMP в плане корректировки путей добавленных экстентов.
2. Смените ваш каталог на $PSC_CLUSTER_PATH.
3. Запустите следующую команду:
bin/pscluster register scripts/PSC_CLUSTER_REG.TMP
Выполнение команды может потребовать некоторого времени!
Примечание: не добавляйте экстент к группам или файловым системам, если они используются другой ресурсной группой.
Рассмотрение специфических платформ
Существует некоторые различия поддержки Failover Clusters на различных операционных системах. Далее будут описаны наиболее важные из них.
Добавление узлов где база данных работает под AIX
По умолчанию, ресурсной группе разрешено работать только на текущем узле, т.е. узле на котором база была включена в кластер. Вы можете изменить приоритеты и количество узлов, на которых база данных может работать, с помощью меню SMIT, команды smit hacmp. Из этого меню выберите Cluster Configuration -> Cluster Resources -> Define Resource Group -> Change/Show a resource group. Change/Show a resource group содержит возможность изменения выбранных узлов.
После добавления узла в ресурсную группу, проверьте, что директория и ее содержимое для ресурсной группы скопированы на все узлы, на которых базе данных разрешено работать. Директория ресурсной группы расположена в /etc/cluster. Имя директории, это имя ресурсной группы. Эта директория, обязательно должна присутствовать во всех узлах.
Предел количества пакетов для HPUX 32\64
Существует определенный предел количества пакетов, которые могут быть зарегистрированы кластерным менеджером. Каждый пакет ассоциируется с базой данных. Watch Dog, BIW, AIW и каждый APW ассоциируется с дополнительным пакетом. Например, если база данных включена в кластерный ресурс вместе с AIW, BIW, WDOG и тремя APW, в итоге кластерным менеджером будет зарегистрировано семь ресурсов. PROCLUSTER учитывает создание файлов и каталогов, необходимых для регистрации, даже если предел был превышен. Это связанно с тем, чтобы контролировать детали конфигурации и проверять, что максимальное количество пакетов не будет превышено до включения базы данных в кластерный ресурс.
Если вы все-таки превысили предел, то настройте MAX PACKAG LIMIT. После чего вы можете исправить ваш кластерный ресурс базы данных следующим образом:
- Используйте cmapplyconf из MC\Service Guard для регистрации пакетов в ручную. Имена пакетов могут быть найдены файле <dbname>.uuid.
- Отключите базу данных и переподключите ее с желаемыми пакетами. PROCLUSTER гарантирует автоматическую регистрацию
Каталог для регистрации пакетов для HPUX 32\64
В каталоге /etc/cmcluster, находятся каталоги каждого пакета, зарегистрированного кластерным менеджером. В них находится три файла:
- Файл конфигурации (.conf), содержащий детальную конфигурацию пакета
- Контрольный файл (.scr), содержащий сценарии запуска, останов и функции мониторинга. Progress Software Corporation не рекомендует редактировать этот файл.
- Журнал событий (log), созданный при первом переводе ресурса в online.
Использование AdminServer для включения кластера
Конфигурирование кластерной базы данных с помощью AdminServer это процесс состоящий из двух шагов. Сначала AdminServer должен быть запущен для идентификации работы в кластере, после чего база данных может быть настроена из Progress Explorer.
Для запуска AdminServer в кластере, используется следующая команда:
proadsv -start -cluster -host cluster-alias
Вне кластерной среды, для PROADSV используется имя хоста – localhost. Но в кластерной среде localhost не может быть доступным для AdminServer.
Настройка кластерной базы данных для работы с AdminServer:
1. проверьте, что база данных расположена на общем ресурсе и доступна для текущего узла кластера
2. Запустите Progress Explorer и подключитесь к кластерному AdminServer
3. Правым щелчком мыши добавьте новую базу данных. Введите имя базы данных и установите флаг Start this Database in Cluster mode, как показано на рисунке:
4. Закончите настройку базы данных
5. Измените файл параметров базы данных dbname.pf, расположенной в том же каталоге где находится и сама база. Файл должен содержать следующее:
-cluster protected
-properties /usr/dlc/properties/conmgr.properties
-servergroup database.defaultconfiguration.defaultservergroup
-m5
-adminport adminserverport # substitute the port name or number
6. Запустите базу данных с помощью Progress Explorer
Использование стандартных команд для включения кластера
Кластерная база данных может быть запущена с помощью стандартных команд, с использованием специального параметра, для проверки работы в кластере. Следующая команда запускает базу данных используя команду PROSERVE:
proserve -db dbname -cluster startup
Параметры –db и –cluster являются единственно доступными, все остальные будут проигнорированы при выполнении. Proserve направляет кластерный менеджер для старта базы и использовании конфигурации базы, определенной при ее включении в кластер.
Использование Windows Cluster Administrator
Windows Cluster Administrator это мощное, имеющее интуитивно понятный интерфейс, средство, предоставляющее пользователям с правами администратора возможность настраивать кластерную среду. Как только вы подключаетесь к кластеру, в окне администратора отображаются группы, ресурсы, настройки кластера и узлы как первичные объекты. Каждая группа может быть расширена, для отображения ее содержимого на подобие Windows Explorer. Ресурс могут перемещаться из группы в группу с помощью технологии drag and drop. Для получения дополнительной информации по Cluster Administrator смотрите документацию Microsoft. Следующие шаги детально описывают как создавать и управлять ресурсами баз данных с помощью Cluster Administrator.
Создание ресурса базы данных:
1. Подключитесь к кластеру и выберите New -> Resource для добавляемой группы
2. Заполните диалоговое окно следующим образом:
a. В поле Name введите имя ресурса.
b. Description – введите понятное описание ресурса
c. Resource type – выберите базу OpenEdge
d. Group – по умолчанию выставляет то, что было введено в поле Name
e. Установите флаг Run this resource in a separate resource monitor.
3. Выберите предпочитаемый узел.
4. Выберите диск и имя кластера (или IP адрес) от которого ресурс будет зависеть
5. Заполните таблицу Parameters для ресурса базы данных:
a. Database File Spec – введите полное имя базы данных
b. Введите полный путь каталогу в котором установлен OpenEdge в поле Working Directory
c. Start Command – введите имя команды запуска базы данных. Например, C:\Progress\OpenEdge\bin\_mprosrv. Необходимо вводить только имя команды, без параметров.
d. Start Options – укажите параметры запуска базы данных, например, -pf <parametr-file>
e. Stop Command – введите команду останова базы данных, например, C:\Progress\OpenEdge\bin\proshut. Вводится только имя команды!
f. Srop Options – введите параметры останова базы данных, например, -by.
6. Выберите Finish для завершения операции. Ресурс базы данных будет отображен в окне Explorer со статусом Offline.
Когда ресурс базы данных создан, он может быть запущен или остановлен с помощью Cluster Administrator.
Для запуска базы данных щелкните правой кнопкой мыши на ресурсе базы и выберите Bring Online. Статус ресурса базы данных будет сменен с Offline на Online Pending, и Online когда база данных окончательно запустится.
Для останова базы данных щелкните правой кнопкой мыши на имени ресурса и выберите Take Offline. Статус базы данных будет изменен с Online на Offline Pending, а после полной остановки базы на статус Offline.
Добавление дополнительного брокера (secondary broker) к кластерной базе данных через Cluster Administrator:
1. Выберите Resources из дерева просмотра
2. Выберите вашу базу данных
3. Выберите File -> New -> Resource. Будет открыто диалоговое окно New Resource
4. Продолжите настройку в этом окне:
a. Name – введите необходимое имя дополнительного брокера
b. Resource type – выберите Progress Database
c. Possible owners – укажите тот же хост что и для выбранной базы данных
d. Dependencies – укажите вашу базу данных
5. Как только вы закончите настройку, перейдите в диалоговое окно Properties и заполните таблицу Parametrs:
a. Database File Spec – введите полное имя базы данных
b. Введите полный путь каталогу в котором установлен OpenEdge в поле Working Directory
c. Start Command – введите имя команды запуска базы данных. Например, C:\Progress\OpenEdge\bin\_mprosrv. Необходимо вводить только имя команды, без параметров.
d. Start Options – укажите параметры запуска базы данных, например, -pf start_secondary_brkr.pf
e. Оставьте поля Stop Command и Stop Options пустыми, т.к. команда и параметры останова регламентируются первичным брокером.
Если необходимо запустить более чем один дополнительный брокер, добавьте .bat файле в поле Start Command описанном в шаге 5. Этот файл может содержать командные линии для запуска дополнительных брокеров.
Аварийное отключение кластера
В случаях, когда возникает неисправимая ошибка, вы можете очистить информацию о кластеризации базы данных в мастер блоке используя следующую команду:
prostrct cluster dbname clear
Подобная очистка позволяет работать с базой данных без кластерной защиты. Но подобная очистка не удаляет базу данных из списка ресурсов кластера, поэтому удаление этих объектов должно выполняться вручную.
Примечание: используйте команду PROSTRCT только в при аварийных случаях. При нормальных обстоятельствах необходимо использовать команду PROCLUSTER для исключения базы данных из кластера.
Команды управления кластером в UNIX
В в следующей таблице указаны команды для управления кластерами в Unix. Для более детального их описания смотрите документацию к операционной системе.
Общая функция
|
AIX |
HPUX
|
HP Tru64
|
Solaris
|
| Сценарии заданный по умолчанию |
n/a |
Cmmakepkg |
n/a |
n/a |
| Перечисление кластерных объектов |
clfindres,
clgetgrp,
clgetaddr,
cllscf |
cmquerycl,
cmgetconf,
cmscancl,
cmviewcl,
cmviewconf |
caa_start |
scha_cluster_open,
scha_resource_open,
scha_resourcetype_open |
| Проверка конфигурации |
clverify_cluster |
cmcheckconf |
n/a |
n/a |
| Просмотр статуса кластера или ресурса |
clstat
clRGinfo |
cmviewcl |
caa_report |
scstat |
| Регистрация ресурса |
cl_crlvfs,
cl_mkvg,
cl_mkgroup,
cl_mklv,
cl_updatevg |
cmapplyconf |
caa_register |
scha_control,
scha_resource_setstatus |
| Удаление ресурса |
cl_rmfs,
cl_rmgroup,
cl_rmlv,
cl_updatevg |
cmdeleteconf |
caa_unregister |
scha_control,
scha_resource_setstatus |
| Запуск ресурса |
n/a |
cmrunpkg |
caa_start |
scha_control,
scha_resource_setstatus |
| Остановка ресурса |
n/a |
cmhaltpkg |
caa_stop |
scha_control,
scha_resource_setstatus |
Move resource
to node. |
n/a |
cmhaltpkg,
cmrunpkg |
caa_relocate |
scha_control,
scha_resource_setstatus
|
Для AIX и HP, общие диски должны быть доступными для использования, varied-on, и установлены. Используйте следующие команды для работы с общими дисками:
| Общая функция |
AIX
|
HPUX
|
| Группы “vary-on” |
varyonvg volgrp |
vgchange -a y volgrp |
| Прикрепление общих файловых систем для совместного использования |
mount/sharedfs |
mount/sharedfs |
| Список |
lsvg -o |
vgdisplay |
Распределенная обработка транзакций
Распределенные транзакции объединяют две и более базы данных в одну транзакцию. Как это происходит, будет описано в этой части:
Распределенные транзакции
Распределенная транзакция (distributed transaction) это одна транзакция изменяющая две и более базы данных. В следующем примере показывается что может произойти при работе распределенной транзакции. Имеется два банковских счета, один на в базе данных acct1, другой в базе данных acct2. Приложение выполняет процедуру снятия денег с счета в базе acct1 и отправки их на счет в базе acct2. Для поддержания баланса банка в соответствующем состоянии обе операции обязательно должны быть корректно завершены, в противном случае, изменения должны быть отменены на обеих базах. Иначе, если сбой произойдет в момент когда деньги уже были сняты со счета в базе acct1, но не зачислены на счет в базе acct2, и транзакция не была распределенной, мы получим по мимо нарушения целостности, еще и расхождение в балансе банка.
Механизм Two-phase commit и клиенты ABL
Механизм Two-phase commit контролирует распределенные транзакции, чтобы они отработали последовательно на всех задействованных базах данных, защищая их от нарушения целостности, и убеждаясь, что транзакция отработала на всех базах без ошибок, или в откатывает изменения в случае возникновения сбоя. Чтобы гарантировать целостность баз, движок базы производит изменения в два этапа. В течении первого этапа, каждая база проверяется на предмет ее готовности провести транзакцию. В течении второго этапа, базам указывается провести транзакцию, и проверяется, сделано ли это должным образом. Если в момент работы транзакции возникают проблемы, движок выдает сообщение об ошибке и предлагает либо завершить транзакцию, либо откатить все изменения для возврата базы в исходное состояние.
Как база данных выполняет two-phase commit
При выполнении two-phase commit движок базы данных назначает базу - координатор и транзакционный номер каждой распределенной транзакции. База – координатор определяет статус транзакции, или успешно выполнена или нет. Транзакционный номер определяет индивидуальные транзакции. Этот номер назначается базой – координатором. Движок сохраняет имя базы – координатора и транзакционный номер в before-image (BI) файл каждой базы участвующей в распределенной транзакции.
База – координатор проверяет статус транзакции, чтобы продолжить работу с ней или ее завершить. Если она выполняет транзакцию, статус транзакции будет – committed, даже если другие базы не выполняют транзакцию (такое может произойти из-за программного или аппаратного сбоя). Если же база – координатор прерывает транзакцию, ее статус будет – aborted. И в этом случае, все базы входящие в транзакцию, должны выполнить те же действия, что и база – координатор.
На следующем рисунке показано как происходит использование two-phase commit в OpenEdge. Поскольку этот алгоритм требует не буферизованные операции I/O, возможно понижение производительности системы при работе Two-Phase commit. Но, при работе транзакций не включающих множество баз данных, ни какого влияния на производительность не будет.
Из рисунка видно, что база – координатор является главной при определении, продолжить или прекратить работать с транзакцией. Следя за действиями координатора, two-phase commit позволяет решать проблемы с любыми противоречивыми транзакциями.
Limbo transaction или in-doubt transaction происходит, когда база – координатор выполняет или прерывает транзакцию, но в следствии различных причин (например, отключение питания сервера), другие базы данных не могут последовать ее примеру, и выполнить аналогичные операции. Такое название эта транзакция получила потому, что на данной стадии, работа транзакции временно приостановлена. Следующий рисунок иллюстрирует работу limbo transaction.
Когда возникает limbo транзакция, ее необходимо решить, для восстановления целостности данных.
Как только база – координатор устанавливает статус распределенной транзакции, она записывает статус в BI и TL (transaction log) файлы. TL файл прослеживает состояние всех распределенных транзакций, с которыми работает координатор.
Статусы транзакций пишут в TL файл, поскольку BI файл постоянно перезаписывается базой данных. Если вопрос с limbo транзакцией решен, TL файл гарантирует, что база – координатор будет иметь надежную запись транзакции.
Если для базы - координатора активирован after-imaging, то она автоматически будет использовать AI файлы для записи в них статусов распределенных транзакций вместо TL файла. Это связанно с тем, что использование только AI файла выгоднее в плане производительность, чем одновременно использовать AI и TL файл, т.к. запись на диск будет производиться реже. Однако, движок базы данных по прежнему использует TL файл для сохранения информации о переключении статуса AI файлов на доступный для использования (EMPTY). Как только after-imaging будет отключен, база начнет полноценно использовать TL файл.
Two-phase commit и roll-forward recovery
Если вы используете Two-phase commit, вы так же должны использовать after-imaging чтобы гарантировать целостность базы данных и избегать проблем синхронизации резервных копий. Хоть и two-phase commit контролирует процесс синхронизации распределенных баз, он не гарантирует вам защиту от потери базы данных или BI файла. AI файлы помогут вам восстановить базу данных в случае потери ее в следствии сбоя.
При восстановлении базы данных с помощью механизма roll-forward всегда помните о следующем:
- Если вы выполняете roll-forward recovery на базе данных с активированным after-imaging и two-phase commit, RFUTIL деактивирует их обоих.
- Когда вы накатываете ai файлы содержащие транзакции базы – координатора и их описание, RFUTIL записывает в TL файл эти описания. Таким образом, если two-phase commit не активирован, RFUTIL активирует его для базы – координатора.
Включение two-phase commit
PROUTIL обеспечивает защиту two-phase commit только если two-phase commit включен для двух или более баз данных входящих в распределенную транзакцию. Например, если транзакция включает в себя три базы данных, а two-phase commit включен только для двух из них, PROUTIL обеспечивает защиту с помощью two-phase commit только этим двум базам. Тем не менее, так как защищены только две из трех базы данных, транзакцию нельзя назвать полностью защищенной. Для обеспечения полной защиты, необходимо включить two-phase commit на всех трех базах данных.
Примечание: для использования two-phase commit необходимо добавить в базу данных область для TL – Transaction log area.
Включить two-phase commit можно с помощью PROUTIL 2PHASE BEGIN. Когда механизм будет включен, вы можете указать, какая база данных будет выступать в роли координатора. Вы можете использовать альтернативное имя (nickname) для базы координатора.
Синтаксис PROUTIL для включения механизма two-phase commit:
proutil db-name -C 2phase begin [ -crd | -tp nickname ]
Где,
db-name –
имя базы данных
-crd
Определяет, что эта база данных может быть координатором
Пример, вы включаете two-phase commit для трех баз данных (db1,db2 и db3) и вы определяете параметр –crd для базы db3, PROUTIL установит db3 как координатора. Однако, если вы укажите параметр –crd для большего количества баз, PROUTIL произвольно назначит координатора из баз данных с указанным параметром. Если не одна из база не будет определена как координатор, все базы с включенным two-phase commit будут являться потенциальными координаторами. PROUTIL произвольно назначит базу – координатор из этих баз.
-tp
Определяет уникальное имя базы – координатора (nickname). Если параметр не будет указан, PROUTIL возьмет имя базы данных без расширения (.db). Например, если имя базы данных /usr/dbs/appl/db, PROUTIL возьмет имя appl. Если PROUTIL установит базу данных appl.db как координатора, в BI файл будет записано имя appl, вместо полного пути к базе данных. Это имя может включать 8 символов.
Примечание: имя должно быть обязательно уникальным в пределах всех баз данных, используемых в распределенной транзакции. Поэтому будьте внимательны, если у вас есть две базы с одинаковым названием, но расположенными в разных местах, PROUTIL не будет видеть разницы между ними.
Изменение nickname и приоритета базы данных
Если вы хотите изменить nickname базы данных или изменить ее приоритет, используйте PROUTIL 2PHASE MODIFY:
proutil db-name -C 2phase modify [ -crd | -tp nickname ]
При определении параметра –crd, PROUTIL определяет, может ли база быть координатором. Точнее, если база данных уже является кандидатом на координатора, то в этом случае она уже не кандидат. Если база данных не была кандидатом, то она им становится.
При указании –tp new_nickname, PROUTIL просто устанавливает новое имя для базы – координатора.
Transaction log area
Отдельная область хранения (Transaction log storage area) используется two-phase commit для хранения генерируемой информации. Эту область обязательно необходимо создать.
Транзакционный лог содержит транзакционный номер для всех выполняющихся распределенных транзакций. Когда возникает limbo транзакция, лог сканируется на наличие транзакционного номера, чтобы определить, выполняется транзакция или нет. Если лог содержит номер, это означает что транзакция выполнена. Если же номер не будет обнаружен, значит транзакция прервана.
Как только последний блок области TL будет заполнен, PROUTIL автоматически переключит текущую запись на первый блок области. Таким образом, самая старая транзакционная запись записанная в лог, находится в блоке после текущей позиции записи.
Запись выполняемой транзакции в лог это 32-битный ID выполненной транзакции. Прерванные транзакции не записываются в лог.
TL область может иметь более одного экстента фиксированного размера, и не может иметь экстентов переменного размера. Размер блока области TL должен быть 16K. Каждый такой блок содержит 4000 записей о выполненных распределенных транзакциях. Транзакционный лог должен иметь достаточно свободного места, чтобы совершаемые транзакции не были перезаписаны прежде чем база данных, содержащая limbo транзакции, будет возвращена в online.
Для определения, какой размер должен быть у TL области, используйте утилиту PROMON, чтобы определить среднее количество транзакций за 24 часовой период. Умножьте полученную цифру на 1,2, и округлите в ближающую сторону кратную 16 Kb. Полученный результат будет количеством байт необходимых для TL области.
Например, в день происходит 1000000 транзакций, расчет будет следующим:
1,000,000 * 1.2 = 1,200,000
1,200,000/16384 = 73.242 (округляем до 74)
74 * 16384 = 1212416
1212416/1024 = 1184 KB
Таким образом получаем, что общий размер экстентов области TL должен быть не менее 1184K.
Отключение two-phase commit.
При отключении two-phase commit база данных не должна использоваться. Для отключения используйте утилиту PROUTIL 2PHASE END:
proutil db-name -C 2phase end
Когда отключение произойдет, в лог базы данных будет записана соответствующая информация.
PROUTIL не удаляет транзакционный лог (TL).
Limbo транзакция в two-phase commit
Limbo транзакция возникает когда синхронизация между базой ординатором и другими базами входящих в распределенную транзакцию прервана. Если база координатор выполнила или откатила транзакцию, а все остальные базы не последовали ее примеру, то транзакция называется неопределенной (limbo). Когда возникает неопределенная транзакция, PROUTIL записывает информацию об ошибочной транзакции в лог базы данных (.lg) и выводит следующее сообщение:
Part of the distributed transaction might have failed.(2022)
Cannot roll back a limbo transaction.(2030)
Следующий рисунок иллюстрирует отображение сообщения:
Неопределенная транзакция может так же возникнуть без отображения сообщения. Например, если произойдет аппаратный или программный сбой во время работы PROUTIL или у пользовательской машины отключилось питание. По возможности, пользователь должен сообщить администратору, время возникновения такой ситуации. Если такое событие произошло, необходимо проверить все возможные базы данных на наличие неопределенных (limbo) транзакций. Для этого можно использовать PROMON или PROUTIL.
Внимание: если приложение выполняет распределенную транзакцию в момент когда происходит ошибка или выключение пользовательской машины, транзакция продолжает выполняться. И соответственно, как и для обычных долгоиграющих транзакции, в этом случае будет наблюдаться рост BI файла.
Решение limbo транзакций
После того как появилась неопределенная транзакция, необходимо определить ее транзакционные номера, какая база является координатором, возникла ли неопределенная транзакция в базе - координатор, и в каком состоянии находится база, в которой возникла такая транзакция. Способ решения неопределенной транзакции зависит от того, используется ли база данных или нет. Если сервер базы данных запущен, используется PROMON. Если не запущен – PROUTIL.
Решение с помощью PROMON:
1. Запустите утилиту PROMON:
promon db-name
Появится основное меню:
MONITOR Release 10.0A
Database: /usr/dlc/sports
1. User Control
2. Locking and Waiting Statistics
3. Block Access
4. Record Locking Table
5. Activity
6. Shared Resources
7. Database Status
8. Shut Down Database
R&D. Advanced Options
T. 2PC Transactions Control
L. Resolve 2PC Limbo Transactions
C. 2PC Coordinator Information
J. Resolve JTA Transactions
M. Modify Defaults
Q. Quit
Enter your selection:
2. Выберите меню T (2PC Transaction Control). Появится следующее меню:
1. Display all entries
2. Match a user number
3. Match a range of user numbers
Q. Return to main menu
Enter your selection:
3. Выберите 1.(Display all entries):
В поле “Limbo?”, если транзакция неопределенная, будет казано – yes.
Примечание: если неопределенные транзакции отсутствуют, PROMON ни чего не покажет в этом окне.
Обратите внимание на все поля неопределенной транзакции, например:
Запомните эту информацию,
она понадобится для решения транзакции
Для каждой неопределенной транзакции необходимо запомнить следующее:
- Номер пользователя, поле Usr
- Имя базы – координатора, поле Coord
- Номер транзакции в базе – координатор, поле Crd-task
Эти данные понадобятся для решения проблемы.
Для решения неопределенной транзакций, необходимо проверить для каждой из транзакций, выполнена ли она на базе – координаторе. Если на координаторе транзакция завершена, необходимо также завершить ее на базе, где возникла неопределенная транзакция. В случае, если на базе – координаторе транзакция не выполнена, ее нужно прервать и на базе где возникла неопределенная транзакция.
4. Для каждой неопределенной транзакции, необходимо запустить PROMON на базе – координаторе, для определения, выполнена ли транзакция на ней или нет.
5. Из меню PROMON выберите C.(2PC Coordinator Information). На экране появится следующее:
MONITOR Release 10
Database: /users/sports1
Q. Quit
Enter the transaction number you want to find out if committed:
Примечание: если база координатор остановлена, и вы не можете использовать PROMON, используйте PROUTIL 2PHASE COMMIT, для определения статуса транзакции.
6. введите транзакционный номер, полученный из Crd-task в первом шаге и нажмите Return.PROMON выдаст сообщение о статусе транзакции.
Примечание: для проведения транзакции на остановленной базе, используйте PROUTIL 2PHASE RECOVER.
7. Запустите PROMON для базы, на которой возникла неопределенная транзакция, чтобы завершить или прервать ее.
8. В основном меню PROMON выберите L (Resolve 2PC Limbo Transactions). Появится следующее меню:
1 Abort a Limbo Transaction
2 Commit a Limbo Transaction
Q Quit
Enter choice>
9. Для завершения транзакции выберите 2 (Commit a Limbo Transaction). PROMON запросит номер пользователя, введите его и нажмите Return. Появится следующее сообщение:
User 1: commit transaction and disconnect.
Для прерывания транзакции, выберите 1 (Abort a Limbo Transaction). Так же будет запрошен номер пользователя.
Повторите шаги с 4 по 9 для каждой неопределенной транзакции. После того как транзакции будут выполнены или прерваны, неопределенная транзакция будет решена.
Решение с помощью PROUTIL:
1. попытайтесь запустить базу данных с помощью PROSERVE, PRO или PROUTIL. Если старт сессий был успешным, значит ни каких неопределенных транзакций нет. Если неопределенные транзакции существуют, сессия не запустится и будет выдано сообщения подобно следующему (так же будет произведена записб в лог базы данных):
Запомните следующую информацию для каждой транзакции, указанной в сообщении:
- транзакционный номер на текущей базе данных (для которой запускалась сессия)
- Имя базы – координатора
- Транзакционный номер в базе – координаторе
Как только вы получите эту информацию, проверьте статус транзакций на базе – координаторе.
2. Введите следующую команду, для определения, выполнена или прервана транзакция:
proutil db-name -C 2phase commit tr-number
Где, db-name, имя базы – координатора, tr-number – номер проверяемой транзакции. Указывайте именно номер транзакции на базе - координаторе.
Если транзакция была завершена базой – координатором, PROUTIL отобразит следующее сообщение:
Transaction 42453 has committed. (2048)
3. Завершите или прервите транзакцию, в зависимости от полученного сообщения. Для этого используйте PROUTIL PHASE RECOVER. Прежде чем вести команду, определите, хотите ли вы завершить или прервать транзакцию.
proutil db-name -C 2phase recover
Когда команда будет запущена для базы, на которой находятся неопределенные транзакции, PROUTIL задаст следующий вопрос:
Commit transaction 760, on coordinator sports1 #42453 (y to commit/n to abort)? (2039)
4. Если вы ответите yes, PROUTIL завершит транзакцию. Если ответите no – транзакция будет прервана.
PROUTIL будет задавать этот вопрос для каждой неопределенной транзакции в базе данных.
Анализ случая Two-phase commit
Этот анализ иллюстрирует способ разрешения неопределенной сделки. Он включает две базы данных, sports1 и sports2, размещенных на разных машинах, mach1 и mach2, соответственно. На каждой базе данных включен two-phase commit. База – координатор – sports1.
Допустим, что вы запустили клиентский процесс на машине mach1 для базы sports1 и подключились к базе sports2, используя следующую команду:
CONNECT sports2 -H mach2 -S sportssv
После подключения, вы запустили распределенную транзакцию. Во время работы процедуры, клиентский процесс был прерван системной ошибкой, и вы получили следующее сообщение:
Error reading socket, ret=-1, errno=2. (778)
Part of the distributed transaction might have failed. (2022)
Press space bar to continue.
Это сообщение говорит о возможном возникновении неопределенной транзакции. Вам необходимо определить возникла ли такая транзакция и разрешить ее.
Вы запускаете PROMON на базе sports1, выбираете T(Transaction Control), и 1(Display all entries). На следующем экране будет отображено, что на этой базе нет неопределенных транзакций:
Transaction Control:
Usr Name Trans Login Time R-comm? Limbo? Crd? Coord Crd-task
RETURN - repeat, U - continue uninterrupted, Q - quit:
Если PROMON не смог запуститься на базе sports1, это говорит о том, что сервер базы данных был остановлен и вам необходимо использовать PROUTIL для нахождения неопределенных транзакций.
После определения что неопределенных транзакций на базе sports1 нет, нужно проверить их наличие на базе sports2. На этот раз экран PROMON покажет наличие неопределенной транзакции:
Transaction Control:
Usr Name Trans Login Time R-comm? Limbo? Crd? Coord Crd-task
15 paul 755 04/01/02 14:19 yes yes no sports1 61061
.
.
.
RETURN - repeat, U - continue uninterrupted, Q - quit
Запомните транзакционный номер координатора (Crd-task), имя координатора видно в поле Coord и указывает на sports1. Следовательно, необходимо запустить снова PROMON на базе sports1. Только в этот раз выбрать в меню C (Coordinator Information). Экран этого меню запросит номер транзакции, введите наш 61061:
PROGRESS MONITOR Release 10.0A
Database: /users/sports1
Q. QUIT
Enter the transaction number you want to find out if committed: 61061
На экран будет выдано сообщение о статусе транзакции:
Scan the logs...
** Transaction 61061 has committed.
Q. QUIT
Enter the transaction number you want to find out if committed:
Данное сообщение говорит о завершении транзакции базой sports1. Теперь вам необходимо запустить PROMON для базы sports2 и выбрать в меню 1 (Resolve Limbo Transaction), появится следующий экран:
Usr PID Time of Login User ID TTY Coord Crd-task
15 3308 Fri Apr 5 14:19:45 2002 paul mach1 ttyp1 sports1 61061
1 Abort a Limbo Transaction
2 Commit a limbo Transaction
Q Quit
Enter choice>
Выберите 2 (Commit a Limbo Transaction), и ответьте на следующий запрос:
Enter the user number whose transaction you want to commit:
Введите номер пользователя, указанный на предыдущем экране. PROMON завершит транзакцию на базе sports2 и отобразит следующее сообщение:
User 15: commit transaction and disconnect.
Если больше нет неопределенных транзакций, то ситуация разрешена и ни каких дополнительных действий не требуется.
Поддержка Java Transaction API (JTA)
OpenEdge RDBMS обеспечивает поддержку JTA в OpenEdge SQL для работы с распределенными транзакциями в SQL. JTA обеспечивает управление транзакциями между менеджером транзакций и менеджером ресурсов согласно стандарта J2EE. В этом сценарии, OpenEdge выступает в роли менеджера ресурсов и сервера приложений SQL, а клиент в роли менеджера транзакций. База данных не является окончательной точкой в работе распределенной транзакции. Для детального изучения J2EE и JTA, обратитесь к документации по Java.
Когда база данных OpenEdge настраивается как менеджер ресурсов для JTA транзакций, менеджер транзакций отвечает за установку и поддержку состояния транзакций. База данных получит идентификатор в контексте глобальной транзакции. Возможно, что многочисленные потоки обрабатывают транзакцию, влияя некоторым образом на транзакционный процесс:
- Записи будут блокироваться JTA транзакцией без привязки к конкретному пользователю.
- Возможны блокировки записей при старте базы данных
- Блокировки принадлежащие транзакции – не пользовательские.
Влияние JTA на ресурсы
Включение JTA на базе данных увеличивает потребление следующих ресурсов:
- After-image и before-image файлы – дополнительная запись описаний JTA транзакций и табличных блокировок. AI и BI должны быть увеличены на 30% при включении JTA.
- Lock Table (-L) – JTA транзакции могут блокировать записи на более длительный период чем обычные локальные транзакции.
- Transaction Table – количество строк в таблице транзакций увеличится на максимальное количество JTA транзакций. Максимальное количество JTA транзакций контролируется параметром запуска базы данных – maxxids.
- Xid Table – дополнительная таблица для хранения информации о JTA транзакциях. Размер таблицы определяется максимальным количеством JTA транзакций и контролируется стартовым параметром –maxxids.
Влияние JTA на процессы
Активация базы данных в качестве JTA менеджера ресурсов изменяет процессы базы данных:
- Crash recovery – процесс crash recovery отрабатывает каждый раз при старте базы в одно или в много пользовательском режимах. База с включенным JTA должна выполнять crash recovery в многопользовательском режиме. Попытки выполнить crash recovery в однопользовательском режиме приведут к ошибке, если JTA транзакции существуют.
- Roll forward recovery – ai – файлы сформированные на базе данных с JTA, могут быть применены только к базе данных с включенным JTA. К тому же параметры endtime и endtrans для ROLL FORWARD будут не доступны.
- OpenEdge Replication- база данных с включенным JTA не может реплицироваться.
- Before-image – длинные JTA транзакции предотвращают многократное использование bi кластеров.
Включение JTA
Перед тем как установить базу данных в качестве JTA менеджера ресурсов, необходимо включить JTA поддержку :
proutil db-name -C enablejta
База данных должна находиться в offline. Включение JTA деактивирует after-imaging, поэтому необходимо его перезапустить после включения JTA.
Для исключения базы данных из распределенных JTA транзакций необходимо отключить поддержку JTA:
proutil db-name -C disablejta
При этом база данных должна находиться в Offline.
Мониторинг JTA транзакций
Утилита PROMON показывает информацию о JTA транзакциях и их блокировках в экранах Record Locking Table и Active Transactions. В этих экранах поле Trans State отображает статус JTA транзакций, Trans ID – внутренний транзакционный номер.
Для JTA транзакции возможны следующие статусы:
- Active JTA – Текущая выполняемая транзакция
- Idle JTA – Транзакция сейчас не выполняется
- Prepared JTA – подготовленная транзакция
- RollbackOnly JTA – Транзакция столкнулась с ошибкой
- Committed JTA – транзакция в процессе завершения
Разрешения JTA транзакций
Поскольку OpenEdge освобожден от транзакционного контроля JTA транзакций, опасно вмешиваться и вручную решать распределенные JTA транзакции. В результате вы можете получить нарушение целостности базы данных. Вмешиваться в ручную допустимо только в случае возникновения катастрофических последствий возникших ошибок. При такой необходимости используйте PROMON для определения и решения JTA транзакций:
1. Запустите PROMON
promon db-name
2. В основном меню выберите J (Resolve JTA Transaction). Откроется следующее окно:
WARNING: Committing or rolling back a JTA transaction can compromise
WARNING: referential integrity. Proceed with EXTREME caution.
1. Display all JTA Transactions
2. Rollback a JTA Transaction
3. Commit a JTA Transaction
Q. Return to main menu
Enter your selection:
3. Выберите 1 (Display all JTA Transaction).
OpenEdge Release 10 Monitor
Tran Id Usr JTA State XID
1492 5 JTA Prepared 4a982a20-49b7-11da-8cd6-0800200c9a66
1494 16 JTA Active 0
Обратите внимание на Tran ID, эта информация будет нужна для решения каждой JTA транзакции.
4. Для каждой не выполненной JTA транзакции, определите, собираетесь ли вы завершить или откатить транзакцию
5. Если вы решили завершить транзакцию, выберите 3 (Commit a JTA Transaction), иначе – 2 (Rollback a JTA Transaction). Вам необходимо будет ввести Tran ID, и подтвердить ваши намерения. Информация о завершении или откате транзакции будет записана в лог базы данных (.lg).
Повторите процедуры 4 и 5 для каждой не выполненной JTA транзакции.
|
Главная
