Перенос PHP-приложений с MySQL на DB2: Часть 2. Миграция данных

Опыт миграции интранет-приложения IBM

Узнайте, зачем переносить PHP-приложение на DB2®, как спланировать и выполнить миграцию, как поддерживать ее и как справиться с потенциальными рисками, на примере опыта миграции интранет-приложения IBM. В этой серии статей, состоящей из четырех частей, рассматривается уроки успешной миграции с MySQL на DB2 критически важного PHP-приложения, которое используют 4000 пользователей из разных стран мира для управления содержимым сайта ibm.com. Во второй части рассматриваются действия по миграции базы данных.

Дэниел Крук, инженер-программист, IBM

Дэниел Крук (Daniel Krook) – сертифицированный специалист (IBM/Open Group Master Certified IT Specialist), проживающий в Нью-Йорке. Имеет более чем 10-летний опыт разработки Web-приложений, а в настоящее время занимается созданием облачной инфраструктуры для IBM с использованием Java EE, DB2, REST и мобильных технологий. Имеет сертификаты по PHP, Java EE, BlackBerry, DB2 и Solaris. Пишет статьи по PHP для IBM developerWorks и является соавтором документа IBM Redbook "Разработка PHP-приложений для IBM Data Servers".



Янь Ли Му, ИТ-архитектор, IBM

Янь Ли Му (Yan Li Mu) – ИТ-архитектор, работающий в Даляне (КНР). Занимается созданием Web-приложений более 8 лет, уделяя основное внимание технологиям Java EE, PHP и разработке баз данных.



Марк Ньюскейбл, старший ИТ-архитектор, IBM

Марк Ньюскейбл (Mark Nusekabel) – сертифицированный специалист (IBM/Open Group Master Certified IT Architect), проживающий в Тампа-Бэй, Флорида. Занимается информационными технологиями более 20 лет; в настоящее время проектирует инструментальные средства с использованием JavaScript, PHP, Java и DB2. Имеет сертификаты по решениям для электронного бизнеса, а также по Java и XML.



08.06.2012

Введение в серию статей

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

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

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

В этой серии, состоящей из четырех статей, рассматриваются уроки успешной миграции с MySQL на DB2 работающего критически важного PHP-приложения, которое используют 4000 пользователей из разных стран мира для управления содержимым сайта ibm.com.

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

Что вы узнаете

Цель данной серии статей – дать информацию о том, что нужно для переноса PHP-приложения с MySQL на DB2, какие имеются дополнительные ресурсы и как группа разработчиков IBM выполнила эту задачу в начале 2010 года.

Если вы изучали вопрос миграции с MySQL на DB2, вы, вероятно, уже оценили преимущества DB2, принимая во внимание информацию о продукте, тесты производительности, функции, описанные в документации по DB2, и сравнения в документах IBM Redbook®, включая "Руководство по переходу с MySQL на DB2" (см. раздел Ресурсы).

Возможно, вам также известно, что DB2 Express-C является бесплатным, полнофункциональным сервером реляционных баз данных, который можно легко установить или опробовать на платформах IBM Smart Business Development and Test Cloud или Amazon EC2 (ссылки приведены в разделе Ресурсы).

Данная серия статей описывает конкретный пример реальной миграции, успешно выполненной в 2010 году для интенсивно эксплуатируемого PHP-приложения, используемого компанией IBM в повседневной работе по управлению контентом, публикуемым в многочисленных разделах Web-сайта ibm.com.

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

Что здесь не рассматривается

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

Чтобы определить соответствующий вашим требованиям подход, обратитесь к "Руководству по переходу с MySQL на DB2" или обратитесь в отдел Software Migration Project Office (SMPO) за бесплатной оценкой миграции. Ссылки приведены в разделе Ресурсы.


Введение в миграцию базы данных

В данной статье рассматриваются четыре основных этапа миграции базы данных с MySQL на DB2. Место этих этапов в общем плане процесса миграции рассматривалось в первой части данной серии статей .

