MariaDB EOLを迎えた本番環境でのバージョン延命と移行計画|apt/yumリポジトリ切替と動作確認

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Linuxtips > データーベース管理 > MariaDB EOLを迎えた本番環境でのバージョン延命と移行計画|apt/yumリポジトリ切替と動作確認
MariaDB の本番サーバーで apt update や dnf update を実行しても、データベースパッケージだけが古いバージョンのまま止まっている——その原因のほとんどは、インストール時に設定したリポジトリが EOL(End of Life、サポート終了)を迎えたバージョンを指したまま変更されていないことです。

EOL 後はセキュリティパッチが提供されなくなるため、脆弱性が判明しても修正が来ません。しかし「アップグレード中にデータが壊れそうで怖い」「どのバージョンへ上げればいいかわからない」と後回しにしているケースは少なくありません。

この記事では、MariaDB の EOL スケジュールを確認する方法から、apt/yum(dnf)リポジトリを新しい LTS 系列へ切り替えてインプレースアップグレードを行う具体的な手順を解説します。Ubuntu 22.04 と Rocky Linux 9 の両環境で動作確認済みです。

この記事のポイント

・MariaDB 10.5 は 2025年6月に EOL 済み
・10.6 LTS は 2026年7月が期限、11.4 LTS が推奨
・apt/dnf リポジトリ切替でインプレースアップグレード可能
・最後に mariadb-upgrade でシステムテーブルを更新する


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜ MariaDB EOL が本番環境で深刻な問題なのか

EOL を迎えた MariaDB を使い続けると、次の3つの問題が顕在化します。

・セキュリティパッチの停止:CVE(共通脆弱性識別番号)が発見されても、公式修正が提供されなくなります。SQL インジェクションや認証バイパスが悪用されるリスクが高まります。
・パッケージ管理の断絶:リポジトリから削除されるため、apt update / dnf update の対象からも外れます。OS のパッケージ更新で依存関係エラーが発生することもあります。
・OS アップグレード時の衝突:Ubuntu 22.04 → 24.04 や Rocky Linux 8 → 9 へ OS を上げる際、EOL バージョンの MariaDB がシステム付属パッケージとコンフリクトして移行がブロックされることがあります。

MariaDB の EOL スケジュールと現在のバージョン確認

1. インストール済みのバージョンを確認する

まずサーバーで動いている MariaDB のバージョンを確認します。

# MariaDB バージョンの確認 mariadb --version # または(MariaDB 10.3 以前の環境) mysql --version # サービスの状態と同時にバージョンを確認する systemctl status mariadb

実際のサーバーで確認した例です(Ubuntu 22.04 / MariaDB 10.6 系)。

$ mariadb --version mariadb Ver 15.1 Distrib 10.6.18-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper $ systemctl status mariadb * mariadb.service - MariaDB 10.6.18 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2026-09-28 02:11:47 JST; 1 weeks 1 days ago Docs: man:mariadbd(8) https://mariadb.com/kb/en/library/systemd/ Main PID: 2031 (mariadbd) Status: "Taking your SQL requests now..." Tasks: 8 (limit: 4915) Memory: 76.2M CPU: 44.921s CGroup: /system.slice/mariadb.service └─2031 /usr/sbin/mariadbd

2. MariaDB の EOL スケジュール一覧

MariaDB Foundation が公表している EOL スケジュールをまとめます(2026年10月時点)。
バージョン系列 EOL 種別 状況
10.5 2025年6月 旧安定版 EOL 済み
10.6 2026年7月 LTS まもなく EOL
10.11 2028年2月 LTS サポート中
11.4 2029年5月 LTS 最新 LTS(推奨)
11.8 2031年(予定) LTS(開発中) 次期 LTS
MariaDB は LTS(Long-Term Support)と短期リリースの2系統に分かれています。本番環境では必ず LTS 系列を選んでください。短期リリース(例: 11.6)は EOL が 1 年以内のものも多く、本番運用には向きません。

新しい LTS 系列を選ぶ際は、既存アプリケーションとの互換性も確認が必要です。10.x → 11.x のメジャージャンプはシステム変数やデフォルト値の変更を伴うため、ステージング環境での動作確認を先に行うことを推奨します。

アップグレード前の準備

1. フルバックアップを取得する

リポジトリ切替とアップグレードの前に、必ずデータのバックアップを取ります。

# 全データベースをダンプ(InnoDB は --single-transaction でロックを避ける) mysqldump -u root -p --all-databases --single-transaction --routines --triggers > /var/backup/mariadb-all-$(date +%Y%m%d).sql # ダンプファイルのサイズを確認 ls -lh /var/backup/mariadb-all-*.sql

--single-transaction は InnoDB テーブルに対して、テーブルロックをかけずにトランザクション整合性を保ったままダンプするオプションです。MyISAM テーブルが混在する場合は --lock-all-tables に切り替えてください。

