このセクションでは、Unix/Linux で MySQL バイナリおよびパッケージベースのインストールをアップグレードする方法について説明します。 インプレースおよび論理アップグレード方法について説明します。
インプレースアップグレードには、古い MySQL サーバーの停止、古い MySQL バイナリまたはパッケージの新しいバイナリまたはパッケージへの置換、既存のデータディレクトリでの MySQL の再起動、およびアップグレードが必要な既存のインストールの残りの部分のアップグレードが含まれます。 アップグレードが必要なものの詳細は、セクション2.11.3「MySQL のアップグレードプロセスの内容」 を参照してください。
最初に複数の RPM パッケージをインストールして作成したインストールをアップグレードする場合は、一部だけでなく、すべてのパッケージをアップグレードします。 たとえば、以前にサーバーおよびクライアントの RPM をインストールした場合は、サーバーの RPM だけをアップグレードすることはしないでください。
一部の Linux プラットフォームでは、RPM または Debian パッケージからの MySQL インストールに、MySQL サーバーの起動と停止を管理するための systemd サポートが含まれています。 これらのプラットフォームでは、mysqld_safe はインストールされません。 このような場合は、次の手順で使用する方法ではなく、systemd を使用してサーバーを起動および停止します。 セクション2.5.9「systemd を使用した MySQL Server の管理」を参照してください。
MySQL クラスタインストールへのアップグレードについては、MySQL クラスタのアップグレード も参照してください。
インプレースアップグレードを実行するには:
セクション2.11.1「始める前に」 の情報を確認します。
セクション2.11.5「アップグレード用のインストールの準備」 で事前チェックを完了して、インストールのアップグレード準備が整っていることを確認します。
XA トランザクションを
InnoDB
で使用する場合は、アップグレードの前にXA RECOVER
を実行して、コミットされていない XA トランザクションを確認します。 結果が返された場合は、XA COMMIT
またはXA ROLLBACK
ステートメントを発行して XA トランザクションをコミットまたはロールバックします。-
暗号化された
InnoDB
テーブルスペースがある場合は、次のステートメントを実行してキーリングマスターキーをローテーションします:ALTER INSTANCE ROTATE INNODB MASTER KEY;
-
innodb_fast_shutdown
を2
(コールドシャットダウン) に設定して構成した MySQL サーバーを通常実行する場合は、次のいずれかのステートメントを実行して、高速または低速なシャットダウンを実行するように構成します:SET GLOBAL innodb_fast_shutdown = 1; -- fast shutdown SET GLOBAL innodb_fast_shutdown = 0; -- slow shutdown
高速停止または低速停止では、
InnoDB
は undo ログおよびデータファイルを、リリース間でファイル形式が異なる場合に処理できる状態のままにします。 -
古い MySQL サーバーを停止します。 例:
mysqladmin -u root -p shutdown
MySQL バイナリまたはパッケージをアップグレードします。 バイナリインストールをアップグレードする場合は、新しい MySQL バイナリ配布パッケージを解凍します。 配布の取得とアンパックを参照してください。 パッケージベースのインストールの場合は、新しいパッケージをインストールします。
-
既存のデータディレクトリを使用して、MySQL 8.0 サーバーを起動します。 例:
mysqld_safe --user=mysql --datadir=/path/to/existing-datadir &
暗号化された
InnoDB
テーブルスペースがある場合は、--early-plugin-load
オプションを使用してキーリングプラグインをロードします。MySQL 8.0 サーバーを起動すると、データディクショナリテーブルが存在するかどうかが自動的に検出されます。 そうでない場合、サーバーはデータディレクトリにそれらを作成し、メタデータを移入してから、通常の起動シーケンスに進みます。 このプロセス中、サーバーは、データベース、テーブルスペース、システムテーブルとユーザーテーブル、ビュー、ストアドプログラム (ストアドプロシージャと関数、トリガーおよびイベントスケジューライベント) など、すべてのデータベースオブジェクトのメタデータをアップグレードします。 サーバーは、以前にメタデータ記憶域に使用されていたファイルも削除します。 たとえば、MySQL 5.7 から MySQL 8.0 にアップグレードした後、テーブルに
.frm
ファイルがなくなった場合があります。このステップが失敗すると、サーバーはすべての変更をデータディレクトリに戻します。 この場合、すべての redo ログファイルを削除し、同じデータディレクトリで MySQL 5.7 サーバーを起動して、エラーの原因を修正する必要があります。 次に、5.7 サーバーの別の低速シャットダウンを実行し、MySQL 8.0 サーバーを起動して再試行します。
-
前のステップでは、サーバーは必要に応じてデータディクショナリをアップグレードします。 ここで、残りのアップグレード操作を実行する必要があります:
MySQL 8.0.16 の時点では、サーバーは前のステップの一部としてこれを行い、新しい権限または機能を利用できるように、
mysql
システムデータベースで MySQL 5.7 と MySQL 8.0 の間で必要な変更を行います。 また、パフォーマンススキーマ、INFORMATION_SCHEMA
およびsys
データベースを MySQL 8.0 用に最新の状態にし、すべてのユーザーデータベースで現在のバージョンの MySQL との非互換性を調べます。-
MySQL 8.0.16 より前は、サーバーは前のステップのデータディクショナリのみをアップグレードします。 MySQL 8.0 サーバーが正常に起動したら、mysql_upgrade を実行して残りのアップグレードタスクを実行します:
mysql_upgrade -u root -p
次に、MySQL サーバーを停止して再起動し、システムテーブルに対する変更が有効になるようにします。 例:
mysqladmin -u root -p shutdown mysqld_safe --user=mysql --datadir=/path/to/existing-datadir &
(前のステップで)MySQL 8.0 サーバーを初めて起動すると、アップグレードされていないテーブルに関するメッセージがエラーログに記録される場合があります。 mysql_upgrade が正常に実行された場合、サーバーの再起動時にこのようなメッセージは表示されません。
アップグレードプロセスでは、タイムゾーンテーブルの内容はアップグレードされません。 アップグレードの手順については、セクション5.1.15「MySQL Server でのタイムゾーンのサポート」を参照してください。
アップグレードプロセスで mysql_upgrade (MySQL 8.0.16 より前) が使用されている場合、このプロセスではヘルプテーブルの内容もアップグレードされません。 この場合のアップグレード手順については、セクション5.1.17「サーバー側ヘルプのサポート」 を参照してください。
論理アップグレードには、mysqldump や mysqlpump などのバックアップまたはエクスポートユーティリティを使用した古い MySQL インスタンスからの SQL のエクスポート、新しい MySQL サーバーのインストール、および新しい MySQL インスタンスへの SQL の適用が含まれます。 アップグレードが必要なものの詳細は、セクション2.11.3「MySQL のアップグレードプロセスの内容」 を参照してください。
一部の Linux プラットフォームでは、RPM または Debian パッケージからの MySQL インストールに、MySQL サーバーの起動と停止を管理するための systemd サポートが含まれています。 これらのプラットフォームでは、mysqld_safe はインストールされません。 このような場合は、次の手順で使用する方法ではなく、systemd を使用してサーバーを起動および停止します。 セクション2.5.9「systemd を使用した MySQL Server の管理」を参照してください。
以前の MySQL リリースから抽出された SQL を新しい MySQL リリースに適用すると、新しい機能、変更された機能、非推奨になった機能または削除された機能によって導入された非互換性が原因でエラーが発生する場合があります。 したがって、以前の MySQL リリースから抽出された SQL では、論理アップグレードを有効にするために変更が必要になる場合があります。
最新の MySQL 8.0 リリースにアップグレードする前に非互換性を識別するには、セクション2.11.5「アップグレード用のインストールの準備」 で説明されているステップを実行します。
論理アップグレードを実行するには:
セクション2.11.1「始める前に」 の情報を確認します。
-
以前の MySQL インストールから既存のデータをエクスポートします:
mysqldump -u root -p --add-drop-table --routines --events --all-databases --force > data-for-upgrade.sql
注記データベースにストアドプログラムが含まれている場合は、mysqldump で
--routines
および--events
オプションを使用します (前述を参照)。--all-databases
オプションには、システムテーブルを保持するmysql
データベースを含む、ダンプ内のすべてのデータベースが含まれます。重要生成されたカラムを含むテーブルがある場合は、MySQL 5.7.9 以上で提供される mysqldump ユーティリティを使用してダンプファイルを作成します。 以前のリリースで提供されていた mysqldump ユーティリティでは、生成されたカラム定義に不正な構文が使用されています (Bug #20769542)。
INFORMATION_SCHEMA.COLUMNS
テーブルを使用して、生成されたカラムを持つテーブルを識別できます。 -
古い MySQL サーバーを停止します。 例:
mysqladmin -u root -p shutdown
MySQL 8.0 をインストールします。 インストールの手順については、第2章「MySQL のインストールとアップグレード」を参照してください。
-
セクション2.10.1「データディレクトリの初期化」 の説明に従って、新しいデータディレクトリを初期化します。 例:
mysqld --initialize --datadir=/path/to/8.0-datadir
画面に表示された一時
'root'@'localhost'
パスワードをコピーするか、後で使用するためにエラーログに書き込みます。 -
新しいデータディレクトリを使用して、MySQL 8.0 サーバーを起動します。 例:
mysqld_safe --user=mysql --datadir=/path/to/8.0-datadir &
-
root
パスワードをリセットします:shell> mysql -u root -p Enter password: **** <- enter temporary root password
mysql> ALTER USER USER() IDENTIFIED BY 'your new password';
-
以前に作成したダンプファイルを新しい MySQL サーバーにロードします。 例:
mysql -u root -p --force < data-for-upgrade.sql
注記ダンプファイルにシステムテーブルが含まれている場合、GTID がサーバー (
gtid_mode=ON
) で有効になっているときにダンプファイルをロードすることはお薦めしません。mysqldump は、非トランザクション MyISAM ストレージエンジンを使用するシステムテーブルに対して DML 命令を発行します。GTID が有効になっている場合、この組み合わせは許可されません。 GTID が有効になっているサーバーから GTID が有効になっている別のサーバーにダンプファイルをロードすると、異なるトランザクション識別子が生成されることにも注意してください。 -
残りのアップグレード操作を実行します:
-
MySQL 8.0.16 以上では、サーバーを停止し、
--upgrade=FORCE
オプションを使用して再起動して残りのアップグレードタスクを実行します:mysqladmin -u root -p shutdown mysqld_safe --user=mysql --datadir=/path/to/8.0-datadir --upgrade=FORCE &
--upgrade=FORCE
を使用して再起動すると、新しい権限または機能を利用できるように、mysql
システムスキーマで MySQL 5.7 と MySQL 8.0 の間で必要な変更がサーバーによって行われます。 また、パフォーマンススキーマ、INFORMATION_SCHEMA
、およびsys
スキーマを MySQL 8.0 用に最新の状態にし、すべてのユーザースキーマで現在のバージョンの MySQL との非互換性を調べます。 -
MySQL 8.0.16 より前は、mysql_upgrade を実行して残りのアップグレードタスクを実行します:
mysql_upgrade -u root -p
次に、MySQL サーバーを停止して再起動し、システムテーブルに対する変更が有効になるようにします。 例:
mysqladmin -u root -p shutdown mysqld_safe --user=mysql --datadir=/path/to/8.0-datadir &
-
アップグレードプロセスでは、タイムゾーンテーブルの内容はアップグレードされません。 アップグレードの手順については、セクション5.1.15「MySQL Server でのタイムゾーンのサポート」を参照してください。
アップグレードプロセスで mysql_upgrade (MySQL 8.0.16 より前) が使用されている場合、このプロセスではヘルプテーブルの内容もアップグレードされません。 この場合のアップグレード手順については、セクション5.1.17「サーバー側ヘルプのサポート」 を参照してください。
MySQL 5.7 mysql
スキーマを含むダンプファイルをロードすると、使用されなくなった 2 つのテーブルが再作成されます: event
および proc
。 (対応する MySQL 8.0 テーブルは events
および routines
で、どちらもデータディクショナリテーブルであり、保護されています。) アップグレードが成功したことを確認したら、次の SQL ステートメントを実行して event
テーブルおよび proc
テーブルを削除できます:
DROP TABLE mysql.event;
DROP TABLE mysql.proc;
このセクションの情報は、MySQL クラスタをアップグレードする場合に使用するための、インプレースアップグレード で説明されているインプレースアップグレード手順に関連しています。
MySQL 8.0.16 では、MySQL クラスタのアップグレードは、通常の順序付きステップに従って定期的なローリングアップグレードとして実行できます:
MGM ノードのアップグレード。
データノードを一度に 1 つずつアップグレードします。
API ノードを一度に 1 つずつアップグレードします (MySQL サーバーを含む)。
データディクショナリのアップグレードとシステムテーブルのアップグレードは分離されているため、各ノードをアップグレードする方法は MySQL 8.0.16 の前とほとんど同じです。 個々の mysqld
をアップグレードするには、2 つのステップがあります:
-
データディクショナリをインポートします。
--upgrade=MINIMAL
オプションを使用して新しいサーバーを起動し、データディクショナリをアップグレードしますが、システムテーブルはアップグレードしません。 これは基本的に、mysql_upgrade を起動せずにサーバーを起動する pre-MySQL 8.0.16 アクションと同じです。このフェーズを完了するには、MySQL サーバーを
NDB
に接続する必要があります。NDB
テーブルまたはNDBINFO
テーブルが存在し、サーバーがクラスタに接続できない場合は、次のエラーメッセージで終了します:Failed to Populate DD tables.
-
システムテーブルをアップグレードします。
MySQL 8.0.16 より前は、DBA は mysql_upgrade クライアントを起動してシステムテーブルをアップグレードします。 MySQL 8.0.16 の時点で、サーバーはこのアクションを実行: システムテーブルをアップグレードするには、
--upgrade=MINIMAL
オプションを指定せずに個々の mysqld を再起動します。