Оптимальні методики роботи з DB2: Відновлення після збою примірника DB2 в IBM Smart Analytics System

1. Серія контенту:
2. Цей контент є частиною серії: Оптимальні методики роботи з DB2
3. Малюнок 1. Архітектура примірника DB2, що підтримує відновлення після збоїв
4. Лістинг 1. Файл db2nodes.cfg
5. Стратегія резервування примірника
6. Таблиця 1. Створення резервної копії файлів операційної системи
7. Таблиця 2. Отримання інформації про параметри операційної системи
8. Таблиця 3. Створення tar-файлу домашньої директорії DB2
9. Таблиця 4. Отримання та збереження конфігурації DB2 Manager і супутньої інформації
10. Сценарії відмов
11. Процедура відновлення екземпляра після збою
12. Відновлення після збоїв, причину яких можна встановити
13. Лістинг 2. Зміна прав доступу може призвести до збою
14. Лістинг 3. Використання команди db2iupdt для поновлення примірника з використанням параметрів встановленого...
15. Ресурси для скачування

Оптимальні методики роботи з DB2

Серія контенту:

Цей контент є частиною # з серії # статей: Оптимальні методики роботи з DB2

http://www.ibm.com/developerworks/data/bestpractices/

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Оптимальні методики роботи з DB2

Слідкуйте за виходом нових статей цієї серії.

У цій статті буде показано, як створити резервну копію файлів і параметрів середовища таким чином, щоб у разі пошкодження примірника DB2 можна було відновити його, не порушивши цілісності конфігурації і параметрів середовища. Ця стаття є частиною серії документів, що описують оптимальні методики в області резервування і відновлення даних в середовищі IBM Smart Analytics System (посилання на ці документи наведені в розділі ресурси ).

Лабораторне середовище для цієї статті побудована на базі IBM Smart Analytics System 5600 з одним вузлом адміністрування і двома вузлами даних. В розділі Завантаження ви можете завантажити сценарії, що містять всі необхідні команди для резервування файлів, середовища і конфігураційних параметрів відповідно до рекомендацій цієї статті. Ви можете відредагувати ці сценарії відповідно до конфігурації вашого середовища. Не намагайтеся виконувати ці команди в робочому середовищі.

Доступ до примірника DB2 може бути втрачений з багатьох причин, таким як помилкове зміна прав доступу до файлів, видалення файлів, пошкодження файлової системи. Для швидкого і ефективного усунення наслідків рекомендується завжди мати план відновлення системи. В цьому плані повинні бути враховані всі файли і параметри середовища, що відносяться до примірника DB2; крім того, повинна бути визначена стратегія резервування, яка передбачає створення резервних копій всіх необхідних файлів, що дозволяють відновити екземпляр після збою, що з'явилася в результаті будь-якого можливого події.

Відносини між екземпляром і базою даних не є абсолютними. Видалення ушкодженого примірника не призводить до видалення пов'язаної з ним бази даних. Дані при цьому не втрачаються. Якщо ви можете правильно відновити середу і конфігурацію примірника, ви можете видаляти і заново створювати екземпляр і каталог пов'язаної з ним бази даних стільки раз, скільки захочете.

Реалізуючи стратегію резервування і відновлення для примірника DB2 в середовищі з секціонуванням бази даних, ви знижуєте час можливого простою системи, оскільки в цьому випадку для відновлення конфігурації примірника не потрібно відновлювати весь сервер.

На малюнку 1 зображена архітектура DB2 в середовищі з секціонуванням бази даних. На кожному вузлі працює програмне забезпечення DB2, що підтримує на ньому розділи бази даних. Група розділів IBMTEMPGROUP охоплює вузол адміністрування і два вузла даних. Групи розділів SDPG і IBMCATGROUP розташовані на вузлі адміністрування. Група розділів PDGP охоплює вузли даних, що містять табличні простору.

Малюнок 1. Архітектура примірника DB2, що підтримує відновлення після збоїв

конфігурація примірника

Рішення IBM Smart Analytics System підтримує секціонування баз даних, забезпечуючи тим самим використання масового паралелізму і лінійної масштабованості. У цьому середовищі на розділи розбивається база даних (але не примірник). Примірник створюється один раз на вузлі адміністрування, після чого директорія db2home розподіляється між усіма вузлами-учасниками (серверами), на яких виконується програмне забезпечення DB2. Щоб секціонірованная база даних правильно працювала, необхідно однаково налаштувати на кожному вузлі даних середу операційної системи, включаючи користувачів та групи. Секціонірованная база даних управляється через вузол адміністрування, який управляє доступом до бази даних і її структурою.