2. 設定ファイルを退避する

# 設定ファイルの場所はディストリビューションによって異なる(存在するものだけコピー) test -f /etc/my.cnf && sudo cp -a /etc/my.cnf /etc/my.cnf.bak test -d /etc/my.cnf.d/ && sudo cp -a /etc/my.cnf.d/ /etc/my.cnf.d.bak/ test -f /etc/mysql/my.cnf && sudo cp -a /etc/mysql/my.cnf /etc/mysql/my.cnf.bak test -d /etc/mysql/mariadb.conf.d/ && sudo cp -a /etc/mysql/mariadb.conf.d/ /etc/mysql/mariadb.conf.d.bak/

バージョン間でパラメータ名や既定値が変わることがあります。元の設定を退避しておくことで、起動しなくなったときのロールバックが容易になります。

Debian/Ubuntu 系(apt)のリポジトリ切替とアップグレード

1. 現在の MariaDB リポジトリを確認する

# リポジトリファイルの場所を確認 ls /etc/apt/sources.list.d/ | grep -i mariadb ls /etc/apt/keyrings/ | grep -i mariadb

古いセットアップスクリプトで追加した環境では /etc/apt/sources.list.d/mariadb.list にバージョン番号が直書きされています(例: deb ... mariadb-10.6/repo/ubuntu jammy main)。

2. 旧リポジトリを削除し、新しい LTS 系列を登録する

# 旧設定を削除 sudo rm -f /etc/apt/sources.list.d/mariadb.list sudo rm -f /etc/apt/keyrings/mariadb-keyring.pgp # MariaDB 公式セットアップスクリプトで 11.4 LTS を指定して再登録 curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-11.4"

公式の mariadb_repo_setup スクリプトは GPG 鍵の登録と sources.list.d への書き込みを一括で行います。バージョン番号を --mariadb-server-version で明示することで、後からリポジトリが何系列を向いているか一目でわかります。

3. アップグレードを実行する

sudo apt update sudo apt install --only-upgrade mariadb-server # アップグレード後のバージョン確認 mariadb --version

apt install --only-upgrade は既存パッケージのアップグレードのみを行い、未インストールのパッケージは追加しません。apt upgrade でも構いませんが、上記の方が対象を明示できます。

RHEL/Rocky Linux/AlmaLinux 系(dnf/yum)のリポジトリ切替とアップグレード

RHEL/Rocky/AlmaLinux では RPM パッケージとして MariaDB を管理します(RPM パッケージ管理の基本については rpm コマンドの使い方も参考にしてください)。

1. 現在のリポジトリを確認する

# MariaDB リポジトリの一覧を確認 dnf repolist | grep -i mariadb # リポジトリファイルの場所 ls /etc/yum.repos.d/ | grep -i mariadb

2. 旧リポジトリを削除し、新しい LTS 系列を登録する

# 旧リポジトリファイルを削除 sudo rm -f /etc/yum.repos.d/MariaDB.repo # 公式セットアップスクリプトで Rocky Linux 9 向け 11.4 LTS を登録 curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-11.4" --os-type="rhel" --os-version="9" # Rocky Linux 8 の場合は --os-version="8" に変更する

--os-type と --os-version を明示することで、ディストリビューションに対応した RPM リポジトリ URL が自動的に選択されます。

3. dnf でアップグレードを実行する

# キャッシュを更新してから MariaDB をアップグレード sudo dnf makecache sudo dnf upgrade MariaDB-server # アップグレード後のバージョン確認 mariadb --version

dnf のアップグレード後、新しいデフォルト設定が .rpmnew として生成されることがあります。内容を確認して既存設定とマージするかどうか判断してください。

# .rpmnew ファイルが生成されていないか確認 find /etc/my.cnf.d/ -name "*.rpmnew" 2>/dev/null

アップグレード後の動作確認

1. サービスの起動状態を確認する

sudo systemctl start mariadb systemctl status mariadb

アップグレード直後は自動起動しない場合があります。Active: active (running) であることを確認してください。

2. システムテーブルを更新する(mariadb-upgrade)

旧バージョンから移行したとき、MariaDB 内部の mysql データベース(ユーザー権限テーブルなど)のスキーマを新バージョンに合わせて更新する必要があります。

sudo mariadb-upgrade -u root -p

実際の実行例です(Rocky Linux 9 / MariaDB 11.4 へのアップグレード後)。

# sudo mariadb-upgrade -u root -p Enter password: MariaDB upgrade detected Phase 1/7: Checking and upgrading mysql database Processing databases mysql mysql.column_stats OK mysql.columns_priv OK mysql.db OK mysql.global_priv OK mysql.innodb_index_stats OK mysql.innodb_table_stats OK mysql.proc OK mysql.proxies_priv OK mysql.tables_priv OK mysql.transaction_registry OK mysql.user OK Phase 2/7: Installing used storage engines Checking for tables with unknown storage engine Phase 3/7: Running 'mysql_fix_privilege_tables' Phase 4/7: Fixing views Phase 5/7: Fixing table and database names Phase 6/7: Checking and upgrading tables Processing databases information_schema performance_schema Phase 7/7: Running 'FLUSH PRIVILEGES' OK

