はじめに
「この古いサーバー、OSのサポートもリポジトリも切れてて yum
が使えない…でもMySQLのバージョンは上げないと…」
システムの保守運用に携わっていると、そんな悩ましい場面に遭遇することがありますよね。
特に、RHEL 6系統の古いディストリビューションで稼働しているサーバーでは、SSL/TLSプロトコルの問題で外部リソースに接続できず、パッケージの更新が困難になりがちです。
この記事では、そんなレガシーな環境下で MySQL 5.5から5.7へ、RPMファイルを直接使って段階的にバージョンアップする具体的な手順を、環境構築のヒントからトラブルシューティングまで含めて徹底解説します。
-
yum
に頼らずRPMでMySQLをアップグレードする具体的な手順 - 段階的なバージョンアップ(5.5 → 5.6 → 5.7)の勘所
-
mysql_upgrade
実行時のよくあるエラーと解決策 - 古いOS環境をEC2などで再現するためのヒント
同じような課題に直面している方の助けになれば幸いです。
1. 検証環境の構築(EC2カスタムAMI作成のヒント)
実機での作業前には、必ず検証環境で手順を確認しましょう。
ここでは、古いLinuxディストリビューションの環境をクラウド上に再現するための、カスタムAMI作成の簡単な流れをご紹介します。
1.1. OSのISOファイルを入手する
古いOSのISOファイルは公式サイトでは配布終了していることが多いですが、公的なアーカイブサイト(大学のFTPサーバーなど)に残っている場合があります。「[OS名] [バージョン] archive iso download」などのキーワードで探してみましょう。
配布元 : https://ftp.riken.jp/Linux/
1.2. 仮想ディスクイメージを準備する
入手したISOファイルを使い、VirtualBoxやVMwareなどの仮想化ソフトで仮想マシンを作成します。その後、作成された仮想ディスクファイル(.vmdk
や.vdi
など)をエクスポートします。
1.3. クラウドにインポートしてカスタムイメージを作成
AWSの VM Import/Export のような機能を利用します。
- 準備した仮想ディスクイメージをオブジェクトストレージ(S3など)にアップロードします。
-
vmimport
のような専用のIAMロールを作成し、必要な権限を付与します。 -
import-image
コマンドなどを実行し、アップロードしたディスクイメージからカスタムイメージを作成します。
この手順により、オンプレミスやローカルの古い環境をクラウド上に再現し、安全にバージョンアップ作業を試すことができます。
2. MySQLバージョンアップ実践手順
ここからは、いよいよMySQLのバージョンアップ作業です。今回は 5.5.x
→ 5.6.x
→ 5.7.x
と段階的にアップグレードしていきます。
段階的にアップグレードする理由として、どのverでエラーが発生したか特定してデバッグしやすくする為です。
2-1 事前準備フェーズ
① RPMファイルをローカルに準備する
MySQLの公式アーカイブサイトから、アップグレードに必要なバージョンのRPMファイルをダウンロードします。
MySQL Community Server Archive
お使いのOS(例: Red Hat Enterprise Linux 6 / Oracle Linux 6
)に対応するRPMパッケージを選択します。以下のファイルが最低限必要です。
-
MySQL 5.6.x:
MySQL-server
MySQL-client
MySQL-shared
-
MySQL 5.7.x:
mysql-community-server
mysql-community-client
mysql-community-libs
mysql-community-common
ダウンロードしたファイルは、バージョンごとにフォルダ分けしておくと管理が楽です。
② サーバーへ接続し、ファイルを転送する
まず、お使いのターミナルソフトでサーバーにSSH接続します。
次に、サーバー上でRPMファイルを置くためのディレクトリを作成します。
# 作業サーバー
mkdir rpm_mysql
ローカル環境に戻り、scpコマンドなどでRPMファイル一式をサーバーに転送します。
# ローカル環境
# フォルダごと再帰的に転送
# scp -r -i [秘密鍵] ./rpm_mysql [ユーザー名]@[ホスト名]:/path/to/home/
scpコマンドを使用する理由
古いLinuxOSではOpenSSLのサポートするプロトコルが古くTLS 1.0や1.1で、現代のサーバーではセキュリティのため、新しいプロトコル(TLS 1.2以降)での接続しか受け付けません。
その為、localのPCでTLS1.2以降に対応している状態でファイルをダウンロードしてから、scpでクラウド環境のLinuxへ転送等を行うことで必要なファイルを準備したりする必要があります。
③ データベースのバックアップ (v5.5.x)
何よりも大事なのがバックアップです。mysqldumpで現在のデータベースをSQLファイルとして出力します。
# 作業サーバー
# [your_database_name] は実際のデータベース名に置き換えてください
mysqldump -u root -p [your_database_name] > backup_5.5.x.sql
# 出力されたファイルを確認
ls
# ファイルが破損していないか簡易チェック
head backup_5.5.x.sql
-- MySQL dump などの記述が見えれば、正常に出力されています。
2-2 アップグレード: 5.5.x → 5.6.x
① MySQLを停止し、旧バージョンを削除
システム操作のため、rootユーザーに切り替えてから作業します。
# 作業サーバー
su - # rootユーザーに切り替え
# MySQLサービスを停止
service mysqld stop
# インストール済みのパッケージを確認
# この結果をメモしておき、次の削除コマンドで使います
rpm -qa | grep -i mysql
# 表示された5.5系のパッケージを削除
# --nodepsで依存関係を無視して削除
# ファイル名は環境に合わせて適宜修正してください
rpm -e --nodeps MySQL-server-5.5.*.el6.x86_64
rpm -e --nodeps MySQL-client-5.5.*.el6.x86_64
rpm -e --nodeps MySQL-shared-5.5.*.el6.x86_64
# 削除されたことを確認 (何も表示されなければOK)
rpm -qa | grep -i mysql
② 依存パッケージと新バージョン(5.6.x)をインストール
MySQL 5.6はnumactlというパッケージに依存しているため、先にyumでインストールします。
# 作業サーバー
# 依存パッケージをインストール (途中の質問には 'y' で回答)
yum install numactl
いよいよMySQL 5.6をインストールします。パッケージのインストール順序が非常に重要です。
# 作業サーバー
# 必ず shared → client → server の順で!
# ファイル名はダウンロードしたものに合わせてください
rpm -Uvh /path/to/rpm_mySQL/5.6.x/MySQL-shared-*.rpm
rpm -Uvh /path/to/rpm_mySQL/5.6.x/MySQL-client-*.rpm
rpm -Uvh /path/to/rpm_mySQL/5.6.x/MySQL-server-*.rpm
③ MySQLを起動し、アップグレード処理を実行
# 作業サーバー
# MySQLを起動
service mysql start
# バージョンが5.6系になっているか確認
mysql -u root -p -e "SELECT VERSION();"
# ★重要★ システムテーブルを新しいバージョンに適合させる
mysql_upgrade -u root -p
④ 動作確認とバックアップ (v5.6.x)
MySQLにログインし、データが無事か確認します。その後、この時点でのバックアップも取得しておきましょう。
# 作業サーバー
# [your_database_name] は実際のデータベース名に置き換えてください
mysql -u root -p
# MySQL [(none)]> USE [your_database_name];
# MySQL [[your_database_name]]> SHOW TABLES;
# MySQL [[your_database_name]]> exit;
# 5.6系でのバックアップを取得
mysqldump -u root -p [your_database_name] > backup_5.6.x.sql
2-3 アップグレード: 5.6.x → 5.7.x
続けて5.7系へアップグレードします。手順は5.6へのアップグレードと似ていますが、いくつか注意点があります。
① MySQLを停止し、旧バージョン(5.6)を削除
# 作業サーバー
service mysqld stop
# 5.6系のパッケージを削除(ファイル名は環境に合わせる)
rpm -e --nodeps MySQL-server-5.6.*.el6.x86_64
rpm -e --nodeps MySQL-client-5.6.*.el6.x86_64
rpm -e --nodeps MySQL-shared-5.6.*.el6.x86_64
② 新バージョン(5.7.x)をインストール
5.7系では、インストールするパッケージが増え、順序も異なります。
# 作業サーバー
# 必ず common → libs → client → server の順で!
# ファイル名はダウンロードしたものに合わせてください
rpm -Uvh /path/to/rpm_mySQL/5.7.x/mysql-community-common-*.rpm
rpm -Uvh /path/to/rpm_mySQL/5.7.x/mysql-community-libs-*.rpm
rpm -Uvh /path/to/rpm_mySQL/5.7.x/mysql-community-client-*.rpm
rpm -Uvh /path/to/rpm_mySQL/5.7.x/mysql-community-server-*.rpm
Note: MySQL 5.7の初回起動時、rootの初期パスワードが /var/log/mysqld.log に出力されることがあります。もしログインできない場合は確認してみてください。
③ MySQLを起動し、アップグレード処理を実行
# 作業サーバー
service mysqld start
mysql -u root -p -e "SELECT VERSION();" # 5.7系になっていることを確認
④ mysql_upgrade とトラブルシューティング
いよいよ大詰めの mysql_upgrade です。5.7へのアップグレードでは、内部的なデータ構造の変更が大きいため、エラーが出やすいポイントです。
# 作業サーバー
mysql_upgrade -u root -p
実行後、以下のようなエラーが大量に表示されることがあります。
[your_database_name].table_name
error : Table rebuild required. Please do "ALTER TABLE `table_name` FORCE" or dump/reload to fix it!
...
これは、テーブルの形式が古いバージョンと互換性がなくなっているためです。慌てずに以下のコマンドでテーブルをチェックし、自動修復しましょう。
```bash
# 作業サーバー
# --auto-repair オプションでテーブルを修復
# [your_database_name] は実際のデータベース名に置き換えてください
mysqlcheck -u root -p --auto-repair --check --databases [your_database_name]
このコマンドが完了したら、もう一度 mysql_upgrade を実行します。
# 作業サーバー
# 再度アップグレードを実行
mysql_upgrade -u root -p
今度はすべての項目が OK になれば成功です!
⑤ 最終確認とバックアップ (v5.7.x)
最後に、アプリケーションが正常に動作するか、データが正しく参照できるかを念入りに確認します。
問題がなければ、最終版のバックアップを取得して全工程完了です!
# 作業サーバー
# [your_database_name] は実際のデータベース名に置き換えてください
mysqldump -u root -p [your_database_name] > backup_5.7.x.sql
ls
3. Tips: どうしても mysql_upgrade が成功しない時は…
mysqlcheck を実行し、再度 mysql_upgrade を実行してもエラーが解消されない…。
そんな時は、MySQLサーバーの再起動を試してみてください。
# 作業サーバー
service mysqld restart
# または systemctl restart mysqld
アップグレードプロセスによって更新されたテーブル定義などが、サーバーのキャッシュに残った古い情報と競合している場合があります。
サーバーを再起動することで、最新のスキーマ情報がクリーンな状態で読み込まれ、問題が解決することがあります。
まとめ
yumが使えない古いLinux環境でのMySQLバージョンアップは、一見するとハードルが高いですが、手順を一つずつ確実に踏めば必ず乗り越えられます。
- バックアップは命綱。 各ステップの前に必ず取得する。
- RPMのインストール順序は絶対。 依存関係を意識する。
- mysql_upgradeは必須作業。 エラーが出たらmysqlcheckで修復。
- 困ったら再起動。 キャッシュが原因のトラブルも多い。
- 実際に動いている環境では安易にはやらないでください。
この記事が、レガシーシステムと向き合うすべてのエンジニアの力になれれば幸いです。