У IBM Smart Analytics System кожен вузол даних містить розділи декількох БД. Для кожного розділу БД виділяються ресурси введення / виведення, процесорів і оперативної пам'яті. Крім того, кожен розділ підтримує власні контейнери, журнали і індекси бази даних, а також свій власний менеджер конфігурації бази даних. Запити передаються координатору, який витягує всі необхідні дані.

Кластер, що розглядається в прикладі до цієї статті, складається з трьох вузлів: вузол адміністрування beluga-bvn-05 і два вузла даних - beluga-bvn-06 і beluga-bvn-07. Вузол адміністрування містить один розділ БД, а кожен з вузлів даних містить по чотири розділи. Таким чином, весь кластер складається з 9 розділів.

Примірник був створений і розміщений на всіх вузлах кластера, а база даних - на всіх розділах БД, перерахованих у файлі db2nodes.cfg. У лістингу 1 представлено вміст файлу db2nodes.cfg, розташованого в директорії db2home / sqllib і описує конфігурацію нашого тестового кластера.

Лістинг 1. Файл db2nodes.cfg

0 beluga-bvn-05 0 1 beluga-bvn-06 0 2 beluga-bvn-06 1 3 beluga-bvn-06 2 4 beluga-bvn-06 3 5 beluga-bvn-07 0 6 beluga-bvn-07 1 7 beluga-bvn-07 2 8 beluga-bvn-07 3

У середовищі IBM Smart Analytics System домашня директорія примірника DB2 розташована на вузлі адміністрування і називається / shared_db2home. Між іншими вузлами файлова система розподіляється за допомогою GPFS або NFS, при цьому локальної точкою монтування є директорія / db2home. Оскільки файлова система / db2home кожного вузла є точкою монтування, що посилається на вузол адміністрування, резервну копію цієї папки потрібно створювати тільки на вузлі адміністрування.

Стратегія резервування примірника

Стратегія резервування середовища DB2 повинна включати в себе створення резервних копій файлів операційної системи, примірника DB2 і бази даних DB2. В цьому випадку при відновленні системи можна звертатися до певної резервної копії. Такі операції адресного відновлення ефективні тим, що вони знижують час простою системи.

Увімкніть створення резервних копій примірника в загальний розклад архівації даних. Створюйте резервні копії примірника кожного разу перед внесенням змін до конфігурації середовища, а також після їх внесення. Для створення резервної копії примірника необхідно зібрати наступну інформацію.

• Версії програмного забезпечення
• ліцензії
• Користувачі і групи
• файли
• Директорії примірника

Всі файли, параметри і змінні, перераховані в цьому розділі, формують повний список об'єктів, які повинні бути включені в резервну копію. Ці файли мають невеликий розмір і містять цінну інформацію, яку можна використовувати після відновлення системи з метою узгодження і аналізу її коректної роботи. Крім того, якщо вам потрібна додаткова допомога, інформація, що міститься в цих резервних копіях, може бути затребувана службою підтримки IBM.

У кожній з чотирьох таблиць, представлених в цьому розділі, містяться категорії файлів і конфігураційних параметрів, які необхідно включати в резервні копії. У таблицях 1 і 2 містяться дані, які необхідно резервувати на кожному вузлі. У таблицях 3 і 4 містяться дані, які необхідно резервувати на вузлі адміністрування. В обох випадках резервні копії можуть створюватися від імені власника примірника DB2. Сценарії для створення резервних копій містяться в двох файлах, які доступні в розділі Завантаження .

Таблиця 1. Створення резервної копії файлів операційної системи

Створіть резервні копії наступних файлів операційної системи на всіх вузлах, що містять дані для роботи з DB2. У разі збою в роботі примірника ви зможете уникнути переустановлення операційної системи, просто відновивши ці конфігураційні файли. Файл Опис / etc / services Параметри FCM-мережі DB2 / etc / exports Інформація про експортованих файлових системах / etc / passwd Інформація про користувачів / etc / hosts Імена і IP-адреси інших вузлів кластера / etc / group Інформація про групи / opt / tivoli / tsm / client / api / bin64 / dsm.opt Налаштування сервера архівів (в прикладі був використаний Tivoli Storage Manager) /opt/tivoli/tsm/client/api/bin64/dsm.sys Скопіюйте цю конфігурацію, якщо TSM інтегрований з функцією резервування та відновлення журналів DB2.

