データ移行について
3,542 views
Skip to first unread message
Crulea
Jul 23, 2009, 11:20:40 PM7/23/09
to Redmine Users (japanese)
Redmine間のデータ移行の方法について教えてください。
既にRedmine v0.7を利用しており、一部のプロジェクトが拡大することになったため、
別途、Redmineのサーバ（Redmine v0.8.4）を構築し、特定のプロジェクトの関連データのみを移行したいと思っているのですが、どの
ような方法があるか、教えていただけませんでしょうか。
よろしくお願い致します。
既にRedmine v0.7を利用しており、一部のプロジェクトが拡大することになったため、
別途、Redmineのサーバ（Redmine v0.8.4）を構築し、特定のプロジェクトの関連データのみを移行したいと思っているのですが、どの
ような方法があるか、教えていただけませんでしょうか。
よろしくお願い致します。
Syysk
Jul 27, 2009, 8:13:09 PM7/27/09
to Redmine Users (japanese)
Syyskです。
一番簡単な方法は、データベースをすべて移行後、対象プロジェクト以外を
削除する方法だと思います。
ユーザーも一緒に移行されてしまうため、必要な場合は無効化する必要があります。
ただ、Watcherなど完全に綺麗な状態にはなりません。
削除する方法だと思います。
ユーザーも一緒に移行されてしまうため、必要な場合は無効化する必要があります。
ただ、Watcherなど完全に綺麗な状態にはなりません。
Crulea
Jul 27, 2009, 9:14:37 PM7/27/09
to Redmine Users (japanese)
回答ありがとうございます。
> 一番簡単な方法は、データベースをすべて移行後、対象プロジェクト以外を
> 削除する方法だと思います。
> ユーザーも一緒に移行されてしまうため、必要な場合は無効化する必要があります。
> ただ、Watcherなど完全に綺麗な状態にはなりません。
確かにデータ自体は移行できたのですが、日本語データが全部文字化けしてしまいました。
移行の際にエンコードの指定ができるものがどうか調べてみます。
> 一番簡単な方法は、データベースをすべて移行後、対象プロジェクト以外を
> 削除する方法だと思います。
> ユーザーも一緒に移行されてしまうため、必要な場合は無効化する必要があります。
> ただ、Watcherなど完全に綺麗な状態にはなりません。
移行の際にエンコードの指定ができるものがどうか調べてみます。
Syysk
Jul 28, 2009, 12:02:09 AM7/28/09
to Redmine Users (japanese)
Syyskです。
MySQLだと過程すると、一番可能性が高いのは
データベース作成時のエンコード指定を忘れてるとか・・
mysqldump -u ユーザー -pパスワード redmine > redmine_dmp.sql
mysqladmin drop redmine -u ユーザー -pパスワード -f
mysqladmin create redmine --default-character-set=utf8 -u ユーザー -pパスワード
-f
mysql -u ユーザー -D redmine -pパスワード < redmine_dmp.sql
こんな感じのスクリプトでバックアップとリカバリしてます。
MySQLだと過程すると、一番可能性が高いのは
データベース作成時のエンコード指定を忘れてるとか・・
mysqldump -u ユーザー -pパスワード redmine > redmine_dmp.sql
mysqladmin drop redmine -u ユーザー -pパスワード -f
mysqladmin create redmine --default-character-set=utf8 -u ユーザー -pパスワード
-f
mysql -u ユーザー -D redmine -pパスワード < redmine_dmp.sql
こんな感じのスクリプトでバックアップとリカバリしてます。
Crulea
Jul 28, 2009, 9:26:22 PM7/28/09
to Redmine Users (japanese)
ご返答いただき、ありがとうございます。
DB作成時は、下記のように指定したので、基本的にキャラクタセットはutf8と思っていたのですが、、、
> create database redmine character set utf8
今回改めて調べてみたところ、下記のように表示されたので、ちょっと驚いております。
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+--------+
※移行元のDBも、移行先のDBも、全く同じ設定でした。
教えていただいたバックアップとリカバリのスクリプトも
実施したものとほぼ同じで、違っているとすれば、
mysqldumpに-optと付けたことくらいなのですが。。。
ブラウザのエンコードもutf8が選択されているので、「なぜ？」と
思うのですが、まだ文字化けから脱出できておりません。orz
DB作成時は、下記のように指定したので、基本的にキャラクタセットはutf8と思っていたのですが、、、
> create database redmine character set utf8
今回改めて調べてみたところ、下記のように表示されたので、ちょっと驚いております。
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+--------+
※移行元のDBも、移行先のDBも、全く同じ設定でした。
教えていただいたバックアップとリカバリのスクリプトも
実施したものとほぼ同じで、違っているとすれば、
mysqldumpに-optと付けたことくらいなのですが。。。
ブラウザのエンコードもutf8が選択されているので、「なぜ？」と
思うのですが、まだ文字化けから脱出できておりません。orz
Syysk
Jul 29, 2009, 1:16:06 AM7/29/09
to Redmine Users (japanese)
Syyskです。
On 7月29日, 午前10:26, Crulea <wishing.your.all.the.b...@gmail.com> wrote:
> DB作成時は、下記のように指定したので、基本的にキャラクタセットはutf8と思っていたのですが、、、
>
> > create database redmine character set utf8
utf8にはなってないですね。
内部データについてもlatin1で作成されてそうです。
取得したバックアップSQLの中身の
CREATE TABLE `attachments` (
などの最後の行
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
のutf8部分がlatin1になってたりしないでしょうか？
あと、稼働させているOSはなんでしょうか？
現在のRedmineデータベース作成時に
create database redmine
のみで作成してみて文字化けがするかどうか確認するとよいかもです。
On 7月29日, 午前10:26, Crulea <wishing.your.all.the.b...@gmail.com> wrote:
> DB作成時は、下記のように指定したので、基本的にキャラクタセットはutf8と思っていたのですが、、、
>
> > create database redmine character set utf8
内部データについてもlatin1で作成されてそうです。
取得したバックアップSQLの中身の
CREATE TABLE `attachments` (
などの最後の行
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
のutf8部分がlatin1になってたりしないでしょうか？
あと、稼働させているOSはなんでしょうか？
現在のRedmineデータベース作成時に
create database redmine character set utf8
の character setを忘れていた場合は
create database redmine
のみで作成してみて文字化けがするかどうか確認するとよいかもです。
Crulea
Jul 29, 2009, 11:16:07 PM7/29/09
to Redmine Users (japanese)
何度もご返答いただき、本当にありがとうございます。
> 取得したバックアップSQLの中身の
> CREATE TABLE `attachments` (
> などの最後の行
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
> のutf8部分がlatin1になってたりしないでしょうか？
おっしゃるとおりlatin1になっていました。
> あと、稼働させているOSはなんでしょうか？
CentOS5.3です。
> 現在のRedmineデータベース作成時に
> create database redmine
> のみで作成してみて文字化けがするかどうか確認するとよいかもです。
キャラクタセットをせずに作成してみましたが、同じように文字化けします。。
なおかつ変数を確認すると、指定したときと同じように、下記のようになっていました。
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+--------+
バックアップのダンプファイル自体を、iconvやnkfで文字変換をしてみたのですが、文字化けの記号が変わるだけで、解決しませんでした。
以上、よろしくお願い致します。
> 取得したバックアップSQLの中身の
> CREATE TABLE `attachments` (
> などの最後の行
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
> のutf8部分がlatin1になってたりしないでしょうか？
> あと、稼働させているOSはなんでしょうか？
CentOS5.3です。
> 現在のRedmineデータベース作成時に
> create database redmine
> のみで作成してみて文字化けがするかどうか確認するとよいかもです。
キャラクタセットをせずに作成してみましたが、同じように文字化けします。。
なおかつ変数を確認すると、指定したときと同じように、下記のようになっていました。
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+--------+
以上、よろしくお願い致します。
Syysk
Jul 30, 2009, 12:00:58 AM7/30/09
to Redmine Users (japanese)
Syyskです。
On 7月30日, 午後12:16, Crulea <wishing.your.all.the.b...@gmail.com> wrote:
> おっしゃるとおりlatin1になっていました。
バックアップ元とバックアップ先が同一データベースの場合本番環境に影響を与える可能性がありますが、
下記の対処を行う事によりlatin1をutf8へ変更する事が可能です。
※実施する前にデータベースのフルバックアップをお勧めします。
musql>set names utf8;
--
/etc/my.conf を編集
[mysqld]
default-character-set=utf8
↑追記
--
service mysqld restart
今あるデータベースの変更を行う場合は
alter databese などで可能ですが、
dumpにて取得したSQLファイルのlatin1とutf8に変更してimportした方が早いです。
mysqldump --default-character-set=latin1 -uユーザー名 redmine >
redmine_dmp.sql
sedかviの置換で latin1をutf8へ変更
mysqladmin create redmine --default-character-set=utf8 -u ユーザー -pパスワード
-f
mysql -u ユーザー -D redmine -pパスワード < redmine_dmp.sql
これで
mysql> show variables like "char%";
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
+--------------------------+----------------------------+
こんな感じになると思います。
# latin1でデータベースが作成されていても登録データをutf8で行えば結構問題なく動いたりします。
# redmineを初めた最初の頃おなじ問題で悩みました
On 7月30日, 午後12:16, Crulea <wishing.your.all.the.b...@gmail.com> wrote:
> おっしゃるとおりlatin1になっていました。
バックアップ元とバックアップ先が同一データベースの場合本番環境に影響を与える可能性がありますが、
下記の対処を行う事によりlatin1をutf8へ変更する事が可能です。
※実施する前にデータベースのフルバックアップをお勧めします。
musql>set names utf8;
--
/etc/my.conf を編集
[mysqld]
default-character-set=utf8
↑追記
--
service mysqld restart
今あるデータベースの変更を行う場合は
alter databese などで可能ですが、
dumpにて取得したSQLファイルのlatin1とutf8に変更してimportした方が早いです。
mysqldump --default-character-set=latin1 -uユーザー名 redmine >
redmine_dmp.sql
sedかviの置換で latin1をutf8へ変更
mysqladmin create redmine --default-character-set=utf8 -u ユーザー -pパスワード
-f
mysql -u ユーザー -D redmine -pパスワード < redmine_dmp.sql
mysql> show variables like "char%";
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
+--------------------------+----------------------------+
こんな感じになると思います。
# latin1でデータベースが作成されていても登録データをutf8で行えば結構問題なく動いたりします。
# redmineを初めた最初の頃おなじ問題で悩みました
fmkt
Jul 30, 2009, 12:15:15 AM7/30/09
to Redmine Users (japanese)
こんにちは。
Syyskのレスでもう解決するかもしれませんが、この辺りが参考になったのかも。
mysqlのデータベース文字コード再設定
http://fmkt.blog65.fc2.com/blog-entry-6.html
Syyskさんが示した方法と上記で提示した差は
dumpするときの charaset を latin1 ではなく binary にたくらいで他の方法はほぼ同じです。
では。
Syyskのレスでもう解決するかもしれませんが、この辺りが参考になったのかも。
mysqlのデータベース文字コード再設定
http://fmkt.blog65.fc2.com/blog-entry-6.html
Syyskさんが示した方法と上記で提示した差は
dumpするときの charaset を latin1 ではなく binary にたくらいで他の方法はほぼ同じです。
では。
Crulea
Jul 30, 2009, 8:06:07 AM7/30/09
to Redmine Users (japanese)
Syyskさん、fmkt さん
いろいろ教えていただき、ありがとうございました。
テスト環境を作ってやってみたところ、うまくいきました。
正確に報告すると・・・
mysqldump --default-character-set=latin1 にして、viで latin1をutf8に全部変更して、ロード
し直すと、やはり文字化けしてしまいました。この際、ダンプしたファイルの中身をcatでみると、文字化けした部分が、文字化けして見えていました。
mysqldump --default-character-set=binary にしてダンプに落とすと、 viで latin1を探しても、そ
もそも全部utf8になっており、日本語のテキスト部分がちゃんと日本語で表示されていました。これを移行先に移動して、ロードしたところ、文字化けを
せず、ちゃんと表示されました。
CentOSもMySQLも超ビギナーなので、どうしてこういう違いが発生したのか理由は不明なのですが、報告まで。
Syyskさん、fmkt さん、本当にありがとうございました。
いろいろ教えていただき、ありがとうございました。
テスト環境を作ってやってみたところ、うまくいきました。
正確に報告すると・・・
mysqldump --default-character-set=latin1 にして、viで latin1をutf8に全部変更して、ロード
し直すと、やはり文字化けしてしまいました。この際、ダンプしたファイルの中身をcatでみると、文字化けした部分が、文字化けして見えていました。
mysqldump --default-character-set=binary にしてダンプに落とすと、 viで latin1を探しても、そ
もそも全部utf8になっており、日本語のテキスト部分がちゃんと日本語で表示されていました。これを移行先に移動して、ロードしたところ、文字化けを
せず、ちゃんと表示されました。
CentOSもMySQLも超ビギナーなので、どうしてこういう違いが発生したのか理由は不明なのですが、報告まで。
Syyskさん、fmkt さん、本当にありがとうございました。
Reply all
Reply to author
Forward
0 new messages