Этап 1. Преобразование структуры базы данных MySQL в формат DB2
  • Создание новой базы данных в DB2.
  • Извлечение структуры исходной базы данных MySQL.
  • Инженерный анализ базы данных с целью получения диаграммы объекты-отношения.
  • Уточнение и изменение структуры модели данных.
  • Преобразование других объектов базы данных.
Этап 2. Перенос MySQL-данных в базу данных DB2
  • Удаление ненужных таблиц и данных.
  • Преобразование всех данных исходной базы данных, которые не отображаются напрямую в тип данных целевой базы данных DB2.
  • Извлечение данных из MySQL.
  • Загрузка данных в DB2.
  • Сброс сгенерированных инкрементов столбцов идентификаторов.
Этап 3. Воссоздание пользовательских полномочий и конфигурации администрирования базы данных
  • Настройка необходимых пользовательских учетных записей и назначение им соответствующих полномочий.
  • Реализация плана резервного копирования и восстановления базы данных.
  • Настройка репликации для создания зеркальной системы, которую может использовать механизм создания отчетов Cognos.
Этап 4. Оценка итогов миграции базы данных
  • Проверка завершения миграции базы данных. Если она не закончена, необходимо повторить шаги 1-3, как показано на рисунке 1 в первой части данной серии статей.
  • Резервное копирование системы.
  • Подготовка к преобразованию приложения.

Учебный пример миграции существующей базы данных MySQL PTT

Напоминание

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

  • Главы 6, 7 и 9 бесплатного документа IBM Redbook® "Руководство по переходу с MySQL на DB2" (EN).
  • Статья developerWorks "Список рекомендованной литературы: администрирование баз данных с использованием DB2 для Linux, UNIX и Windows" (EN).
  • Статья developerWorks "Использование опыта работы с MySQL при изучении DB2 Express" (EN).

Конечно же, важным источником информации являются документы по инструментам для миграции баз данных, таким как IBM Data Movement Tool и Rational Software Architect.

Другим вариантом осуществления миграции является использование облака. Можно использовать виртуальные образы Amazon EC2 Linux и DB2 AMI или сервис IBM Development and Test на платформе IBM Cloud (см. раздел Ресурсы).

Исходная база данных MySQL для программы Project Tracking Tool (PTT), используемая в данной статье в качестве примера, содержит 150 таблиц (в среднем по 6 столбцов каждая) с общим объемом текстовых данных около 10 ГБ. PTT первоначально создавалась для работы с версией MySQL 3.23 и через семь лет была переведена на MySQL версии 5.0. Все таблицы используют механизм хранения MyISAM.

База данных PTT используется при обработке информации, публикуемой на сайте ibm.com. Приложение обрабатывает двоичные файлы (например, изображения продуктов и документы), но сами файлы хранятся в файловой системе, а не в базе данных; а в столбце базы данных указывается логическая ссылка на их местоположение.

Более 4000 пользователей со всего мира обращаются к этой базе и изменяют ее посредством Web-интерфейса, реализованного на PHP. В каждый момент времени с системой одновременно работает несколько сотен пользователей.

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

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


Установка ПО миграции

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

MySQL-копия исходной базы данных
Миграция базы данных – это итеративный процесс, поэтому для облегчения доступа к исходной базе установите ее MySQL-копию на рабочую станцию. Это позволит повысить производительность миграции по сравнению с установкой базы на удаленной системе и обеспечит возможность свободно изменять исходную базу данных по мере необходимости.
Версия DB2
Для создания целевой базы данных установите DB2 на рабочей станции. Вообще говоря, она не обязательно должна быть той же версии, которая будет использоваться в дальнейшем, но это желательно для обеспечения полной функциональной совместимости. Для работы с примером данной статьи установите DB2 Enterprise Server Edition Version 9.7.2.
Программа IBM Data Movement Tool
Загрузите и разархивируйте последнюю версию программы IBM Data Movement Tool (см. раздел Ресурсы), которую можно использовать для извлечения базы данных из MySQL и импорта ее в DB2.
Основанная на Eclipse интегрированная среда разработки (IDE) от IBM с перспективой data (необязательно).
Можно использовать существующий дистрибутив Rational® Software Architect, представляющий собой полнофункциональный инструмент для визуализации и редактирования моделей баз данных. Ссылки на Rational Software Architect и аналогичные инструментальные средства, такие как InfoSphere™ Data Architect и Optim™ Development Studio, размещены в разделе Ресурсы.

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

Чтобы сохранить образ конфигурации физической машины, воспользуйтесь бесплатной программой VMware vCenter Converter. В качестве альтернативы можно использовать облако, например, Amazon EC2 DB2 AMI или IBM Development and Test на платформе IBM Cloud. Используя виртуальные компьютеры, вы сможете избежать первоначальных затрат на приобретение серверного аппаратного обеспечения и установку операционной системы и DB2, что сэкономит время, ускорит процесс миграции и придаст больше уверенности при проведении экспериментов с конфигурациями, соответствующими вашим требованиям. Ссылки на все эти продукты приведены в разделе Ресурсы.


Этап 1. Преобразование структуры базы данных MySQL в формат DB2

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

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

Приложение PTT обеспечивает работу пользователей из разных стран, поэтому важно с самого начала позаботиться о том, чтобы новая база данных DB2 поддерживала различные языки и кодовые таблицы. Для выполнения этого требования создайте базу данных с кодовой таблицей UTF-8.

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

Чтобы воспроизвести поведение MySQL-системы в плане обработки данных (нечувствительность к регистру), выберите алгоритм UCA500R1_S1 (Unicode Collation Algorithm), который обрабатывает регистр и сортировку символов аналогичным образом. При такой конфигурации строки role, Role и rôle при сортировке и сравнении рассматриваются как одинаковые.

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

Листинг 1. Команда, используемая для создания новой базы данных DB2
CREATE DATABASE PTT 
USING CODESET UTF-8
TERRITORY US 
COLLATE USING UCA500R1_S1
PAGESIZE 4096;

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

Существует множество других параметров, которые можно указать при создании базы данных. Имеет смысл изучить эти параметры, поскольку желательно правильно настроить базу данных с самого начала, а не менять настройки впоследствии. В разделе 6.2.1 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы) подробно описываются многие из этих параметров.

Извлечение структуры исходной базы данных MySQL

Следующая задача – извлечь структуру базы данных из MySQL и загрузить ее в DB2. Если база данных невелика, можно с помощью mysqldump извлечь из MySQL DDL-выражение, а затем вручную изменить его в соответствии с синтаксисом DB2. В разделе 6.1 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы) описываются все типы данных и приводится таблица их отображения.

Для больших баз данных, как в примере данной статьи, содержащем 150 таблиц, используйте средства автоматического извлечения структуры базы данных, такие как IBM Data Movement Tool. Программа IBM Data Movement Tool предоставляет простой пользовательский интерфейс, настроенный на подключение к локальной базе данных MySQL и к новой базе данных DB2. Ссылки на подробное описание использования IBM Data Movement Tool для извлечения структуры базы данных приведены в разделе Ресурсы.

Например, отметьте только флажок Data и нажмите кнопку Extract DDL/Data, как показано на рисунке 1.

Рисунок 1. Извлечение DDL
Извлечение DDL

После извлечения программой IBM Data Movement Tool структуры базы данных в каталоге migr появится список DDL-файлов. Некоторые из этих файлов могут быть пустыми. Например, файл db2udf.sql не имеет содержимого, поскольку в исходной базе данных MySQL примера нет определяемых пользователем функций.

Загрузите DDL-выражения в локальную базу данных DB2, выполнив пакетное задание db2ddl.cmd, расположенное в том же каталоге, что и DDL-файлы.

Инженерный анализ базы данных с целью получения диаграммы объекты-отношения

После загрузки DDL-выражений в DB2 используйте RSA для анализа структуры базы данных в DB2. Подключитесь к созданной базе данных DB2 и извлеките ее визуальную модель, используя Rational Software Architect. Этот процесс, называемый инженерным анализом (reverse engineering), преобразовывает базу данных в диаграмму объекты-отношения (entity-relationship – ER), отображающую таблицы, столбцы и взаимосвязи между ними.

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

Опять-таки можно вручную изменить модель данных, редактируя DDL в соответствии с синтаксисом DB2, но визуальная модель в виде ER-диаграммы удобнее для просмотра, документирования и обслуживания структуры данных. ER-диаграмма может служить документом для технической службы и бизнес-партнеров.

Построение диаграммы и выполнение соответствующих действий дает ряд преимуществ::

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

Более подробная информация об инженерном анализе существующей базы данных в модель данных приведена в InfoSphere Data Architect (см. раздел Ресурсы). Эти же инструкции применимы для любой основанной на платформе Eclipse Data Tools Platform среды разработки от IBM. В отличие от руководства, где в качестве примера используется база данных Apache Derby, мы будем подключаться к базе данных DB2.

Уточнение и изменение структуры модели данных

Независимо от того, сгенерировали вы ER-диаграмму или нет, на этом этапе можно приступать к улучшению структуры данных. Рассмотрим изменения структуры, используемой в нашем примере.

Убедитесь, что типы данных первичных и соответствующих им внешних ключей согласованы
Например, в таблице USER первичный ключ имеет тип SMALLINT, но внешний ключ USER_ID, логически связанный с этим первичным ключом в другой таблице, имеет числовой тип INTEGER большего диапазона. Такое часто наблюдается в структурах баз данных MySQL, которые были созданы в версии, не поддерживающей требования согласованности типов данных ключей.
Увеличьте при необходимости максимальный размер столбцов идентификаторов
Если ваше приложение работает достаточно долго, значения столбцов идентификаторов могут начать приближаться к установленному для них пределу. Миграция предоставляет хорошую возможность решить эту потенциальную проблему. Например, если данные столбца ID таблицы USER имеют тип SMALLINT, а число пользователей может в будущем превысить 32767, следует увеличить ID и установить тип INTEGER, поддерживающий до 2 миллиардов пользователей.
Измените там, где это возможно, MySQL-поля TEXT с текстовых типов DB2-объектов CLOB на символьные типы VARCHAR
В DB2 есть определенные ограничения для типов CLOB. Данные типа CLOB нельзя использовать для поиска DISTINCT-значений и загружать в буферные пулы. Поэтому данные типа CLOB снижают производительность, т.к. нельзя воспользоваться преимуществами страничного кэширования. По возможности следует изменить тип полей с TEXT на VARCHAR. Максимальный размер столбца VARCHAR определяется размером табличной области, поэтому в них можно сохранять текст размером до 32 КБ.
Удалите устаревшие или неиспользуемые столбцы
Некоторые приложения, например, используют разный подход к хранению отчетов, поэтому есть вероятность существования нескольких устаревших таблиц, содержащих большой объем данных, потерявших свою ценность и часто сбивающих с толку новых разработчиков. Заархивируйте эти данные и удалите их из активной базы данных.
При необходимости добавьте первичные ключи или ограничения уникальности
Помимо обеспечения целостности данных, ограничения ключей играют важную роль в репликации DB2. Для каждой таблицы нужны первичный или уникальный ключи, чтобы можно было перенести уникальные значения в резервную копию базы данных.
Определите и активируйте новые внешние ключи
В рассматриваемом примере базы данных MySQL внешние ключи отсутствуют, поскольку приложение изначально создавалось для работы с механизмом хранения MyISAM по умолчанию, который их не поддерживает. На этапе преобразования данных добавьте необходимые внешние ключи для улучшения целостности данных, например, свяжите таблицу USER с таблицей TASK_HISTORY, что гарантирует ненарушение связей регистрационных записей с пользователями.
Преобразуйте или добавьте другие объекты, такие как индексы, представления, хранимые процедуры и функции
Визуализация структуры данных может быть полезна для понимания взаимосвязей между таблицами, их относительной важности и частоты обращений к ним, влияющих на производительность. Такая визуализация поможет лучше понять, где нужно применить ограничения и сгруппировать связанные действия для улучшения качества данных и скорости чтения.

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

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

В разделе Ресурсы (как и для рассмотренной ранее задачи инженерного анализа) приведены ссылки на информацию о модификации и экспорте модели данных при помощи основанных на Eclipse инструментальных средств от IBM, в частности, на содержащееся в документации по InfoSphere учебное руководство по преобразованию физической модели данных в DDL.

Преобразование других объектов базы данных

Инструмент IBM Data Movement Tool может автоматически преобразовывать большинство объектов баз данных, таких как таблицы, ключи, индексы и табличные области, но существуют и другие объекты, которые необходимо преобразовать вручную, если они присутствуют в исходной базе данных MySQL. К таким объектам относятся представления, хранимые процедуры, определяемые пользователем функции и триггеры.

Эти объекты несложно преобразовать вручную, потому что MySQL и DB2 совместимы с синтаксисом хранимых процедур SQL:2003. А поскольку триггеры DB2 по функциональности являются надмножеством возможностей MySQL, их можно легко воссоздать. В главе 6 документа IBM Redbook "Разработка PHP-приложений для серверов данных IBM" приведена подробная информация об отличиях, о которых следует знать.

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


Этап 2. Перенос MySQL-данных в базу данных DB2

На этом этапе мы извлечем данные из базы данных MySQL и загрузим их в DB2. Этот процесс также предоставляет возможность улучшить качество данных. Выполняются следующие действия:

Удаление ненужных таблиц и данных

Инструмент IBM Data Movement Tool формирует файл имя_таблицы.tables, содержащий информацию о том, какие данные извлекать из исходной базы данных, в виде запроса SELECT для каждой таблицы. Например, можно включать только те данные, которые накопились за последние четыре года. Некоторые строки необходимо удалить, а к некоторым добавить оператор WHERE для фильтрации перемещаемых данных.

Если переносить таблицу из MySQL в DB2 не нужно, следует полностью удалить ее из этого файла. Если нужно перенести подмножество данных, следует соответствующим образом изменить выражение SELECT. Если, например, таблицу WORK_TMP не нужно переносить в DB2, удалите строку, приведенную в листинге 2.

Листинг 2. Строка, которая была удалена из файла timetrac.tables
"timetrac"."work_tmp":SELECT * FROM "timetrac"."work_tmp"

Возможно, вы захотите оставить в таблице WORK только те данные, которые были созданы после 2008 года. Для этого добавьте оператор WHERE, как показано в листинге 3.

Листинг 3. Строка, измененная для фильтрации данных по дате
"timetrac"."work":SELECT * FROM "timetrac"."work" WHERE ts >= '2008-01-01'

Преобразование MySQL-данных, несовместимых с DB2

Еще одной важной задачей является определение совместимости типов данных исходной и новой базы данных. Поскольку вы уже изменили базу данных DB2 на этапе реорганизации модели данных (этап 1), убедитесь, что типы данных, импортируемых из MySQL, совместимы с типами данных, определенными в DB2.

Например, тип данных TIME существует в обеих базах данных, но допустимые диапазоны значений различны. В MySQL тип TIME представляет значение времени в интервале от -838:59:59 до 838:59:59, а в DB2 тип TIME представляет время в 24-часовом формате в интервале значений от 00:00:00 до 24:00:00. Если имеются данные типа TIME не в 24-часовом формате, преобразуйте их в MySQL в совместимый с DB2 формат до выполнения миграции. В листинге 4 приведено SQL-выражение, выполняющее такое преобразование.

Листинг 4. Преобразование в MySQL данных типа TIME в формат DB2
mysql> UPDATE WORK W SET W.HOUR = SUBTIME(W.HOUR, '24:00:00') WHERE W.HOUR >= '24:00:00';

Могут существовать и другие типы данных, требующие изменения в исходной базе данных до их переноса. В разделе 6.1 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы) дается описание всех типов данных и приведена таблица совместимости.

Извлечение данных из MySQL

После подготовки к миграции данных в MySQL снова откройте IBM Data Movement Tool, отметьте флажок Data и нажмите Extract DDL/Data, как показано на рисунке 2.

Рисунок 2. Генерирование сценариев извлечения
Генерирование сценариев извлечения

По завершении этого действия в папке migr появятся четыре файла: geninput, rowcount, timetrac.tables (где timetrac – это название базы данных) и unload.

Замените файл timetrac.tables тем, который вы редактировали после этапа извлечения базы данных, чтобы ограничить выбираемые данные. Выполните команду unload для извлечения данных из MySQL. После завершения извлечения проверьте отсутствие сообщений об ошибках в файле IBMDataMovementTool.log. В результате успешной выгрузки сгенерируется большое количество файлов, включая файл db2load.cmd и папку data.

Загрузка данных в DB2

Перейдите в каталог migr и выполните пакетное задание db2load.cmd для фактического переноса данных в DB2.

Проверьте файл db2load.log и убедитесь, что все данные успешно загружены в DB2. IBM Data Movement Tool предоставляет сценарий проверки равенства номеров строк исходной базы данных MySQL номерам строк в таблицах DB2. Для проверки соответствия номеров можно выполнить команду rowcount.

Помимо этого вы, возможно, захотите более тщательно проверить данные в DB2, используя другие методы, такие как сравнение результатов выполнения важных запросов. В разделе 7.2.7 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы) описывается несколько стратегий проверки перенесенных данных.

Сброс сгенерированных инкрементов столбцов идентификаторов

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

Листинг 5. Команда для сброса инкрементов столбцов идентификаторов
ALTER TABLE WORK ALTER COLUMN ID RESTART WITH 5000;

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

После импорта структуры базы данных и данных в DB2 следует третий важный этап - проверка корректности доступа к этим данным и управления ими. Нужно настроить необходимые учетные записи и назначить им соответствующие полномочия. Затем нужно настроить резервное копирование и аварийное восстановление на основе существующей системы, определенной в результате исследования и консультации эксперта по DB2. Наконец, нужно настроить репликацию для создания зеркальной системы, которая будет использоваться системой бизнес-аналитики Cognos® для создания отчетов.

На данном этапе выполняются следующие действия:

Преобразование модели полномочий

При установке DB2 по умолчанию создается пользовательский ID владельца экземпляра db2inst1. В базе данных MySQL имеется аналогичный пользователь-администратор root. Понятно, что при выполнении функций, которые обычно выполняет root, вместо него используется db2inst1.

Кроме того, необходимо создать еще две учетные записи. Пользователь pttuser выполняет операции чтения и записи, необходимые приложению. Пользователь read необходим как для рабочей базы данных, так и для реплики базы данных. Эта учетная запись используется для выполнения запросов к рабочей базе данных только по чтению. Механизм создания отчетов Cognos по данным реплики базы данных также использует учетную запись read. Эти учетные записи приведены в таблице 1.

Таблица 1. Список пользователей
Пользователь ОписаниеБаза данных
Администрирование (db2inst1)Пользовательская учетная запись с привилегиями SYSADMПроизводство и отчетность
Приложение (pttuser)Пользователь с доступом по чтению и записи к рабочей базе данныхПроизводство
Отчетность (read)Пользователь с доступом только почтению к рабочей базе данных и к копии базы данныхПроизводство и отчетность

Эти пользовательские учетные записи создаются в ОС Linux, а соответствующие привилегии присваиваются им при помощи выражения GRANT. Обычно это отдельная операция, выполняемая после создания базы данных DB2 и переноса в нее данных из MySQL. Однако при развертывании в производство выражения GRANT будут включаться в тот же DDL, который использовался для создания структуры базы данных.

В MySQL доступ часто предоставляется с низкой степенью детализации, поскольку пользователю (ограниченному именем хоста, с которого выполняется подключение) можно назначить полномочия для операций чтения, записи или управления лишь для базы данных в целом. В нашем примере пользователю pttuser разрешен доступ к базе данных по чтению и записи (только при соответствующем имени хоста Web-сервера), поэтому он может обращаться к любой таблице и изменять ее.

В DB2 доступ предоставляется для пользователя, но не указывается имя хоста, с которого он подключается. В DB2, как и в MySQL, можно указать права на операции запроса, добавления или обновления данных. Однако при этом нужно предоставить пользователю доступ к каждой таблице базы данных, поскольку команда предоставления доступа ко всей базе данных отсутствует (если только вы не создали базу данных и таблицы от имени этого пользователя, что не рекомендуется). Поэтому после создания таких объектов, как таблицы, в DDL часто включаются команды GRANT.

В листинге 6 приведен пример предоставления доступа к таблице WORK. Пользователь application получает полный доступ по чтению и записи, а пользователь reporting может только читать данные.

Листинг 6. Пример GRANT-выражений
-- GRANT-выражения для предоставления доступа по чтению/записи учетной записи application
GRANT DELETE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT INSERT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER";  
GRANT UPDATE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 

-- GRANT-выражения для предоставления доступа только по чтению учетной записи
-- reporting/ad hoc
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "READ";

В разделе 7.1.3 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы) приведена подробная информация об отличиях в управлении пользовательскими учетными записями и о параметрах детализированной настройки доступа, предлагаемых DB2.

Преобразование процедуры резервного копирования и восстановления

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

В MySQL для создания копии данных используется команда mysqldump, а для восстановления данных – команда SQL. Например, можно каждую ночь выполнять резервное копирование при помощи mysqldump и поддерживать синхронизированную реплику базы данных только для чтения с целью создания отчетов, одновременно служащую резервной базой данных для обеспечения отказоустойчивости.

Для новой базы данных запланируйте выполнение команд backup и restore, используя средства, предоставляемые DB2. Есть несколько вариантов таких команд, позволяющих выполнять полное или инкрементное резервное копирование в автономном (offline) или оперативном (online) режимах. Например, можно выполнять инкрементное резервное копирование в оперативном режиме один раз в день и полное резервное копирование в автономном режиме один раз в неделю во время проведения работ по обслуживанию. В таблице 2 приведен пример плана и политики резервного копирования и восстановления.

Таблица 2. План резервного копирования и восстановления после сбоев
ЗадачаОписание
Оперативное резервное копирование каждую ночьОперативное резервное копирование базы данных DB2 каждую ночь и сохранение ее на том же сервере DB2. Это обеспечивает простое и быстрое восстановление в случае возникновения несложных проблем с базой данных. При этом не требуется останавливать приложение. Однако в данном случае не обеспечивается восстановление с повтором всех завершенных транзакций с использованием log-файлов; это означает, что могут быть потеряны все данные, созданные за промежуток времени между резервным копированием и сбоем в работе базы данных.
Еженедельное автономное резервное копированиеАвтономное резервное копирование базы данных DB2 каждые выходные и сохранение ее на другом сервере (желательно, чтобы он находился в другом месте). Это обеспечит более надежное восстановление после серьезных проблем с сервером. Такое копирование требует останова приложения. Однако в данном случае имеется возможность восстановления с повтором всех завершенных транзакций с использованием log-файлов; это означает, что данные можно полностью восстановить, используя резервную копию и операции, записанные в log-файлы после резервного копирования.

Информация, необходимая для определения и реализации нового процесса резервного копирования и восстановления, приводится в главе 9 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы). В ней приводятся примеры команд резервного копирования и описывается планирование резервного копирования при помощи DB2 Control Center или Optim™ Development Studio.

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

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

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

MySQL и DB2 реализуют репликацию по-разному. В MySQL можно изменить несколько конфигурационных параметров и выполнить репликацию всей базы данных с одного сервера на другой в режиме реального времени. Можно также сделать резервную копию, а затем асинхронно восстановить ее в другую базу данных.

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

Кроме того, перед настройкой репликации в DB2 желательно проверить каждую таблицу базы данных на наличие первичного ключа или уникального индекса. Хотя их наличие рекомендуется, в некоторых базах данных они могут отсутствовать. Вспомните, что MySQL-таблицы нашего примера не имели этих значений, поскольку создавались для механизма хранения MyISAM. Репликация в MySQL может работать без ключа или индекса. Однако для репликации в DB2 требуется уникальная идентификация строк таблицы по ключу или индексу. Если таблица не имеет первичного ключа или уникального индекса, обновляемые в рабочей базе данных записи могут рассматриваться как вновь созданные, а не как существующие, поскольку отсутствует ключ для поиска обновляемой записи.

Глава 9 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы) должна стать для вас главным источником информации при выработке стратегии настройки репликации. Для управления параметрами репликации можно использовать предоставляемые DB2 инструментальные средства или реализовать специализированное решение, основанное на переносе log-файлов.


Этап 4. Оценка итогов миграции базы данных

На этом этапе, выполнив этапы 1-3, которые сами могут потребовать нескольких итераций, мы имеем работающую базу данных на рабочей станции Windows и записи об изменениях и возникших проблемах.

Если вы использовали виртуальные машины, у вас имеется образ системы Windows как для архивирования текущего рабочего состояния, так и для использования в качестве основы для сравнения последующих изменений производительности. Другим вариантом, естественно, является использование виртуального образа в облаке IBM или Amazon Cloud и работа с ним аналогичным способом.

Можно поэкспериментировать с разными процессами миграции для определения наиболее подходящего для вашей среды. После проверки соответствия используемой на этапах 1-3 рабочей станции Windows всем требованиям можно перенести базу данных на выделенный сервер, на котором мы будем тестировать обновления PHP-приложения в третьей части данной серии статей.


Заключение

Эта серия статей подробно рассказывает о том, что обычно требуется для переноса PHP-приложения с MySQL на DB2 и какие имеются вспомогательные ресурсы. Также рассмотрен пример успешной миграции.

Во второй части данной серии статей вы:

  • познакомились с исходной базой данных MySQL;
  • узнали, как преобразовать структуру этой базы данных в DB2;
  • узнали, как перенести данные в DB2;
  • узнали, как настроить функции администрирования.

В следующей части серии вы узнаете, как преобразовать PHP-код.

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

Авторы благодарят Леонса Петразикиса (Leons Petrazickis) и Эмбриша Бхаргава (Ambrish Bhargava) за комментарии к статье.

Ресурсы

Научиться

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

  • Получите IBM DB2 e-kit for Database Professionals для изучения возможностей DB2, использования вашего опыта разработки приложений и администрирования баз данных, подключения к сообществу DB2 и подготовки к экзаменам по сертификации.
  • Свяжитесь с группой Software Migration Project Office DB2, чтобы получить бесплатную оценку возможности миграции.
  • Создавайте и проверяйте ваши PHP/DB2-приложения в IBM Cloud при помощи сервиса IBM Smart Business Development and Test on the IBM Cloud.
  • Попробуйте поработать с DB2 на Amazon EC2.
  • Zend Server – сервер Web-приложений корпоративного уровня для выполнения и поддержки PHP-приложений, предъявляющих высокие требования к надежности, производительности и безопасности, на Linux, Windows или IBM i.
  • Zend Server включает в себя драйверы для DB2, но для собственных конфигураций PHP можно использовать исходный код расширения драйвера в виде PECL или бинарных файлов для Windows на сайте SourceForge.
  • Дополнительная информация по обучению и сертификации по DB2. Пройдите учебный курс по управлению информационными ресурсами.
  • Загрузите и установите бесплатный сервер данных DB2 Express-C.
  • Используйте Rational Software Architect или InfoSphere Data Architect для выполнения логического и физического моделирования данных.
  • Используйте Optim Development Studio для разработки и оптимизации приложений, работающих с DB2.
  • Используйте бесплатную программу VMware vCenter Converter для преобразования физических машин в виртуальные образы.

Обсудить

Комментарии

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, Open source
ArticleID=820397
ArticleTitle=Перенос PHP-приложений с MySQL на DB2: Часть 2. Миграция данных
publish-date=06082012