Таблиця 2. Отримання інформації про параметри операційної системи

У процесі створення резервних копій зберіть на всіх вузлах інформацію про параметри роботи операційної системи за допомогою наступних команд. Цю інформацію можна використовувати для перевірки операційної середовища після відновлення. Команда Опис db2level> db2level.out Інформація про версії продуктів DB2 oslevel> oslevel.out Рівень операційної системи df> df_g.out Інформація про вільному дисковому просторі mount> mount.out Інформація про змонтованих файлових системах ulimit -a> ulimit.out Параметри Ulimit crontab -l> crontab.out Розклад планувальника Crontab id $ Instance> id.out Використовувані ідентифікатори екземпляра (ID) ~ / sqllib / java / jdk64 / jre / bin / java -version> jdk.out Версія Java JDK ~ / sqllib / java / jdk64 / jre / bin / java com.ibm.db2.jcc.DB2Jcc -version> jcc.out Версія JCC

Таблиця 3. Створення tar-файлу домашньої директорії DB2

Для відновлення екземпляра на вузлі адміністрування вам знадобиться наступна директорія і весь її вміст. Також ця директорія містить різні сценарії, призначені для роботи в вашому середовищі. Для забезпечення підтримки посилань використовуйте команду tar. Команда Опис tar -cvf 2010-07-29.beluga-bvn-05.tar $ HOME / * Упаковка в tar-файл вмісту директорії DB2HOME / на вузлі адміністрування

Таблиця 4. Отримання та збереження конфігурації DB2 Manager і супутньої інформації

Виконайте наступні команди на вузлі адміністрування для отримання знімка конфігурації примірника. Команда Опис db2 get admin cfg> admin.cfg Конфігурація сервера адміністрування DB2 db2set -all> db2set Список значень системних змінних середовища DB2 db2licm -l> db2licm.license.information Інформація про ліцензії DB2 db2cfexp db2cfexp.bak backup Дані експорту конфігурації DB2 db2 list node directory> db2.list.node.directory Список директорій вузла db2 list database directory> db2.list.database.directory Список баз даних db2 list dcs directory> db2.list.dcs.directory Список директорії DCS cp /sqllib/.rhosts .rhosts .bak Довірені вузли Linux-платформ db2 get dbm cfg> dbm.cfg Конфігурація менеджера бази даних $ HOME / .profile Скопіюйте профіль власника примірника $ HOME / sqllib / db2nodes.cfg Скопіюй ті конфігураційний файл вузла і розділів бази даних

Сценарії відмов

Найчастіше відмови в роботі відбуваються в результаті людських помилок, збоїв в роботі служб або пошкодження файлів. Причини можуть бути самими різними - від зміни змінної середовища до зміни конфігураційного файлу операційної системи, який використовується програмним забезпеченням DB2. Сценарії відновлення після збоїв можна розділити на дві групи в залежності від того, чи відома причина виникнення проблеми чи ні. Якщо причина виникнення проблеми відома, її можна вирішити шляхом виправлення відповідного файлу або конфігураційного параметра. Якщо ж причина виникнення проблеми невідома, потрібно повне відновлення екземпляра. У робочому середовищі час відновлення працездатності є більш значущим чинником, ніж час, витрачений на виявлення та усунення проблеми.

Визначте всі можливі сценарії відновлення, які можуть мати місце у вашій робочої середовищі, і розробіть стратегію, що дозволяє відновити роботу примірника незалежно від того, з якої причини сталася відмова. Нижче перераховані чотири найбільш поширених сценарію відмов, які необхідно враховувати при розробці плану відновлення після збоїв.

