Реализация аварийного восстановления в системе IBM PureData System for Transactions

Восстановление с использованием функциональности DB2 High Availability and Disaster Recovery

Узнайте, как настроить и осуществить аварийное восстановление для баз данных продукта IBM® DB2® V10.5 в системе IBM PureData® System for Transactions. Описываемое решение основано на функциональности DB2 High Availability and Disaster Recovery.

Энцо Чалини, главный архитектор по системам IBM PureData Systems, IBM

Enzo Cialini photoЭнцо Чалини (Enzo Cialini) на протяжении десяти лет занимается технологиями баз данных в лаборатории IBM в Торонто и является обладателем сертификата DB2 UDB Database Administration (администрирование баз данных DB2 UDB) и сертификата DB2 UDB Database Application Development (разработка приложений DB2 UDB). Кроме того, он является обладателем сертификатов Advanced Technical Expert in DB2 for DRDA и сертификата Advanced Technical Expert in DB2 for Clusters. Э. Чалини на протяжении многих лет занимается применением продукта DB2 в средах высокой готовности; в настоящее время он руководит подразделением DB2 UDB System Verification Test, которое ориентировано на обеспечение высокой готовности. Э. Чалини имеет обширный опыт внедрения и поддержки программного обеспечения, а также оказания консультационных услуг.



Иэн Хэйкс, руководитель по созданию информационных активов для платформы IBM PureData Systems, IBM

Author photaИэн Хейкс (Ian Hakes) — ведущий автор технических статей по продукту IBM PureData System for Transactions. Последние 15 лет он участвовал в создании продуктов и технологий на основе баз данных IBM.



Ричард Любелл, разработчик информационных активов, IBM

Richard Lubell photoРичард Любелл (Richard Lubell) — разработчик информационных активов в лаборатории IBM в Дублине. Он участвует в создании программного обеспечения с 2000 года и специализируется на следующих направлениях: создание руководств и учебных материалов по финансовым транзакционным приложениям и приложениям для управления контентом, подготовка руководящего персонала, представление бизнес-процессов. В настоящее время занимается созданием документации для решения IBM Smart Analytics System и для облачных платформ IBM типа DBaaS для баз данных.



Пол Макинерни, специалист по проектированию с ориентацией на пользователей, разработчик для DB2, IBM

Paul McInerney photoПол Макинерни (Paul McInerney) проводит широкие исследовательские опросы заказчиков хранилищ данных по вопросам использования различных функций DB2, в том числе рассматриваемых в данной статье.



17.03.2014

Введение

Чтобы поддерживать максимальную эффективность потоков работ, корпоративным приложениям требуется источник данных с бесперебойной доступностью. Любая остановка по причине локальной аварии способна сделать ответственные базы данных недоступными. Минимизация продолжительности отключений и масштабов потери данных — это не просто требование бизнеса; это производственная необходимость.

В этой статье описывается настройка и работа решения аварийного восстановления для баз данных DB2 V10.5 в системе IBM PureData System for Transactions с пакетом исправлений Fix Pack 3 или более поздним. Это решение основано на функциональности DB2 High Availability and Disaster Recovery (HADR) и включает дополнительные элементы, которые функциональность HADR не реализует непосредственно. Технология HADR реплицирует любые изменения данных в первичной базе данных (источнике) на резервной базе данных (цели). Эта технология полностью интегрирована в продукт DB2 и использует стандартный сетевой интерфейс TCP/IP между первичной и резервной системами баз данных. HADR обеспечивает быстрое выполнение операций передачи управления как для плановых, так и для внеплановых событий.

Функциональность HADR в системе IBM PureData System for Transactions используется для обеспечения аварийного восстановления на уровне системы, на уровне экземпляров и на уровне баз данных. Для описываемого решения требуется две системы PureData System for Transactions. Процедура передачи управления на другую систему (takeover) выполняется в ручном режиме с помощью соответствующих HADR-команд; эту процедуру можно интегрировать в корпоративную стратегию аварийного восстановления.

Рассматриваемый сценарий охватывает весь жизненный цикл решения: настройка, нормальное функционирование и передача управления.

Конфигурация системы аварийного восстановления

Эта статья представляет собой руководство по решению аварийного восстановления, основанному на определенной конфигурации системы IBM PureData System for Transactions. Конфигурация, используемая для иллюстрации описываемых концепций и задач, состоит из двух систем (называемых в тексте System A и System B). Чтобы реализовать сценарий аварийного восстановления в масштабе всего сайта, резервная система должна размещаться в территориально отделенном центре обработки данных. В этом сценарии на одной системе (System A) размещаются все первичные базы данных, а на другой системе (System B) находятся все резервные базы данных. До конфигурирования функциональности аварийного восстановления на системе System A уже исполнялись прикладные рабочие нагрузки, работающие с базами данных. Соответственно, рассматриваемый сценарий спроектирован таким образом, чтобы свести к минимуму отрицательные последствия для исходной системы (System A) при добавлении System B в качестве резервной системы.

Изложенные в этой статье инструкции относятся к среде, которая описывается конфигурацией со следующими параметрами.

Листинг 1. Параметры конфигурации
  Primary System == System A
  DB2 Instance == hdrinst1 (small)
  2CF + 2Member
  0 rack6_c2_ite0.example.com 0 rack6_c2_ite0 – MEMBER
  1 rack6_c2_ite1.example.com 0 rack6_c2_ite1 – MEMBER
  128 rack6_c2_ite0.example.com 0 rack6_c2_ite0 – CF
  129 rack6_c2_ite0.example.com 0 rack6_c2_ite1 – CF
  
  DB2 Database == foo_db
  TCPIP Client/Server port (SVCENAME) == 65100

  Standby System == System B
  DB2 Instance == hdrinst1 (small)
  2CF + 2Member
  0 rack7_c2_ite2.example.com 0 rack7_c2_ite2 – MEMBER
  1 rack7_c2_ite3.example.com 0 rack7_c2_ite3 – MEMBER
  128 rack7_c2_ite2.example.com 0 rack7_c2_ite2 – CF
  129 rack7_c2_ite3.example.com 0 rack7_c2_ite3 – CF
  
  DB2 Database == foo_db
  TCPIP Client/Server port (SVCENAME) == 65100

Механизм аварийного восстановления

