免責事項
- この翻訳は MySQL Server Blogの記事をユーザーが翻訳したものであり、Oracle公式の翻訳ではありません。
本文
この記事はMySQLのアップグレードに関する2部作の2番目である。1つ目の記事は mysqldumpを使って5.0から5.7に直接アップグレードする で、
mysqldumpを利用したアップグレードの挙動について言及している。我々はこれを'ダンプ'アップグレードと呼んでいる。この記事では我々が`インプレース'アップグレードと呼んでいる、バイナリーアップグレードやライブアップグレードとしても知られているやり方について言及する。'ダンプ'アップグレードは何かの変更をする前にデータベースのバックアップを取っておくことを推奨する。アップグレードの作業を開始する前に、移行先バージョンのアップグレード関連のドキュメントを必ず読むこと。アップグレードに関する重要なTIPSや情報が含まれている: 5.1へのアップグレード, 5.5へのアップグレード, 5.6へのアップグレード, 5.7へのアップグレード
'インプレース'アップグレードは'ダンプ'アップグレードよりも速い。何故なら、アップグレードプロセスの一環としてデータベースをロードし直す必要がないからだ。もう一度言うと、この方法はロードにかかる時間を短縮するが、アップグレード前のバックアップは(訳注: 'ダンプ'アップグレードに比べて)より重要になる。全てのアップグレードの手順は'インプレース'で、もともとのデータディレクトリ上で行われるからだ。(訳注: 古いバージョンから引き継いだ)同じデータファイルを使うことで、サーバーの再構築が必要な類の新機能は使えなくなる。UNDOテーブルスペースの作成(5.6.3で導入された)や既に存在するInnoDBのテーブルを個別のテーブルスペースに再構築することだ(innodb_file_per_tableは5.6.6からデフォルトで有効になった) (訳注: 'インプレース'アップグレードでは既にibdata1に作られたInnoDBのテーブルを自動で.ibdファイルに分割はできない)
アップグレードは以下の手順で進めた。
1. 元となるMySQL 5.0.96のサーバーにsakila schema(訳注: MySQL公式のサンプルデータベースの1つ)をロードしておく。説明をシンプルにするため、--no-defaultsオプションを付けてサーバーを起動した。
$ cd <mysql 5.0.96 basedir>
$ ./scripts/mysql_install_db --no-defaults --datadir=<DATADIR> --basedir=.
$ ./bin/mysqld_safe --no-defaults --datadir=<DATADIR> --basedir=. --port=<PORT> --socket=<SOCKET> &
$ ./bin/mysql -uroot --socket=<SOCKET> --execute="create database sakila;"
$ ./bin/mysql -uroot --socket=<SOCKET> --execute="source sakila-schema.sql" --database=sakila
$ ./bin/mysql -uroot --socket=<SOCKET> --execute="source sakila-data.sql" --database=sakila
2. MySQLサーバーを停止する。これは(訳注: アップグレード前のデータの)バックアップを取るいいタイミングになるだろう。次に、ディレクトリーを新しいバージョンのものに移動して、MySQLサーバーを起動する。ここで同じデータディレクトリーを使うので、全てのデータファイルはDATADIRの中に存在していなければならない。
$ cd <mysql 5.0.96 basedir>
$ ./bin/mysqladmin -uroot --socket=<SOCKET> shutdown
$ cd <mysql 5.7.9 basedir>
$ ./bin/mysqld_safe --no-defaults --datadir=<DATADIR> --basedir=. --port=< PORT> --socket=<SOCKET> --skip-grant-tables &
- 憶えておいて欲しいのは、MySQL 5.0.xと5.1.xのバージョン(訳注: で作られたデータディレクトリー)を5.7.xのバイナリーから使うには、初回のみ
--skip-grant-tablesをMySQLサーバーの起動オプションに与えなければならないことだ。
3. mysql_upgradeを実行する（全てのシステムテーブルがアップグレードされる）
$ ./bin/mysql_upgrade -uroot --socket=<SOCKET>
4. ヘルプテーブルをロードする（やらなくても良い）
$ ./bin/mysql -uroot --socket=<SOCKET> --execute="source ./share/fill_help _tables.sql" mysql
5. MySQLサーバーを再起動する
$ ./bin/mysqladmin -uroot --socket=<SOCKET> shutdown
$ ./bin/mysqld_safe --no-defaults --datadir=<DATADIR> --basedir=. --port=<PORT> --socket=<SOCKET> &
6. 全てのテーブルの状態を確認するために、mysqlcheckを実行する
$ ./bin/mysqlcheck -uroot --socket=<SOCKET> --all-databases
- もしMySQL 5.0.96からのアップグレードなら、ここでいくつかのユーザーテーブルやトリガーの再構築/アップグレードが要求される。sakila schemaの例だと、
mysql_upgradeが以下のようなトリガーを修復せよというワーニングを出力する（その他の出力は省いてある）
Warning : Triggers for table `sakila`.`customer` have no creation context
Warning : Triggers for table `sakila`.`film` have no creation context
Warning : Triggers for table `sakila`.`payment` have no creation context
Warning : Triggers for table `sakila`.`rental` have no creation context
- トリガーのためのメタデータを変更するため、トリガーの再作成が要求される。以下の手順でトリガーを再作成する。
1. mysqldumpを使ってトリガーを(訳注: SQLとして)展開する
$ ./bin/mysqldump --socket=<SOCKET> -uroot --triggers --no-create-db --no-data --no-create-info --all-databases > addtriggers.sql
2. 既存のトリガーを削除するスクリプトを作る。'sys'を除外しているのは、mysqldumpの出力は'sys'のものを含まないからだ。
mysql> SELECT CONCAT('DROP TRIGGER ', TRIGGER_SCHEMA, '.',
TRIGGER_NAME, ';')
FROM INFORMATION_SCHEMA.TRIGGERS
WHERE trigger_schema not in ('sys')
INTO OUTFILE 'droptriggers.sql';
3. 既存のトリガーを削除する。
$ ./bin/mysql --socket=<SOCKET> -uroot --execute="source droptriggers.sql"
4. トリガーを再作成する。
$ ./bin/mysql --socket=<SOCKET> -uroot --execute="source addtriggers.sql"
5. 全てのテーブルの状態を確認するために、mysqlcheckを実行する
$ ./bin/mysqlcheck -uroot --socket=<SOCKET> --all-databases
- この手順の'インプレース'アップグレードは、MySQL 5.0.96, 5.1.73, 5.5.46, 5.6.27から5.7.9へのアップグレードに成功した。これら(訳注: 各バージョンからのアップグレードが正しく行われたこと)の検証は、 mysqlcheck によるチェック、テーブルの数, カラムの数, 全てのスキーマのルーチンの数の確認、基本的なSELECT/INSERT/UPDATE/DELETEステートメントが動くこと、ユーザー関数やストアドプロシージャがちゃんと動くこと、で確認している。
(訳注: 'インプレース'アップグレードの手順は) これだけだ。 MySQLを使ってくれてありがとう！
