![Bitnami Redmine (Windows) 3.1.2→4.1.0の移行でハマった事](https://gourmet-technology-crypto.jp/wp-content/uploads/2020/03/redmine.png)
2019/12/20に1年ぶりのリリースとなるRedmine 4.1.0がリリースされました。
UIの改善や機能追加が多くかなり良さそうな印象を受けたので、長らくアップデートしていなかった3.1.2から4.1.0への移行の検証を行う事にしました。
Redmine 4.1.0 リリース - Redmine.JP -
目次
Redmine移行のハードル
Redmineのバージョン移行は他のソフトウェアと違って互換性が少ない為簡単にアップデートできず、かなりハードルが高いと思います。
主な障害点として、
- 現行データベースの移行
- プラグインの互換性
の2つが挙げられます。
メジャーバージョンが上がればデータベースやRailsのバージョンも大きく変わってデータベースの移行がすんなりいかなかったり、特にプラグインは開発が止まっているものもある為インストールに工夫が必要だったり、対応していないものもあります。
検証した環境
- Microsoft Azure Virtual Machines
- Windows 10 Pro 64bit
- バージョン1909
- OSビルド:18363.657
データベース移行での障害
0000-00-00 00:00:00のエラー
通常はC:\Bitnami\redmine-4.1.0-8\use_redmine.batを起動し、バックアップしたデータを以下のコマンドを入力してインポート・マイグレーションできるのですが、今回のBitnami Redmine4.1.0-8ではMySQLが5.7.29になっており、マイグレーション時にエラーが発生します。
※パスワードは-pだけにすると聞かれるのでそちらで入力した方が安全。
mysql -u root -p<password> bitnami_redmine < <移行するデータベースのパス> cd apps\redmine\htdocs bundle exec rake db:migrate RAILS_ENV=production
エラーメッセージ
Mysql2::Error: Incorrect datetime value: '0000-00-00 00:00:00' for column 'closed_on' at row 281: ALTER TABLE `issues` CHANGE `description` `description` longtext DEFAULT NULL
5.7.8以降はsql_modeのデフォルト値が以下のようになっており、00:00:00 0000-00-00を許さないのがエラーの原因のようです。
MySQLのsql_modeのせいで'0000-00-00'登録時にエラーが出た昔話。 - Qiita -
こちらを参考にデータベースにログインし、sql_modeを確認します。
mysql -u root -p<password> bitnami_redmine mysql>SELECT @@GLOBAL.sql_mode; +-------------------------------------------------------------------------------------------------------------------------------------------+ | @@GLOBAL.sql_mode | +-------------------------------------------------------------------------------------------------------------------------------------------+ | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | +-------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)
SET GLOBAL sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
既にインデックスが存在するエラー
このままだとマイグレーション時に
Index name 'index_issues_on_parent_id' on table 'issues' already exists
ALTER TABLE issues DROP INDEX index_issues_on_parent_id;
この状態でデータベースのマイグレーションを行うとエラー無しで通ります。
プラグインの障害
プラグインはそれぞれの環境で使っている物が異なるので1つずつ検証するしかありませんが、
2つだけ工夫してインストールできたプラグインを紹介します。
Advanced Roadmap & Milestones plugin v2
こちらはロードマップを見やすくするプラグインです。
元々使用していたリポジトリは4.1に対応していませんでしたが、、ありがたい事にフォークして4.0以降に対応してくれている方がいました。
https://github.com/awk-kazmin/redmine_advanced_roadmap_v2
こちらのフォークはそのままマイグレーションしてインストールできました。
※追記
マイルストーン機能が対応されなくなったようで、過去に作ったマイルストーンへのリンクを踏むとInternal Errorが発生するようになりました。
その他にグラフ表示が文字化けしていたり、ちょこちょこ不具合もありそうなので結局アンインストールする事にしました。
Redmine Knowledgebase Plugin
本流の開発はストップして4.1に対応していませんでしたが、こちらもフォークして4.0-stable(Rails 5.2.2)に対応してくれてる方がいました。
https://github.com/southbridgeio/redmine_knowledgebase
しかしこちらはそのままではマイグレーション時にエラーが発生します。
Cannot drop index 'index_taggings_on_tag_id': needed in a foreign key constraint: DROP INDEX `index_taggings_on_tag_id` ON `taggings`
MySQLの仕様で外部キーを設定すると自動的にインデックスが作成され、外部キーが設定されたままインデックスを削除しようとするとエラーになるようです。
これだとすると、下記現象でpgsqlでは通るのかもhttps://t.co/WuuBi3bRay
>MySQLでは外部キーを設定すると自動的にインデックスが作成されるようです。
>逆に外部キーが設定されたままインデックスを削除しようとするとエラーになります。— y503Unavailable@Redmine Kindle本出版unofficialcooking (@y503Unavailable) March 4, 2020
これはデータベースにログインし、SQLで外部キー制約を無視するコマンドを入力する事でマイグレーションが通るようになりました。
SET FOREIGN_KEY_CHECKS=0;
※正規の方法では無いのでデータ移行後に過去のデータに破損が無いか、新規に記事が作成できるかなどを確認してください。
本来はRailsのマイグレーションの中で処理するべきとこちらの記事にもありますが、とりあえず通る事を確認するだけならこの方法でも良いのかも…
https://redmine.tokyo/issues/1085
4.1への移行の流れのまとめ
データベース移行でハマった事を踏まえて一連の流れとしてまとめます。
- 現行(移行元)のデータベースをバックアップ(パスワードはRedmineインストール時のもの)
mysqldump -u root -p<password> bitnami_redmine > <任意のバックアップファイル名>
- 移行先サーバーに4.1をインストール
- C:\Bitnami\redmine-4.1.0-8\manager-windows.exeで移行先サーバーのApacheとRedmineを停止し、MySQLのみ動く状態にする
- データベースにログイン
mysql -u root -p<password> bitnami_redmine
- データベースの作り直しと権限付与してログアウト
DROP DATABASE bitnami_redmine; CREATE DATABASE bitnami_redmine; GRANT all privileges on bitnami_redmine.* to bitnami@localhost identified by '<apps/redmine/htdocs/config/database.ymlに記載されてるbitnami_redmineのパスワード>'; flush privileges; exit;
- バックアップした移行元データベースをインポート
mysql -u root -p<password> bitnami_redmine < <移行元のバックアップファイルのパス>
- 再度データベースにログイン
mysql -u root -p<password> bitnami_redmine
- sql_modeで000:00:00 0000-00-00エラーが発生しないようにする
SET GLOBAL sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
- インデックスを削除してデータベースからログアウト
ALTER TABLE issues DROP INDEX index_issues_on_parent_id; exit;
- apps\redmine\htdocs\pluginsフォルダに4.1で動作するプラグインを保管する (knowledgebaseなど事前に対処必要なものは対処しておく)
- apps\redmine\htdocs\filesフォルダの中身(添付した画像やファイル等)を移行元から移行先へ丸ごとコピペ
- インストール・マイグレーション(※ruby/binを環境変数に登録してbundleのパスを通しておく)
bundle install --no-deployment bundle exec rake db:migrate RAILS_ENV=production bundle exec rake redmine:plugins:migrate RAILS_ENV=production
エラーが無ければOK。
MySQL、Apache、Redmineを再起動して移行完了。
後は動作確認する。
以上です!
社内サーバーの本番環境ではファイアウォールに注意!
Azureの仮想環境では上手く移行できましたが、いざ社内サーバーで環境構築した際にまたエラーが発生しました。
knowledgebaseプラグインのインストール時に発生したのですが、gitプロトコルが通らなくて依存パッケージがダウンロードできない…
みたいなエラーメッセージが出ていました。
gitプロトコルはTCPの9418番ポートで、社内のファイアウォールではブロックされていました。
gitプロトコルは高速な代わりにセキュアではない通信だそうです。
bundle config github.https true
上記のコマンドを実行する事でgitプロトコルからHTTPSに切り替える事ができ、インストール・マイグレーションには成功するのですが、何故かこのパターンだとThin_redmineが停止してしまうエラーが発生しました。
Thin_redmineのログを取る方法が見つからず、HTTPSを利用したインストールは諦めました。
knowledgebaseプラグインをアンインストールすれば正常動作するのですが、これを諦めたくなかった為ファイアウォールのgitプロトコルのポートを開放して再度インストールする事で正常にRedmineが動作するようになりました。
企業のサーバーで上手く環境構築ができない場合はファイアウォールの設定に注意しましょう!