В системе IBM PureData System for Transactions технология HADR конфигурируется и функционирует на каждой базе данных. Согласно стандарту DB2 HADR, определенные аспекты системной среды должны оставаться идентичными на обеих системах, чтобы резервная система могла беспрепятственно функционировать после передачи управления. Идентичными должны быть следующие аспекты первичной системы и резервной системы.

  • Конфигурация базы данных DB2
  • Конфигурация экземпляра DB2
  • Аспекты системной конфигурации

Технология HADR в контексте PureData

Большинство концепций и задач HADR применимы при использовании технологии HADR в системе IBM PureData System for Transactions, однако есть ряд особенностей.

Во-первых, система PureData осуществляет хостинг экземпляров DB2 pureScale®, а использование экземпляров HADR в среде DB2 pureScale имеет определенную специфику. Более подробную информацию можно получить в разделе High availability disaster recovery in DB2 pureScale environments Информационного центра DB2.

Во-вторых, эта система обладает встроенными возможностями по развертыванию баз данных и управлению ими. Эти возможности имеют определенные преимущества и ограничения относительно других сред DB2 HADR.

Основная цель этой статьи состоит в изложении рекомендаций, адаптированных к средам PureData System for Transactions.


Задачи, предусматривающие аварийное восстановление

Описываемые нами задачи предполагают, что первичная система (System A) действует и исполняет рабочие нагрузки базы данных. Вторая система (System B) располагается в другом центре обработки данных. System B — это резервная система, предназначенная для ситуаций, когда в результате какой-либо аварии система System A оказывается неспособна обрабатывать транзакции.

Задача: Конфигурирование аспектов системного уровня

Для этой задачи необходимо настроить сетевое TCP/IP-соединение между сетями передачи данных системы System A и системы System B. Все компоненты системы System A имеют возможность обращаться ко всем компонентам в системе System B и наоборот.

Задача: Настройка каждого экземпляра DB2 на резервной системе

Эта задача состоит их следующих этапов.

  1. Разверните на системе System B экземпляр, основанный на существующем экземпляре в системе System A.
  2. Задайте стратегию распространения изменений на уровне экземпляров между системой System A и системой System B, чтобы сохранять идентичность между первичным и резервным экземплярами.

Задача: Конфигурирование HADR для каждой базы данных в экземпляре DB2

Эта задача состоит их следующих этапов.

  1. Разверните новую базу данных в экземпляре, развернутом на системе System B.
  2. Восстановите резервную копию базы данных системы System A в базе данных, только что развернутой на системе System B.
  3. Задайте стратегию распространения изменений на уровне баз данных между системой System A и системой System B, чтобы гарантировать идентичность параметров баз данных.
  4. Сконфигурируйте и запустите HADR-операции на System A и на системе System B.

Теперь конфигурация HADR настроена таким образом, что System B служит резервной для System A.

Задача: Использование функций PureData в среде HADR

Эта задача предусматривает выполнени стандартных операций на первичной системе (System A) или на резервной системе (System B).

Применительно к первичной системе добавление технологии HADR оказывает лишь небольшое влияние на стандартные операции или вообще не оказывает на них никакого влияния. Применительно к резервной системе операции резервного копировании базы данных или подключения к базе данных не поддерживаются, поскольку базы данных играют роль резервных.

Задача: Выполнение процедуры передачи управления в системе PureData.

Эта задача предусматривает выполнение передачи управления (takeover) в случае планового или внепланового события.

Выполнение HADR-операций для передачи управления на системе IBM PureData System for Transactions не имеет никаких особенностей по сравнению с типичной системой DB2 pureScale.


Аспекты системного уровня

Настройка системного уровня относится к обязательному начальному конфигурированию систем, после которого они готовы к использованию администраторами баз данных. В этом разделе рассматриваются задачи интеграции аппаратных средств, сетевых средств и центра обработки данных, выполняемые системными администраторами.

Обязательные требования к аппаратным средствам

И первичная система, и резервная система должны представлять собой системы IBM PureData System for Transactions. Резервная система должна иметь столько же вычислительных узлов/элементов, как и первичная система, для которого создается HADR-конфигурация. Это гарантирует, что ресурсов резервной системы будет достаточно для охвата всех вычислительных узлов/элементов, используемых первичным экземпляром.

Обязательные требования по безопасности

Если в ваших системах управление безопасностью осуществляется посредством пользователей консоли:

  • Необходимо создать учетные записи пользователей с идентичными паролями на первичной системе и на резервной системах. Это необходимо, чтобы гарантировать доступ пользователей после событий аварийного восстановления.
  • Для выполнения задач конфигурирования HADR пользователи консоли на обеих системах должны иметь полномочия Create new DB2 pureScale instances позволяющие развертывать экземпляры.

Если в ваших системы для управления безопасностью используются LDAP-пользователи/группы:

  • И первичная, и резервная системы должны иметь доступ к одному и тому же контенту LDAP-сервера. Это необходимо для того, чтобы гарантировать доступ пользователей после событий аварийного восстановления.
  • Перед развертыванием экземпляров необходимо с помощью консоли Workload Console сконфигурировать и задействовать плагин LDAP. Нажмите Cloud > System Plug-ins. SВыберите плагин LDAP и нажмите Configure. Обратитесь к своему администратору по LDAP для получения конфигурационных параметров, необходимых для этого плагина.
  • Для выполнения задач конфигурирования HADR учетные записи LDAP должны иметь полномочия Create new DB2 pureScale instances, позволяющие развертывать экземпляры.

Первичная и резервная системы должны использовать одну и ту же форму аутентификации (LDAP или консоль). Сочетание разных методов управления безопасностью не поддерживается.

Уровни авторизации пользователей

Пользователь, выполняющий процедуры конфигурирования HADR, должен являться владельцем экземпляра или назначенным им представителем, либо владельцем базы данных с правами SYSADM или SYSCTL. Этот пользователь должен существовать на обеих системах.

Владелец экземпляра или любой другой пользователь консоли с правами администратора для этого экземпляра может с помощью консоли Workload Console предоставить надлежащие права на администрирование DB2 пользователю уровня экземпляров или уровня баз данных.

Управление пользователями уровня экземпляров осуществляется с помощью панели DB2 pureScale Instances (нажмите Database > DB2 pureScale Instances). Выберите экземпляр и добавьте учетную запись пользователя к списку Access granted to

