Переход с bugzilla 2.20 на bugzilla 3.4.2

Целью данной статьи является помощь тем, кто решил перейти со старой версии багзиллы 2.20 на более новую 3.4.2. В данной статье рассматривается переход с bugzilla 2.20 с кодировкой latin1, которая была на сервере mysql ver 4.0.21, на новый сервер Linux redhat с bugzilla 3.4.2 с кодировкой utf8 и сервером баз данных mysql ver 5.0.45.

Главное, что нужно знать, в какой кодировке находятся данные в вашей базе. Это можно узнать следующим образом.
Получаем в какой кодировке хранится база (появился функционал с версии mysql 4.1):

mysql>show create database bugs;

В какой кодировке на самом деле таблицы (сами данные), например таблица profiles:

mysql>show create table profiles;

ОБЯЗАТЕЛЬНО храните полную копию своих данных чтобы всегда можно было восстановиться. Если будите делать все на одном и том же сервере, сделайте вторую папку создайте virtual host и тестируйте в нем, но ни в коем случае не затирайте стаую базу пока не будите уверены, что новая вас полностью устраивает и она полностью работоспособна.
Итак приступим.

1. Подготавливаем базу для перекодировки.

1.1 Делаем проверку утилитой SanityCheck. Для этого в версии 2.20 вызываем утилиту SanityCheck(Проверка системы) под администратором:

http://localhost/bugs/sanitycheck.cgi

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

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

1.2 Включаем в настройках Required Settings параметр utf8 в on.

1.3 Затем делаем дамп базы:

C:\Documents and Settings\sokunova>mysqldump -uroot -proot bugs > C:\dump1.sql

Если Вы добавляли свои таблицы в базу bugzilla, то вам нужны 2 дампа своей базы. В первом все стандартные таблицы bugzilla. Во втором добавленные таблицы.

2. Подготовка dump-а для перекодировки.

Все поля varchar() в dump-e необходимо увеличить в 2 раза. К примеру, если в таблице attachments поле filename было 100, то его надо сделать 200, так как после перекодировки utf8 строка займет больше места об этом не нужно забывать. Аналогично и для всех остальных полей, во всех остальных таблицах. Если этого не сделать , то часть полей, к Вашему сожалению обрежется.
Это надо сделать со всеми полями кроме ключевых key полей. Т.е. для полей groups.name и profiles.login_name значение в 255 увеличивать НЕ надо. Для ключевых полей оно не должно превысить 255. В bugzilla 3.4.2 используется InnoDB в ней на ключевые поля по умолчанию выделяется 765 бит и рассчитывается по следующей формуле:

uft8 = 3 byte = 1 character

3. Готовим сервер, где будем разворачивать новую систему.

3.1 На сервере Redhat распаковываем архив bugzilla 3.4.2:

# tar -xvf bugzilla-3.4.2.tar.gz

Переименовываем папку как нужно плюс делаем корректного владельца всем файлам, папкам и подпапкам:

# mv bugzilla-3.4.2 bugzilla
# chown apache:apache bugzilla
# chown -R apache:apache ./bugzilla

После этого не забываем прописать в httpd.conf для сервера apache созданную папку багзилы (либо в httpd-vhosts.conf).

3.2 Проверяем каких модулей не хватает для bugzilla 3.4.2:

# ./checksetup.pl --check-modules

Устанавливаем те, которые REQUIRED обязательно и OPTIONAL - по желанию.
Обязательно пользуемся типом установки предложенным багзилой, а именно:

# /usr/bin/perl install-module.pl CGI

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

3.3 Первая часть установки bugzilla 3.4.2

# ./checksetup.pl

3.4 После этого создается файл localconfig. В файле localconfig необходимо ввести параметры для базы данных ошибок, а именно: db_name, db_user, db_pass и т.д.

# vi localconfig
$db_driver = 'mysql';
$db_host = 'localhost';
$db_name = 'bugs';
$db_user = 'bugs_user';
$db_pass = 'bugs_pass';

3.5 Теперь делаем соответствующие права пользователю bugs_user на базу bugs на сервере:

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES, CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.* TO bugs_user@localhost IDENTIFIED BY 'bugs_pass'; Query OK, 0 rows affected (0.01 sec)

3.6 Второй раз вызываем скрипт установки:

# ./checksetup.pl

Во время создания базы Вас спросят ввести e-mail администратора багзилы, его имя и пароль

Enter the e-mail address of the administrator: halyava_84@mail.ru
Enter the real name of the administrator: Mariya Sokunova
Enter a password for the administrator account:***

3.7 После инсталляции проверьте свой сервер на наличие ошибок, может все таки каких то еще модулей не хватает:

# ./testserver.pl

3.8 Так как размер перекодируемых данных большой (скорей всего у Вас будет не меньше) нужно позаботиться о настройках mysql сервера, так как он будет хранить все данные в своем буфере. Я использую основные две следующие переменные:

max_allowed_packet=512M
innodb_buffer_pool_size=512M

Эти настройки задаются в файле /etc/my.cnf (для Linux). Мой файл настроек: my.cnf.
Перезапукаем сервер с новыми настройками:

# service mysqld restart
Останавливается MySQL:                                     [  OK  ]
Запускается MySQL:                                         [  OK  ]

Теперь наш сервер готов к перекодировке.Если Вы не добавляли никаких таблиц ранее в багзилу 2.20 (как уже спрашивалось в п.2 ), то описание в пункте 3.9 можете пропустить и смело переходить к пункту 4.

3.9 Настройка Schema.pm для тех, кто добавлял в bugzilla 2.20 свои таблицы. Если все-таки по каким-то причинам Вы добавляли новые таблицы, т.е.исправляли структуру bugzilla 2.20, то перед п.4 Вам нужно поправить файл Schema.pm в версии bugzilla 3.4.2 он находится по пути (текущий каталог с установленной багзилой):

./Bugzilla/DB/Schema.pm

Примерное описание от самой багзилы, как с файлом Schema.pm работать, можно найти здесь.
Если Вы не поправите этот файл Schema.pm, то при перекодировке на этих таблицах bugzilla остановится и дальше перекодировка не пойдет и в самой базе будет каша.
Пример, как описывать новую таблицу в Schema.pm приведен ниже. Можно найти соответствие в описании dump-a (или description таблицы из mysql) и Schema.pm и сделать тоже самое для своих таблиц соответственно.
Если в дампе таблицы создаются так:

CREATE TABLE fixes_bugs (
  bug_id mediumint(9) NOT NULL default '0',
  target_milestone varchar(40) NOT NULL default '---',
  req_id mediumint(9) NOT NULL default '0',
  sendto_id mediumint(9) NOT NULL default '0',
  answ_id mediumint(9) NOT NULL default '0',
  decision smallint(1) NOT NULL default '0',
  PRIMARY KEY  (bug_id)
) TYPE=MyISAM;

CREATE TABLE my_stat_param (
  `id` int(5) NOT NULL default '0',
  `name` varchar(20) NOT NULL default '',
  `eqdate` datetime NOT NULL default '0000-00-00 00:00:00',
  `eqproc` smallint(3) NOT NULL default '0',
  `from` datetime NOT NULL default '0000-00-00 00:00:00',
  `to` datetime NOT NULL default '0000-00-00 00:00:00',
  `dt` int(5) NOT NULL default '0',
  PRIMARY KEY  (`id`)
) TYPE=MyISAM;

То в Schema.pm я их описала следующим образом:

fixes_bugs => {
        FIELDS => [
            bug_id             => {TYPE => 'INT3', NOTNULL => 1,
                                   PRIMARYKEY => 1},
            target_milestone   => {TYPE => 'varchar(20)', NOTNULL => 1},
            req_id             => {TYPE => 'INT3', NOTNULL => 1},
            sendto_id          => {TYPE => 'INT3', NOTNULL => 1},
            answ_id            => {TYPE => 'INT3', NOTNULL => 1},
            decision           => {TYPE => 'INT1', NOTNULL => 1},
        ],
    },

 my_stat_param => {
        FIELDS => [
            "`id`"     => {TYPE => 'INT3', NOTNULL => 1,
                       PRIMARYKEY => 1},
            "`name`"   => {TYPE => 'varchar(10)', NOTNULL => 1},
            "`eqdate`" => {TYPE => 'DATETIME', NOTNULL => 1},
            "`eqproc`" => {TYPE => 'INT2', NOTNULL => 1},
            "`from`"   => {TYPE => 'DATETIME', NOTNULL => 1},
            "`to`"     => {TYPE => 'DATETIME', NOTNULL => 1},
            "`dt`"     => {TYPE => 'INT3', NOTNULL => 1},
        ],
    },

4. Непосредственно перекодировка базы.

4.1 Сносим базу utf8:

mysql> drop database bugs;

4.2 Создаем пустую базу latin1:

mysql> create database bugs character set=latin1;
Query OK, 1 row affected (0.01 sec)

4.3 Заливаем dump (в случае двух дампов это дамп номер 1) в эту базу :

mysql>use bugs;
mysql> source /home/dump1.sql;

4.4 Вызываем checksetup.pl для преобразования базы и получения всех необходимых индексов, столбцов и т.д.:

# ./checksetup.pl

Когда все преобразования пройдут Вы увидите сообщение:

WARNING: We are about to convert your table storage format to UTF8. ....
.....
         Press Enter to continue or Ctrl-C to exit...

После этого необходимо будет нажать Ctrl+C.
Если у вас не было дополнительных таблиц в базе (только основные багзиловские стандартные), то переходите сразу к п. 4.5

4.4.(2) Если У Вас два дампа базы, Вы делали изменения в Shema.pm и вместе со смой мучаетесь и ждете когда же перекодируется эта база с измененной структурой, то Вам нужно пройти и этот пункт тоже.
В п. 4.4 Вы видели, что при выполнении скрипта checksetup.pl обновилась таблица bz_schema и добавились автоматически в базу bugs пустые таблицы, с именами и структурой соответствующими Вашим лежащим во втором дампе.
Вам необходимо на сервере удалить эти пустые таблицы и залить второй дамп из своих таблиц (дамп номер 2):

mysql>use bugs;
mysql>source dump2.sql;

И еще раз вызвать checksetup.pl, чтобы эти таблицы тоже переконвертировались в InnoDb.

# ./checksetup.pl

В конце также нажимаем Ctrl+C.

4.5 Можно получить краткую справку как использовать скрипт перекодировки:

# ./contrib/recode.pl --help

В моем случае с кодировкой latin1 (cp1251) я вызываю команду следующим образом:

# ./contrib/recode.pl --show-failures --charset=cp1251

Будет выводиться список перекодированных таблиц и их полей :

Converting attachments.description...
Converting attachments.mimetype...
Converting attachments.filename...
Converting bug_severity.value...
....

Когда все базы перекодировались последний раз вызываем checksetup.pl :

# ./checksetup.pl

Когда появится сообщение:

WARNING: We are about to convert your table storage format to UTF8. ....
.....
Press Enter to continue or Ctrl-C to exit...

Жмем Enter. Получаем примерно следующие сообщения:

Converting table storage format to UTF-8. This may take a while.
Converting attachments.description to be stored as UTF-8...
Converting attachments.mimetype to be stored as UTF-8...
....

5. Визуально оцениваем корректность перекодировки

Вот и все. Можно заходить в новую bugzilla 3.4.2 под старыми пользователями. Смотреть свои старые списки ошибок, поиски и т.д. Можно сравнить, что было в версии bugzilla 2.20 :

И как стало отображаться в версии bugzilla 3.4.2:

Смотрим содержимое какой-нибудь ошибки:

Видно, что все перекодировалось с latin1 в utf8 корректно. И переход c bugzilla 2.20 на bugzilla 3.4.2 прошел успешно