mariadb-upgrade は冪等なので複数回実行しても問題ありません。古い環境では mysql_upgrade コマンドとして提供されていますが、MariaDB 10.9 以降は mariadb-upgrade が正式コマンドです。

3. バージョンと接続を確認する

mariadb -u root -p -e "SELECT VERSION(); SHOW VARIABLES LIKE 'version%';"

Enter password: +-----------------+ | VERSION() | +-----------------+ | 11.4.4-MariaDB | +-----------------+ +-------------------------+--------------------+ | Variable_name | Value | +-------------------------+--------------------+ | version | 11.4.4-MariaDB | | version_comment | mariadb.org binary | | version_compile_machine | x86_64 | | version_compile_os | Linux | +-------------------------+--------------------+

想定外のバージョンが表示された場合は、PATH に別の mariadb バイナリが混在している可能性があります(which mariadb で確認してください)。その後、アプリケーション(PHP/Python/Java など)からも接続テストを行い、クエリが正常に返ることを確認します。特に utf8mb4 の扱いや STRICT_TRANS_TABLES などの SQL モードはバージョン間で変わっている場合があるため、アプリケーション側のエラーログも確認してください。

EOL 後も延命を余儀なくされる場合の一時対策

どうしてもすぐにアップグレードできない場合、以下の暫定措置を検討してください。ただし、これらはあくまで「移行計画を策定する間の緩和策」です。本番トラフィックを長期間受け続けることは推奨しません。

・ネットワーク隔離:bind-address = 127.0.0.1 でローカルのみに限定するか、firewalld/iptables で 3306 の接続元 IP を信頼できるサーバーだけに絞る。
・データディレクトリを読み取り専用マウントで保護:万一の侵害時にデータが改ざんされにくいように、バックアップ先ボリュームを別マウントで管理する。
・ロールバック手順を事前検証:ダンプからリストアできる手順を文書化し、実際にステージング環境で試しておく。

本番サーバーのデータベース移行計画や体系的な Linux 運用を学びたい方は、Linux Master Pro Seminar もご確認ください。移行の計画立案からロールバック設計まで、実機ハンズオンで体系的に身につけられます。

トラブルシュート

アップグレード後に MariaDB が起動しない場合

ログで原因を特定します。

sudo journalctl -xe -u mariadb --no-pager | tail -60

よくある原因と対処:

・「unknown variable」エラー:バージョンアップで廃止されたパラメータが /etc/my.cnf に残っている。ログで unknown variable 'xxx' を探して該当行をコメントアウトする。
・SELinux のラベル問題(RHEL 系):新バージョンで mariadbd バイナリのパスが変わると SELinux が拒否する。ausearch -c 'mariadbd' --raw | audit2allow でポリシーを生成して適用する。
・データディレクトリの権限エラー:sudo chown -R mysql:mysql /var/lib/mysql で所有者を確認・修正する。

mariadb-upgrade でエラーになる場合

ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded が出た場合は、認証プラグインの切り替わりが原因です。--protocol=tcp で TCP 接続を強制して再実行してください。

# unix_socket を使わずに TCP で接続して実行 sudo mariadb-upgrade -u root -p --protocol=tcp -h 127.0.0.1

アプリケーションから接続できなくなった場合

MariaDB 10.x → 11.x ではデフォルト認証プラグインが ed25519 になる場合があります。既存アプリケーションが mysql_native_password 前提で実装されているときは、ユーザーの認証プラグインを変更してください。

ALTER USER 'appuser'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('your_password'); FLUSH PRIVILEGES;

本記事のまとめ

やりたいこと コマンド・手順
MariaDB バージョン確認 mariadb --version
フルバックアップ取得 mysqldump -u root -p --all-databases --single-transaction > backup.sql
apt リポジトリを 11.4 LTS へ切替 旧 mariadb.list 削除 → 公式スクリプト再登録 → apt install --only-upgrade mariadb-server
dnf リポジトリを 11.4 LTS へ切替(RHEL 系) 旧 MariaDB.repo 削除 → 公式スクリプト再登録 → dnf upgrade MariaDB-server
システムテーブルの更新 sudo mariadb-upgrade -u root -p
起動ログの確認 journalctl -xe -u mariadb

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、

MariaDB のバージョン管理・バックアップ設計・本番移行フローなど、実務で使える Linux サーバー運用のノウハウを体系的に学べる Linux Master Pro Seminar を開催しています。少人数ハンズオン形式で、実機を触りながら「型」として定着させることができます。

>> Linux Master Pro Seminar の詳細を見る

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。