Управление пользователями уровня баз данных осуществляется с помощью панели Databases (нажмите Database > Databases). Выберите базу данных и добавьте учетную запись пользователя к списку Access granted to.

Сетевые средства

Сетевой администратор должен подключить первичную и резервную системы к существующей высокоскоростной и высокопроизводительной TCP/IP-сети, связывающей участвующие в конфигурации центры обработки данных. Каждый элемент в первичной системе должен быть в состоянии обращаться к элементам в резервной системе.

Для проверки корректности сетевой конфигурации можно войти в каждый элемент в экземпляре первичной системы и подтвердить доступность каждого элемента резервной системы посредством ping-запросов. Аналогичным образом войдите в каждый элемент на экземпляре резервной системы и подтвердите возможность доступа к каждому элементу первичной системы посредством ping-запросов.

Конфигурирование доступа к Tivoli Storage Manager

Чтобы облегчить восстановление базы данных на резервной системе, необходимо, чтобы резервная система имела доступ к резервному образу базы данных, созданному на первичной системе.

Перед началом работы убедитесь в том, что компонент Tivoli® Storage Manager уже установлен и сконфигурирован на центральном сервере, к которому имеют доступ обе системы, или на отдельных серверах Tivoli Storage Manager, связанных друг с другом посредством узла репликации Tivoli Storage Manager.

Перед развертыванием экземпляра (экземпляров) сконфигурируйте и активируйте плагин TSM с помощью консоли Workload Console. Нажмите Cloud > System Plug-ins. Выберите плагин TSM и нажмите Configure.


Настройка на уровне рабочих нагрузок

Настройка на уровне рабочих нагрузок — это конфигурирование, необходимое для исполнения рабочих нагрузок баз данных в системе PureData System for Transactions. Это конфигурирование, которое обычно осуществляют администраторы баз данных, делится на следующие два уровня.

  1. Необходимая настройка для каждого экземпляра DB2, который осуществляет хостинг одной или нескольких резервных баз данных.
  2. Необходимая настройка для каждой резервной базы данных DB2 pureScale.

Настройка экземпляра DB2 на резервной системе

Разверните экземпляр DB2 Version 10.5 на резервной системе. Любые или все активные базы данных в экземпляре DB2 Version 10.5 на первичной системе можно сконфигурировать для аварийного восстановления.

Процедура настройки резервного экземпляра

Разверните новый экземпляр на резервной системе. В консоли Workload Console нажмите Database > DB2 pureScale Instances. На этой панели нажмите на зеленый значок "плюс", а затем укажите опции для своего нового экземпляра. Этот экземпляр должен иметь такой же размер, как и активный первичный экземпляр, с таким же количеством элементов DB2 pureScale. Резервный экземпляр должен иметь такое же имя, как и первичный экземпляр.

Если этого еще не сделано, создайте или обновите учетные записи пользователей консоли для владельца резервного экземпляра для обеспечения доступа к этому экземпляру.

Если на первичной системе вы обновили конфигурационные параметры экземпляра по умолчанию, внесите такие же изменения в новый резервный экземпляр на резервной системе, чтобы гарантировать беспрепятственное выполнение операций после HADR-процедуры передачи управления.

В Приложении B описывается скрипт для автоматизации сравнения и обновления параметров конфигурации на первичной и резервной системах.


Порты HADR

И первичной, и резервной базам данных требуется порт для сервиса HADR. Если на одном экземпляре сконфигурировано на использование HADR более одной базы данных, необходимо задать по одному порту для каждой такой базы данных.

Если между первичной системой и резервной системой имеется брандмауэр (межсетевой экран), убедитесь, что для обоих направлений задано исключение для портов, которыми пользуются базы данных, в т.ч. для портов HADR.

В качестве порта сервиса HADR нельзя использовать порты, используемые для типичных операций базы данных DB2. По умолчанию порты DB2 pureScale имеют следующие номера: 50001, 56000, 56001, 60000 — 60004.

В ходе настройки HADR заданные порты используются в следующих параметрах базы данных: HADR_LOCAL_SVC, HADR_REMOTE_HOST и HADR_TARGET_LIST.

Ваш сетевой администратор должен сконфигурировать сетевую маршрутизацию таким образом, чтобы все элементы системы System A могли обращаться ко всем элементам в системе System B и наоборот.


Верификация сетевого соединения

Для верификации сетевого соединения между первичной и резервной системами выполните следующие шаги.

  1. На первичной системе определите топологию базы данных с помощью консоли Workload Console, для чего нажмите: Database > Databases. Выберите свою базу данных и запишите значения параметров Host и IP address, показанные в панели Show database members.
  2. На резервной системе убедитесь в том, что резервная база данных имеет такую же топологию, для чего повторите предыдущий шаг на резервной системе. Количество хостов должно быть одинаковым, и все они должны иметь состояние STARTED, хотя хосты и IP-адреса будут другими.
  3. На каждом элементе первичной системы протестируйте соединение посредством ping-запросов к каждому элементу резервной системы с использованием имени хоста. От элемента Member 0 на первичной системе инициируйте ping-запрос к элементу Member 0 и элементу Member 1 на резервной системе:
    ping rack6_c2_ite0
    ping rack6_c2_ite1
    Повторите этот шаг для элемента Member 1 на первичной системе. Если этот шаг оказался успешным, повторите его посредством подачи запроса от резервной системы к первичной системе.
  4. Если предыдущий шаг завершился неудачей, повторите этот процесс с использованием IP-адреса, отображенного в консоли Workload Console, вместо имен хостов узлов резервной системы:
    ping 20.155.4.142
    ping 20.155.4.143

    Если этот шаг оказался успешным, повторите его посредством подачи запроса от резервной системы к первичной системе, а затем продолжайте процесс настройки HADR. Если этот шаг завершился неудачей, обратитесь к своему сетевому администратору на предмет анализа сетевой маршрутизации между первичной и резервной системами.

Настройка резервной базы данных

Базы данных на первичной и резервной системах должны быть сконфигурированы таким образом, чтобы у них совпадали следующие параметры: версия операционной системы, версия DB2, конфигурация табличного пространства, пространство системного журнала.

Создание резервной базы данных

Разверните резервную базу данных посредством восстановления резервного образа существующей первичной базы данных на резервной системе.

На резервной системе:

  1. С помощью консоли Workload Console и такой же учетной записи владельца экземпляра, как у первичного экземпляра (например, hdrinst1) разверните пустую базу данных с таким же именем, как у первичной базы данных (например, foo_db). Нажмите Database > Databases. На этой панели нажмите на зеленый значок "плюс", а затем задайте опции для своей новой базы данных.
  2. Чтобы предотвратить подключение к этой базе данных со стороны компонента Database Performance Monitor, необходимо деактивировать сбор данных. В консоли Workload Console нажмите Database > Database Performance Monitor. Нажмите Databases и выберите пустую базу данных HADR (foo_db) из списка соединений. Нажмите на ниспадающий список Monitor и выберите Disable Automatic Collection.
  3. Кроме того, для базы данных необходимо отключить предупреждения о состоянии. В консоли Database Performance Monitor нажмите Health > Alerts и откройте вкладку Health Alert Configuration. Выберите пустую базу данных HADR (foo_db) и снимите флажок Monitor database health, а затем нажмите Apply.
  4. Восстановите резервный образ базы данных первичной системы в новой пустой базе данных (foo_db) на резервной системе.

Создание резервного образа первичной базы данных:

  1. На первичной системе создайте резервную копию базы данных на Tivoli Storage Manager с помощью панели Backup в консоли системы PureData System for Transactions.
  2. Если первичная и резервная системы используют разные серверы Tivoli Storage Manager, примените репликацию узла Tivoli Storage Manager для перемещения резервного образа с первичной системы на резервную систему.
  3. Зафиксируйте самую последнюю метку времени и убедитесь в том, что такая же метка времени существует на резервной системе.

Чтобы восстановить резервный образ, можно в командной строке подать команду восстановления резервной базы данных из резервной копии первичной базы данных.

В командной строке на резервной системе:

  1. Выполните на любом узле команду restore.
    db2 RESTORE DB <mydb> INTO <mydb> USE tsm TAKEN AT <timestamp>
    где <mydb>— это имя базы данных, а параметр <timestamp> можно взять из задачи создания резервной копии первичной базы данных.

При восстановлении базы данных на резервной системе оставьте базу данных в состоянии rollforward pending. В противном случае команда запуска HADR не сможет завершиться, и резервная база данных останется в состоянии failed.

Для завершения развертывания выполните следующую процедуру.

  • Повторно активируйте компонент Database Performance Monitor. На резервной системе снова включите сбор данных, осуществляемый с помощью Database Performance Monitor. В консоли Workload Console нажмите Database > Database Performance Monitor. Нажмите Databases и выберите из списка соединений только что восстановленную копию резервной базы данных (foo_db). Нажмите на ниспадающий список Monitor и выберите Enable Automatic Collection.

Компонент Database Performance Monitor не обеспечивает мониторинг базы данных на резервной системе, поскольку база данных играет роль резервной и не принимает соединений. Тем не менее если активировать компонент Database Performance Monitor для базы данных на резервной системе, операции мониторинга запустятся в тот момент, когда база данных резервной системы начнет функционировать в качестве первичной.


Конфигурирование HADR

Базовые сведения

Для выполнения этих операций необходимо быть владельцем базы данных или пользователем с правами SYSCTL или SYSADM

Задачу конфигурирования HADR необходимо выполнить по одному разу для каждой резервной базы данных.

В Приложении B описывается скрипт с инструкциями по верификации параметров базы данных HADR и автоматизации процессов конфигурирования HADR на первичной и на резервной системах.

Убедитесь в том, что следующим параметрам баз данных присвоены рекомендованные значения для конфигурирования HADR. В командной строке выполните следующую команду:

db2 get db cfg for foo_db
  • LOGINDEXBUILD – Имеет значение ON. Это значение не дает резервной системе ждать построения некорректных индексов, что обеспечивает наилучшую производительность для технологии HADR. По умолчанию этот параметр имеет значение OFF.
  • LOGARCHMETH1 – Имеет значение TSM. Присвоение значения, отличного от OFF деактивирует циркулярное журналирование. При циркулярном журналировании в случае заполнения журнала журнальное пространство используется повторно; потенциально это может привести к потере транзакций, если журналы не смогут синхронизироваться перед заполнением и перезапуском первичного журнала. Этому параметру присваивается значение TSM, когда система регистрируется на сервере Tivoli Storage Manager.
  • INDEXREC – Если этому параметру присвоено значение RESTART, то при выполнении процедуры takeover производится повторное построение неверных индексов. По умолчанию этот параметр имеет значение RESTART.

Если какие-либо из этих параметров заданы неправильно, скорректируйте соответствующие значения с помощью следующей команды:

db2 UPDATE DB CFG FOR <database> USING <parameter name> <parameter value>

Следующие параметры используют номера портов, которые не должны совпадать с номерами портов, выделенных первичному и резервному экземплярам DB2 pureScale.

  • HADR_LOCAL_HOST – Имя локального хоста. Значение этого параметра на первичной системе должно совпадать со значением параметра HADR_REMOTE_HOST на резервной системе. Значение этого параметра на резервной системе должно совпадать со значением параметра HADR_REMOTE_HOST на первичной системе.
  • HADR_TARGET_LIST – Список целевых пар "хост/порт", представляющих резервную базу данных.
  • HADR_REMOTE_HOST – Имя удаленного хоста. Значение этого параметра на первичной системе должно совпадать со значением параметра HADR_LOCAL_HOST на резервной системе. Значение этого параметра на резервной системе должно совпадать со значением параметра HADR_LOCAL_HOST на первичной системе.
  • HADR_LOCAL_SVC – Имя TCP/IP-сервиса или номер порта, на котором локальная HADR-система принимает соединения.
  • HADR_REMOTE_INST – Имя удаленного экземпляра. Значение этого параметра должно быть одинаковым на первичной системе и на резервной системе.

В разделе под названием HADR ports описывается, какие порты требуются операциям базы данных DB2 pureScale. Например, на первичной системе могут использоваться следующие параметры:

HADR_TARGET_LIST {rack7_c2_ite2:4000|rack7_c2_ite3:4000}
HADR_REMOTE_HOST {rack7_c2_ite2:4000|rack7_c2_ite3:4000}
HADR_REMOTE_INST hdrinst1
HADR_SYNCMODE ASYNC

На резервной системе, в свою очередь, могли бы использоваться следующие параметры:

HADR_TARGET_LIST {rack6_c2_ite0:4000|rack6_c2_ite1:4000}
HADR_REMOTE_HOST {rack6_c2_ite0:4000|rack6_c2_ite1:4000}
HADR_REMOTE_INST hdrinst1
HADR_SYNCMODE ASYNC

Процесс

Команды конфигурирования на глобальном уровне требуется выполнять лишь на одном элементе кластера. Конфигурационные изменения применяются ко всем элементам.

Чтобы обновить локальные IP-адреса или имена элементов, команды конфигурирования на уровне элементов должны применяться к каждому элементу.

Все команды должны быть выполнены из командной строки DB2.

Сконфигурируйте настройки HADR (конфигурационные значения базы данных) для базы данных сначала на первичной системе (System A), а затем на резервной системе (System B).

На системе System A:

  • Обновления на уровне глобальных параметров; исполняются на любом узле:
    db2 "UPDATE DB CFG FOR foo_db USING
     HADR_TARGET_LIST {rack7_c2_ite2:4000|rack7_c2_ite3:4000}
     HADR_REMOTE_HOST {rack7_c2_ite2:4000|rack7_c2_ite3:4000}
     HADR_REMOTE_INST hdrinst1
     HADR_SYNCMODE ASYNC"
  • Обновления параметров на уровне элементов:
    • Для элемента Member 0:
      db2 "UPDATE DB CFG FOR foo_db MEMBER 0
       USING HADR_LOCAL_HOST rack6_c2_ite0
          HADR_LOCAL_SVC 4000"
    • Для элемента Member 1:
      db2 "UPDATE DB CFG FOR foo_db MEMBER 1
       USING HADR_LOCAL_HOST rack6_c2_ite1
          HADR_LOCAL_SVC 4000"

На системе System B:

  • Обновления на уровне глобальных параметров; исполняются на любом узле:
    db2 "UPDATE DB CFG FOR foo_db USING
     HADR_TARGET_LIST {rack6_c2_ite0:4000|rack6_c2_ite1:4000}
     HADR_REMOTE_HOST {rack6_c2_ite0:4000|rack6_c2_ite1:4000}
        HADR_REMOTE_INST hdrinst1
        HADR_SYNCMODE ASYNC"
  • Обновления параметров на уровне элементов:
    • Для элемента Member 0:
      db2 "UPDATE DB CFG FOR foo_db MEMBER 0 USING
       HADR_LOCAL_HOST rack7_c2_ite2
          HADR_LOCAL_SVC 4000"
    • Для элемента Member 1:
      db2 "UPDATE DB CFG FOR foo_db MEMBER 1 USING
       HADR_LOCAL_HOST rack7_c2_ite3
          HADR_LOCAL_SVC 4000"

В этой точке параметры, связанные с HADR, уже заданы, и системы готовы к запуску процесса HADR.

Запуск HADR

На первичной системе (System A) необходимо запустить HADR на всех элементах первичной базы данных. На резервной системе (System B) необходимо запустить HADR лишь на одном из элементов. Этот элемент обозначается как предпочтительный элемент воспроизведения.

На системе System B:

Перед запуском HADR необходимо деактивировать базу данных на резервной системе:

db2 DEACTIVATE DATABASE foo_db

Для элемента Member 0 введите следующую команду:

db2 START HADR ON DATABASE foo_db AS STANDBY

На системе System A:

Для ВСЕХ элементов введите следующую команду:

db2 START HADR ON DB foo_db AS PRIMARY

Удостоверьтесь в том, что HADR функционирует надлежащим образом.

На системе System A вызовите функцию MON_GET_HADR table:

db2 "SELECT LOG_STREAM_ID, PRIMARY_MEMBER, HADR_ROLE,
 STANDBY_MEMBER, STANDBY_ID, HADR_STATE,
 varchar(PRIMARY_MEMBER_HOST,30) AS PRMRY_MEMBER_HOST,
 varchar(STANDBY_MEMBER_HOST,30) AS STNDBY_MEMBER_HOST
    FROM TABLE (MON_GET_HADR(-2))"

Пример выходной информации.

LOG_STREAM_ID PRIMARY_MEMBER HADR_ROLE STANDBY_MEMBER
------------- -------------- --------- --------------
1             1              PRIMARY   0
0             0              PRIMARY   0

Пример выходной информации (продолжение).

STANDBY_ID HADR_STATE PRMRY_MEMBER_HOST STNDBY_MEMBER_HOST
---------- ---------- ----------------- ------------------
1          PEER       rack6_c2_ite1     rack7_c2_ite2
1          PEER       rack6_c2_ite0     rack7_c2_ite2

Убедитесь в том, что каждый из первичных элементов присутствует и что у каждого из них параметр PRIMARY имеет значение HADR_ROLE.

С помощью поля STANDBY_MEMBER убедитесь в том, что текущим элементом воспроизведения является элемент Member 0 в системе System B (предпочтительный элемент воспроизведения). Каждый поток журнала сообщает об одном и том же резервном элементе, поскольку все первичные элементы соединены с этим резервным элементом.

Вы также может воспользоваться командой db2pd для возвращения подробной информацию о среде HADR:

db2pd –db foo_db –hadr
Листинг 2. Пример выходной информации команды db2pd
Database Member 0 -- Database foo_db -- Active -- 
    Up 0 days 01:00:24 -- Date 2013-07-24-20.33.16.378486

                 HADR_ROLE = PRIMARY
               REPLAY_TYPE = PHYSICAL
             HADR_SYNCMODE = ASYNC
                STANDBY_ID = 1
             LOG_STREAM_ID = 0
                HADR_STATE = PEER
                HADR_FLAGS =
       PRIMARY_MEMBER_HOST = 20.155.4.140
          PRIMARY_INSTANCE = hdrinst1
            PRIMARY_MEMBER = 0
       STANDBY_MEMBER_HOST = 20.155.2.140
          STANDBY_INSTANCE = hdrinst1
            STANDBY_MEMBER = 0
       HADR_CONNECT_STATUS = CONNECTED
  HADR_CONNECT_STATUS_TIME = 07/24/2013 20:29:39.895023 (1374697779)

Итак, вы успешно сконфигурировали аварийное восстановление с использованием технологии HADR для базы данных на системе IBM PureData System for Transactions.

Конфигурирование повторной маршрутизации клиента

Если вы хотите, чтобы после наступления события аварийного восстановления на первичной системе клиентские приложения автоматически маршрутизировали запросы на соединение к резервной системе, выполните шаги, изложенные в этом разделе.

Параметр уровня элементов

  • На системе System A:

    Для элемента Member 0:

    db2 "UPDATE ALTERNATE SERVER FOR DATABASE foo_db
        USING HOSTNAME rack7_c2_ite2 PORT 65100"
  • На системе System B:

    Для элемента Member 0:

    db2 "UPDATE ALTERNATE SERVER FOR DATABASE foo_db
        USING HOSTNAME rack6_c2_ite0 PORT 65100"

В качестве альтернативного варианта можно использовать процедуру ADMIN_CMD:

CALL SYSPROC.ADMIN_CMD ('UPDATE ALTERNATE SERVER FOR DATABASE foo_db
    USING HOSTNAME rack7_c2_ite2 65100')
CALL SYSPROC.ADMIN_CMD ('UPDATE ALTERNATE SERVER FOR DATABASE foo_db
    USING HOSTNAME rack6_c2_ite0 65100')

Нерегистрируемые операции

HADR обрабатывает только регистрируемые в журнале операции базы данных; другие аспекты аварийного восстановления рабочей нагрузки должны рассматриваться отдельно. Речь идет о следующих аспектах:

  • Настройка идентификаторов пользователей операционной системы на системном уровне
  • Конфигурационные параметры менеджера баз данных на уровне экземпляров
  • Переменные реестра DB2 на уровне экземпляров
  • Конфигурационные параметры базы данных на уровне баз данных
  • Восстановление внешних процедур на уровне баз данных

Если вы используете для этих аспектов ручной процесс, вам необходимо выявить их и в процессе нормального функционирования распространить все изменения на резервную систему.

В Приложении B описывается скрипт, который упрощает задачу сравнения конфигураций баз данных и экземпляров на разных системах. Этот скрипт предоставляет список команд, которые требуются для корректировки этих настроек на резервной системе.


Операции при нормальном функционировании

Состояние системы

Исполняющийся сервис HADR предоставляет несколько показателей для измерения состояния вашей среды.

При вызове табличной функции MON_GET_HADR на первичной системе она возвращает информацию о функциональности HADR на первичной и на резервной базах данных.

Поскольку резервная система не принимает клиентских соединений, для запроса информации непосредственно с резервной системы можно воспользоватся командой db2pd.

Следующие поля, возвращенные табличной функций MON_GET_HADR или командой db2pd детализируют состояние вашего соединения.

  • HEARTBEAT_MISSED – Количество heartbeat-сообщений, которые не были своевременно получены для этого потока журнала начиная с момента запуска базы данных на локальном элементе.
  • HEARTBEAT_EXPECTED – Количество heartbeat-сообщений, которые ожидаются в этом потоке журналирования начиная с момента запуска базы данных на локальном элементе. Сравнение этого значения со значением HEARTBEAT_MISSED является показателем состояния сети на определенном временном интервале.
  • STANDBY_SPOOL_PERCENT - Доля используемого пространства spool space относительно сконфигурированного лимита spool space. Это значение показывает, какую часть пространства spool space использует журнал HADR.
  • STANDBY_ERROR_TIME - Ближайший момент времени, когда резервная система испытала крупную ошибку.
  • HADR_CONNECT_STATUS - Текущее состояние HADR-соединения базы данных. Возможные значения: CONGESTED, CONNECTED, DISCONNECTED.
  • TIME_SINCE_LAST_RECV - Время (в миллисекундах), прошедшее с момента получения последнего сообщения. Когда это значение превышает заданный heartbeat-интервал, считается, что произошла потеря heartbeat-сообщения.
  • STANDBY_RECV_REPLAY_GAP - Среднее количество байтов в промежутке между позицией получения в резервном журнале и позицией воспроизведения в резервном журнала. Это поле указывает на факт отставания резервного журнала. При отставании резервного журнала существует опасность того, что резервная база данных прекратит получение журналов и заблокирует поддержание равноправного состояния с первичной базой данных.

Описание табличной функции MON_GET_HADR в Информационном центре IBM DB2, Версия 10.5 содержит полный список контролируемой информации, которую возвращает эта табличная функция.


Операции передачи управления

Процедура передачи управления при плановом событииr

Переключение ролей между первичной и резервной базами данных для плановых событий можно осуществить с помощью команды DB2 TAKEOVER HADR.

Для выполнения плановой процедуры takeover с базой данных обратитесь к резервному экземпляру системы (System B) и введите следующую CLP-команду:

db2 TAKEOVER HADR ON DATABASE foo_db

Убедитесь в доступности этой базы данных на системе System B, выполнив команду connect:

db2 CONNECT TO foo_db

Теперь база данных на системе System B является первичной, а база данных на системе System A является резервной.

Чтобы после планового события передачи управления вернуться к прежнему состоянию (когда первичная база данных работает на системе System A, а резервная база данных работает на системе System B), инициируйте процедуру передачи управления на системе System A с целью переключения ролей.

db2 TAKEOVER HADR ON DATABASE foo_db

Убедитесь в доступности этой базы данных на системе System A, выполнив команду connect:

db2 CONNECT TO foo_db

Для получения дополнительной информации о команде TAKEOVER обратитесь к разделу HADR commands в Информационном центре IBM DB2, Версия 10.5.

Процедура передачи управления при внеплановом событии

Все внеплановые процедуры аварийного переключения необходимо выполнять в ручном режиме; поддержка автоматического выполнения процедур передачи управления при аварийном восстановлении отсутствует.

Введите следующую команду на резервной системе (System B):

db2 TAKEOVER HADR ON DATABASE foo_db BY FORCE

Заключение

Эта статья посвящена настройке и функционированию альтернативного решения для аварийного восстановления, предназначенного специально для систем IBM PureData System for Transactions. Это решение основано на функциональности HADR в версии DB2 Version 10.5 и задействует лучшие в отрасли возможности DB2, а также учитывает специфику систем IBM PureData System for Transactions.


Благодарности

Авторы благодарят за вклад в написание данной статьи, за ее рецензирование и исправление следующих коллег: Diaa El-Din Ali, Marco Bonezzi, Paddy Burke, Yvonne Chan, Ciaran De Buitlear, Belarmino Fernandez, Brian McKeown, Nancy Miller, Andriy Miranskyy, Ryan Paton, Ismail Rawoof, Pablo Perez Rodriguez, Armin Tabrizi, Michael Zuliani.


Приложение A. Концепции и терминология

Аварийное восстановление— восстановление операций базы данных в случае катастрофической потери работоспособности первичной системы обработки данных. Степень такой потери работоспособности может варьировать в широких пределах в зависимости от серьезности события и от его источника (программное обеспечение, сеть, аппаратные средства или даже вся площадка).

Возможности HADR-решения определяются объемом хранилища, выделенного под резервные копии, от пропускной способности сети и от политик журналирования архивов. Кроме того, необходимо учитывать потребности бизнеса.

  • RPO (Recovery Point Objective – целевая точка восстановления) – объем данных, теряемых в определенном решении. Описываемое решение поддерживает технологию HADR в режимах ASYNC and SUPERASYNC. В системах, отличающихся от PureData System for Transactions, значения показателя RPO в этих синхронизированных режимах одинаковы, а именно: нулевая потеря данных для плановых событий и близкая к нулевой потеря данных для внеплановых событий.
  • RTO (Recovery Time Objective – целевое время восстановления) – время, прошедшее от момента ручного инициирования процедуры передачи управления до момента, когда приложения снова могут подключиться к базе данных (измеряется в секундах для каждой базы данных). Это время не включает в себя интервал от момента идентификации происходящей проблемы до момента, когда оператор в ручном режиме инициирует передачу управления. Одновременно можно переключить несколько баз данных. Показатель RTO для всей системы также измеряется в секундах.

HADR-среда состоит из первичной системы, связанной через TCP/IP-соединение с системой аварийного резерва, которая может находиться в другом городе. При внесении изменений в базу данных на первичной системе журнальные данные непрерывно доставляются из первичной базы данных и повторно вносятся в базу данных на резервной системе. Этот процесс непрерывно обновляет резервную базу данных, что позволяет быстро осуществлять передачу управления. Выделенные соединения позволяют первичным и резервным базам данных поддерживать непрерывный контакт и устанавливать состояние репликации.

Резервная система – система IBM PureData System for Transaction, настроенная на выполнение операций с базой данных в случае катастрофического события, которое делает первичную систему недоступной.

Аварийное переключение (Failover) – быстрое принудительное изменение состояния резервной базы данных с целью ее превращения в первичную базу данных и поддержания доступности данных. Такое изменение состояния должно происходить лишь в том случае, когда первичная база данных прекращает свое функционирование. HADR уведомляет об отказе, если heartbeat-сообщения указывают на прерывание обмена данными между этими двумя системами, однако аварийное переключение не всегда необходимо. При отказе первичной системы выполняется аварийное переключение в ручном режиме, чтобы предотвратить нежелательные перерывы в обслуживании.

Передача управления (Takeover) – обмен ролями между первичной и резервной системами в некритических или в плановых ситуациях.

Обратное переключение(Failback) производится после передачи управления. Система, изначально являвшаяся первичной, возвращается в работу и вновь получает статус первичной. Затем производится изменение ролей, т.е. обратное переключение текущей первичной системы на ее изначальную роль резервной системы.


Приложение B: Скрипты конфигурирования системы

Юридический комментарий. Эти программы не были протестированы при всех возможных условиях; IBM предоставляет их без обязательств предоставления какой-либо поддержки.

IBM ПРЕДОСТАВЛЯЕТ ЭТИ ПРОГРАММЫ ПО ПРИНЦИПУ "КАК ЕСТЬ", БЕЗ КАКИХ БЫ ТО НИ БЫЛО ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ ГАРАНТИИ СОБЛЮДЕНИЯ АВТОРСКИХ ПРАВ, НЕНАРУШЕНИЯ ПРАВ ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ, А ТАКЖЕ ВСЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ И УСЛОВИЯ РЫНОЧНЫХ КАЧЕСТВ И ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ. Некоторые юрисдикции не допускают исключения или ограничения подразумеваемых гарантий; в связи с этим изложенное выше может не распространяться на вас. IBM не несет ответственности за ущерб, который может быть причинен в результате использования, изменения или распространения этих программ или их производных.


Верификация конфигурационных параметров системы

В процессе настройки функциональности HADR администратор баз данных должен собрать конфигурационные параметры экземпляра и базы данных, а также переменные реестра для обеих систем. Только после сравнения и обновления настроек системы производится инициирование технологии HADR на первичной и на резервной системах. Этот процесс сравнения, сопоставления и обновления конфигураций экземпляров и баз данных является трудоемким и подвержен ошибкам со стороны пользователей.

Чтобы упростить эту задачу, мы прилагаем к этой статье предоставляемый по принципу as-is скрипт на языке Perl для выполнения следующих задач.

  • Подключение к экземплярам баз данных на первичной системе (System A) и на резервной системе (System B).
  • Извлечение и сравнение конфигураций экземпляров и баз данных, а также переменных реестра.
  • Создание списка команд, которые требуются для корректировки конфигурации системы System B, чтобы сделать ее идентичной конфигурации системы System.

Этот скрипт должен исполняться на клиентском компьютере, который связан с HADR-системой и на котором установлены продукт DB2 или DB2 Connect и языковая среда Perl. Исполняемые двоичные файлы DB2 и Perl должны быть указаны в переменной срреды $PATH. Откройте командное окно и запустите скрипт с помощью следующей команды.

Листинг 3. Пример скрипта
  perl cfg_replicator.pl -ph <primary_host> -sh <secondary_host>
    -in <instance_name> -pn <primary_host_portnumber>
    -sn <secondary_host_portnumber> -db <database_name>
    -u <username> -p <password> -d <update_direction>
    -o <output_file_name>

Скрипт принимает следующие входные параметры.

  • -ph <primary_host>
    Имя хоста или IP-адрес первичного хоста (System A)
  • -sh <secondary_host>
    Имя хоста или IP-адрес резервного хоста (System B)
  • -in <instance_name>
    Имя экземпляра
  • -pn <primary_host_portnumber>
    Номер порта первичного экземпляра (на System A)
  • -sn <secondary_host_portnumber>
    Номер порта резервного экземпляра (на System B)
  • -db <database_name>
    Имя базы данных.
  • -u <username>
    Идентификатор пользователя (этот пользователь должен иметь разрешение на получение конфигурации экземпляра и базы данных)
  • -p <password>
    Пароль для вышеуказанного идентификатора пользователя
  • -d <update_direction>
    Направление "зеркалирования" операторов (может принимать значение left или right). В случае присвоения значения left скрипт генерирует команды, необходимые для приведения резервной конфигурации (System B) в соответствие с первичной конфигурацией (System A). Вы будете использовать эти команды в стандартном сценарии, который изложен в этой статье. Если вместо этого вы захотите привести конфигурацию первичной системы в соответствии с конфигурацией резервной системы, присвойте этому параметру значение right с целью генерации необходимых команд.
  • -o <output_file_name>
    Имя выходного файла. Этот файл содержит сгенерированные команды, необходимые для согласования конфигураций.

Кроме этого, описываемый скрипт имеет следующие параметры.

  • -help: предоставляет дополнительные технические сведения
  • -man: предоставляет дополнительные технические сведения

Данный скрипт пытается зеркально воспроизвести все конфигурационные параметры. Тем не менее некоторые параметры первичной и резервной систем (например, маршруты к журналам) могут отличаться друг от друга. Перед выполнением сгенерированных команд просмотрите выходную информацию этого скрипта.


Конфигурирование всех настроек HADR

Процесс конфигурирования и настройки технологии HADR на системе PureData System for Transactions сложен, а повторяющийся характер некоторых задач порождает ошибки пользователя.

Этот предоставляемый по принципу as-is скрипт призван помочь в выполнении следующих задач.

  • Обновление конфигурационных параметров базы данных HADR для каждой базы данных.
  • Обновление конфигурационных параметров альтернативного сервера баз данных для каждой базы данных.
  • Активация функции ACR (automatic client reroute).
  • Запуск HADR на резервной и на первичной системах.
  • Демонстрация состояния HADR-среды.

Для использования скрипта неообходимо следующее:

  • Два экземпляра DB2 Version 10.5 pureScale (скрипт работает для любого количества элементов).
  • Первичная база данных, у которой параметру LOGARCHMETH1 присвоено значение TSM, а параметру LOGINDEXBUILD присвоено значение ON
  • Резервная копия первичной базы данных, которая была создана с этими значениями параметров. Эта резервная копия может быть создана с помощью Tivoli Storage Manager или в ручном режиме с помощью стандартных средств резервного копирования DB2.
  • Первичная база данных, способная принимать новые соединения.
  • Одинаковые пользователи экземпляров для обоих экземпляров.
  • Для выполнения этого скрипта пользователь должен иметь полномочия SYSAMD или SYSCTL.
  • Резервный экземпляр должен быть создан с таким же именем экземпляра, как у первичной системы.
  • Первичная система должна иметь сетевое соединение с резервной системой.

Применительно к этому скрипту первичный элемент — это элемент на первичной системе, на которой запущен этот скрипт. Элемент воспроизведения — это резервный элемент, который задан в качестве параметра при запуске скрипта; этот резервный элемент получает и обрабатывает журналы, получаемые от всех первичных элементов.

Сначала этот скрипт проверяет соблюдение всех обязательных условий; конфигурирование HADR осуществляется лишь при положительных результатах этой проверки. Кроме того, скрипт проверяет наличие базового соединения между первичным элементом (на котором вы запустили этот скрипт) и элементом воспроизведения. После проверки соблюдения всех обязательных требований скрипт переходит к конфигурированию HADR на резервном экземпляре, а затем и на первичном экземпляре. Резервная база данных конфигурируется таким образом, чтобы указывать на первичную базу данных; а первичная база данных — наоборот.

Следующий шаг скрипта состоит в активации и запуске HADR. После осуществления основной настройки и обновления конфигурация базы данных на каждом элементе скрипт деактивирует резервную базу данных, а затем запускает HADR на резервной системе с помощью главного элемента (элемента воспроизведения) на резервном экземпляре. После запуска HADR на резервном экземпляре скрипт запускает HADR на каждом элементе первичного экземпляра.

В этот момент HADR начинает синхронизироваться и фиксировать всю регистрируемую информацию из журналов первичной базы данных в журналах резервной базы данных.

Последний шаг конфигурирования состоит в активации функции ACR (automatic client reroute). Эта функция обновляет информацию об альтернативном сервере на каждом элементе таким образом, чтобы при передаче управления все клиентские соединения маршрутизировались к новой первичной системе.

После успешного обновления настроек альтернативного сервера скрипт верифицирует результаты конфигурирования и проверяет фактическое состояние HADR-среды. В этот момент все должно быть запущено и сконфигурировано ожидаемым образом, а все первичные элементы должны иметь равноправный статус.

Этот скрипт запускается из начального каталога пользователя-владельца базы данных на первом элементе первичной базы данных. Его должен запускать владелец базы данных, который был специфицирован в процессе создания базы данных, либо пользователь с полномочиями SYSCTL или SYSADM. Этот пользователь должен быть одинаковым на каждом элементе и иметь одинаковый пароль на каждом элементе.

После копирования файла в начальный каталог на первичном элементе раскройте сжатый файл:

tar –zxvf pdtx_hadr.tar.gz

В разархивированном каталоге hadr внимательно прочитайте инструкции в файле README.txt, а затем запустите скрипт следующей командой:

./pdtx_hadr_setup.sh -d <database> -s <standby_member> -a

В учебном сценарии данной статьи:

./pdtx_hadr_setup.sh -d foo_db -s 0 -a

Скрипт принимает следующие входные параметры.

  • -d <database>
    База данных, которую вы хотите сконфигурировать с технологией HADR
  • -s <standby_member>
    Резервный элемент. Этот элемент является первым элементом в резервном экземпляре (элемент воспроизведения).
  • -a
    Применение конфигурации. Если вызов скрипта осуществляется без параметра -a, он лишь записывает шаги конфигурирования в конфигурационные файлы, находящиеся в каталоге $HOME/hadr/cfg/ на элементе, на котором исполняется этот скрипт. Если параметр -a указан, то скрипт применяет все изменения конфигурации, запускает HADR на резервной и на первичной базах данных, а затем конфигурирует функцию ACR (automatic client reroute).

После применения конфигурации возвращаемым результатом выполнения этого скрипта является текущий статус HADR-среды.


Загрузка

ОписаниеИмяРазмер
Учебные файлы для данной статьиsamples.zip22 КБ

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=966014
ArticleTitle=Реализация аварийного восстановления в системе IBM PureData System for Transactions
publish-date=03172014