• Видалення директорії db2home на вузлі адміністрування або видалення екземпляра з необережності. Директорія db2home на вузлі адміністрування використовується всіма іншими вузлами секціонірованной бази даних. Якщо вміст домашньої директорії було пошкоджено або видалено, екземпляр виявиться недоступним.
• Порушена або пошкоджена конфігурація примірника. Примірник може виявитися недоступним внаслідок пошкодження, порушення або видалення конфігураційних файлів DB2. Такими прикладами є файли .rhosts, db2nodes.cfg і глобальні змінні. Ненавмисна модифікація системних змінних також може стати причиною виникнення подібних збоїв.
• Видалення розподіленої файлової системи db2home на вузлах кластера типу data, standby, user або InfoSphere Warehouse. Примірник на тому вузлі, на якому була видалена зазначена директорія, виявиться недоступним.
• Ненавмисне зміна прав доступу до директорії примірника. Примірник DB2 може виявитися недоступним у разі зміни прав доступу до файлу або директорії db2home.

Процедура відновлення екземпляра після збою

У цьому розділі описуються процедури перевірки конфігурації операційної системи, а також видалення та повторного створення екземпляра. Тут будуть використовуватися файли резервних копій, створені за допомогою сценаріїв резервування, представлених в розділі Завантаження . При перевірці конфігурації переконайтеся, що ви порівнюєте значення параметрів того вузла, для якого ви зробили резервну копію. Для зміни файлів і параметрів операційної системи необхідно мати привілеї користувача root. Для виконання завдань, що відносяться до DB2, використовуйте обліковий запис власника примірника DB2.

1. Перевірте конфігурацію операційної системи на несправному вузлі.
   1. Перевірте, що в файлі / etc / passwd присутні обліковий запис користувача примірника і обмежена обліковий запис.
   2. Перевірте, що в файлі / etc / group присутній обліковий запис групи DB2.
   3. Порівняйте файли etc / services та / etc / hosts з відповідними файлами з резервної копії і при необхідності внесіть відповідні поправки.
   4. Перегляньте список пов'язаних з DB2 програмних продуктів, встановлених в системі, і порівняйте його зі списком з резервної копії. У разі виявлення розбіжностей встановіть їх причину.
   5. Перевірте і порівняйте обмеження користувачів (ulimit), точки монтування (/ etc / fstab), рівень операційної системи (oslevel) і записи crontab. У разі виявлення розбіжностей встановіть їх причину.
2. Видаліть пошкоджений екземпляр на несправному вузлі.
   1. За допомогою команди db2ilist визначте, чи присутній екземпляр в списку. Якщо екземпляр не було порушено, перевірте всі точки монтування і мережеві параметри. За допомогою команди db2iupdt виправте проблеми, пов'язані з правами доступу.
   2. Видаліть частково пошкоджений екземпляр за допомогою команди db2idrop <екземпляр>
   3. За допомогою команди db2iset видаліть відповідну інформацію про профілі і параметри конфігурації. Приклад: db2iset -d bcuinst2
3. Створіть і налаштуйте на несправному вузлі новий екземпляр.
   1. Увійдіть в систему на вузлі адміністрування під обліковим записом root і створіть екземпляр за допомогою команди db2icrt. Запустіть цю команду з директорії, в яку було встановлено програмне забезпечення DB2. У нашому прикладі ця директорія називається /opt/IBM/dwe/db2/V9.7/instance, а команда має наступний вигляд:
      db2icrt -u bcufenc2 bcuinst2
      де bcufenc2 і bcuinst2 - ідентифікатори користувача, що є власником примірника.
   2. Порівняйте параметри конфігурації менеджера бази даних з параметрами з резервної копії (файл dbm.cfg.out) і при необхідності відновите їх.
   3. Порівняйте файл $ DB2HOME / sqllib / db2nodes.cfg з файлом з резервної копії і при необхідності відновите його.
   4. Порівняйте значення системних змінних зі значеннями з резервної копії (файл db2set.out) і при необхідності виправте поточні значення. Наприклад, для присвоєння змінної DB2COMM значення tcpip виконайте наступну команду:
      db2set DB2COMM = tcpip
   5. Порівняйте файл DB2HOME / sqllib / userprofile з файлом з резервної копії і при необхідності замініть його.
4. Додайте на несправному вузлі файли ліцензій, каталогізує базу даних і запустіть DB2.
   1. Відновіть файл db2ese.lic з резервної копії і виконайте наступну команду:
      db2licm -a db2ese.lic
      Якщо файл ліцензії не знайдений, команда db2start повертає помилку SQL8000N.
   2. Каталогізує вузли і директорію бази даних відповідно до вмісту файлів db2.list.database.directory і db2.list.node.directory, які ви знайдете в наборі резервних копій. У нашому прикладі це можна зробити за допомогою наступних команд:
      catalog tcpip node beluga-bvn-05 remote beluga-bvn-05 server 50000
      catalog database BCUDB as BCUDB at node beluga-bvn-05
   3. Запустіть DB2. Якщо ви використовуєте функціональність DB2 High Availability (HA), використовуйте для запуску і зупинки DB2 відповідні процедури.

Відновлення після збоїв, причину яких можна встановити

Як вже говорилося, якщо вам відома причина збою в роботі примірника, повне відновлення може не знадобитися. Ви можете усунути проблеми, пов'язані з мережею, точками монтування і правами доступу, за допомогою наступних дій.

• Видалення домашньої директорії власника примірника на вузлі, який не є адміністративним.

  Домашня директорія примірника на вузлах, які не є адміністративними, являє собою змонтовану файлову систему. Для її відновлення спробуйте виконати наступні дії.

  1. Змонтуйте файлову систему на несправному вузлі за допомогою наступної команди:
     mount / db2home
  2. Запустіть менеджер бази даних від імені власника примірника, наприклад, за допомогою наступної команди:
     db2start

     Примітка. У середовищі з високою готовністю може використовуватися інша команда. Зверніться до керівництва користувача.

• Ненавмісне зміна прав доступу до діректорії прімірніка

  Якщо за допомогою команд chmod або cp змінити права доступу до директорії db2home (зокрема, до директорії sqllib), екземпляр може виявитися недоступним внаслідок того, що DB2 не зможе прочитати, записати або запустити потрібний файл. У прикладі, показаному в лістингу 2, на вузлі адміністрування була виконана команда chmod. Це призвело до того, що запуск команди db2start виявився неможливим внаслідок помилки доступу до файлу. Невдалий запуск DB2 показаний в лістингу 2.

  Лістинг 2. Зміна прав доступу може призвести до збою

  bcuinst2 @ beluga-bvn-05: ~> cd ~ / sqllib bcuinst2 @ beluga-bvn-05: ~> chmod -R 444 * bcuinst2 @ beluga-bvn-05: ~> db2start -bash: / db2home / bcuinst2 / sqllib / adm / db2start: Permission denied SQL6031N Error in the db2nodes.cfg file at line number "<line>". Reason code "<reason-code>". Explanation: The statement can not be processed because of a problem with the db2nodes.cfg file, as indicated by the following reason codes: 1 Can not access the sqllib directory of the instance.

  Щоб усунути наслідки цього сценарію, виконайте наступні дії для відновлення прав доступу до файлів і призначення їх власників.

  1. Власниками кожного файлу в директорії ~ / sqllib повинні бути користувач і група примірника DB2. Можна забезпечити виконання цієї умови, запустивши на вузлі адміністрування наступну команду:
     chown db2inst2: db2igrp / db2home / bcuinst2 / sqllib / *
     де bcuinst2 і db2igrp - облікові записи користувача DB2 і групи DB2.
  2. Запустіть команду db2iupt, щоб оновити директорію db2home і замінити загальні файли з використанням параметрів встановленого програмного забезпечення DB2. Для поновлення примірника за допомогою команди db2iupdt необхідно зупинити всі його запущені процеси. Команда db2iupt замінює всі файли в директорії ~ / sqllib. У лістингу 3 показано, як виконати цей крок в нашому тестовому кластері.

     Лістинг 3. Використання команди db2iupdt для поновлення примірника з використанням параметрів встановленого програмного забезпечення DB2

     beluga-bvn-05: /opt/IBM/dwe/db2/V9.7/instance # ./db2iupdt bcuinst2 DBI1070I Program db2iupdt completed successfully. bcuinst2 @ beluga-bvn-05: ~> db2start 08/10/2010 15:09:16 1 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 5 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 2 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 3 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 7 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 6 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:18 4 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:18 8 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:30 0 0 SQL1063N DB2START processing was successful. SQL1063N DB2START processing was successful.

Висновок

Завжди слід мати готові стратегії резервування і відновлення, що дозволяють швидко і ефективно відновити роботу примірника DB2 після збоїв, що приводять до його недоступності. Розробивши ці стратегії, можна уникнути складних процедур із відновлення інсталяції, які довелося б виконувати в разі відсутності плану відновлення. Це може істотно скоротити час простою при виникненні потенційних проблем.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів