MariaDB 10.6→10.11：ダウンタイムを最小限に抑えるアップグレード方法

2025-05-26

MariaDBのバージョンアップは、データベースの安定性やセキュリティ、新機能の利用のために重要ですが、慎重に進める必要があります。特にメジャーバージョンアップ（例: 10.6から10.11）では、非互換な変更が含まれる可能性があるため、事前の準備と確認が不可欠です。

アップグレード前の準備と確認

ディスクスペースの確認
アップグレードプロセス中に一時ファイルなどが作成される可能性があるため、十分なディスクスペースがあることを確認します。
設定ファイルの確認
my.cnfなどの設定ファイルで、旧バージョンで使っていたオプションが新バージョンで非推奨になったり、削除されたりしていないか確認します。
アプリケーションの互換性確認
MariaDBのバージョンアップが、利用しているアプリケーション（WordPress、PHPアプリケーション、Javaアプリケーションなど）に影響を与えないか確認します。必要であれば、テスト環境でアプリケーションの動作検証を行ってください。
バックアップの取得
最も重要です。現在のMariaDBのデータディレクトリ全体と設定ファイル（my.cnfなど）を完全にバックアップしてください。万が一問題が発生した場合に元に戻せるようにするためです。

基本的なアップグレード手順は以下の通りです。具体的なコマンドはOSやパッケージマネージャーによって異なります。

MariaDBサービスを停止する
アップグレード作業を行う前に、MariaDBサービスを完全に停止します。これにより、データの一貫性が保たれます。
```
sudo systemctl stop mariadb
```
または
```
sudo /etc/init.d/mysql stop
```
既存のMariaDB 10.6をアンインストールする
パッケージマネージャーを使って、既存のMariaDB 10.6のパッケージをアンインストールします。この際、データディレクトリは削除しないように注意してください。通常、パッケージのアンインストールではデータは残りません。
- Debian/Ubuntu系
```
sudo apt-get remove mariadb-server
```
- RHEL/CentOS/Fedora系
```
sudo yum remove MariaDB-server
# または
sudo dnf remove MariaDB-server
```
MariaDB 10.11をインストールする
新しいリポジトリが設定されたら、MariaDB 10.11のパッケージをインストールします。
- Debian/Ubuntu系
```
sudo apt-get update
sudo apt-get install mariadb-server
```
- RHEL/CentOS/Fedora系
```
sudo yum install MariaDB-server
# または
sudo dnf install MariaDB-server
```
設定ファイル（my.cnf）の調整
新しいバージョンのMariaDBをインストールすると、デフォルトの設定ファイルが配置されることがあります。旧バージョンで使用していたカスタム設定を新しい設定ファイルに適用したり、非推奨になったオプションを削除したりします。
- 旧バージョンのmy.cnfと新バージョンのmy.cnfを比較し、必要な変更を反映させます。
- 特に、文字セットやストレージエンジンに関する設定は、動作に影響を与える可能性があるため注意深く確認してください。
MariaDBサービスを起動する
新しいバージョンのMariaDBを起動します。
```
sudo systemctl start mariadb
```
```
sudo /etc/init.d/mysql start
```
mariadb-upgradeを実行する
MariaDBサーバーの起動後、必ずmariadb-upgradeコマンドを実行してください。このツールは以下の2つの重要な作業を行います。
- mysqlデータベース内のシステムテーブルを新しいバージョンと互換性があるように更新します。
- 既存のすべてのテーブルをチェックし、新しいバージョンのMariaDBと互換性があることをマークします。

```
sudo mariadb-upgrade -u root -p
```
（パスワードを求められたら入力します。）
アップグレードの確認
MariaDBに接続し、バージョンが10.11になっていることを確認します。
```
mysql -V
# または
mysql -u root -p
SELECT VERSION();
```
また、アプリケーションが正常に動作するか、テスト環境で thoroughly に確認します。

トラブルシューティングと注意点

Galera Clusterの場合
Galera Clusterを使用している場合は、ローリングアップグレードの手順が少し異なります。クラスタ内の各ノードを個別にアップグレードし、クラスタ全体のダウンタイムを避けるための特別な考慮が必要です。公式ドキュメントの「Upgrading from MariaDB 10.6 to MariaDB 10.11 with Galera Cluster」を参照してください。
異なるOS間の移行
OSをまたいでのMariaDBのアップグレードは、上記の手順に加えてデータのエクスポート/インポートが必要になる場合があります。
ログファイルの確認
問題が発生した場合は、MariaDBのエラーログファイル（通常は/var/log/mysql/error.logや/var/log/mariadb/mariadb.logなど）を確認してください。問題解決の手がかりが得られます。
競合するパッケージ
アップグレード中に、既存のパッケージとの競合エラーが発生する場合があります。その際は、エラーメッセージをよく読み、指示に従って競合するパッケージを解決してください。
GPGキーエラー
リポジトリの追加や更新時にGPGキーに関するエラーが発生することがあります。MariaDBの公式ドキュメントに従って、正しいキーを追加してください。

MariaDBのメジャーバージョンアップは、通常はスムーズに進むように設計されていますが、環境や既存の設定によっては予期せぬ問題が発生することがあります。以下に、よくあるエラーとその対処法を挙げます。

MariaDBサービスが起動しない/起動に失敗する

アップグレード後、MariaDBサービスが正常に起動しないのは最もよくある問題です。

考えられる原因とトラブルシューティング

InnoDBのRedoログ互換性
稀に、InnoDBのredoログファイルが新しいバージョンと互換性がなく、起動に失敗することがあります。特に、クリーンシャットダウンせずにアップグレードした際に発生しやすいです。
- エラーメッセージ例
  [ERROR] InnoDB: Upgrade after a crash is not supported.
- 対処法
  通常はMariaDBのクリーンシャットダウンが必要ですが、既にアップグレードプロセス中にエラーが発生している場合は、以下の手順を試す場合があります（データの破損リスクがあるため、必ずバックアップ後に実施してください）。
  1. MariaDBサービスを停止します。
  2. データディレクトリ内のib_logfile*（redoログファイル）を別の場所に移動または削除します。
  3. MariaDBサービスを再起動します。新しいredoログファイルが自動的に作成されます。
  4. mariadb-upgradeを実行します。
mariadb-upgradeの未実行または失敗
アップグレード後にmariadb-upgradeを実行しないと、システムテーブルが新バージョンと互換性がないままになり、起動しないことがあります。
- 対処法
  MariaDBサービスが起動していることを確認し、mariadb-upgrade -u root -pを実行します。もしサービスが起動しない場合は、--skip-grant-tablesオプションを付けて一時的にMariaDBを起動し、その状態でmariadb-upgradeを実行してから、通常通り再起動します。
```
# 一時的にサービスを起動 (セキュリティリスクがあるため、完了後はすぐに通常停止)
sudo mysqld_safe --skip-grant-tables &
# mariadb-upgradeを実行
mariadb-upgrade -u root -p
# サービスの停止
sudo mysqladmin shutdown -u root -p
# 通常起動
sudo systemctl start mariadb
```
データディレクトリのパーミッション問題
MariaDBのデータディレクトリ（通常は/var/lib/mysql）の所有者やパーミッションが正しくない場合、データベースファイルへのアクセスができずに起動に失敗します。
- 対処法
  データディレクトリとその中身がmysqlユーザー（またはmariadbユーザーなど、システムによって異なる）とmysqlグループ（またはmariadbグループ）に所有されていることを確認し、適切なパーミッション（通常は700や755など）が設定されていることを確認します。
```
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod -R 700 /var/lib/mysql # 必要に応じて
```
- 非推奨/削除されたオプション
  MariaDB 10.11 では、10.6で使用されていた一部のオプションが非推奨になったり、削除されたりしています。これらのオプションがmy.cnfに残っていると、サービスが起動しません。
  - 対処法
    MariaDBのエラーログ (/var/log/mysql/error.log や /var/log/mariadb/mariadb.log など) を確認し、「unknown option」や「deprecated option」といったメッセージがないか探します。該当するオプションがあれば、my.cnfから削除するか、新しい同等のオプションに置き換えます。
  - 特に、InnoDBの圧縮に関するオプション（innodb_log_write_ahead_size など）や、古いGalera Cluster関連のオプション（wsrep_replicate_myisam など）が変更されている可能性があります。
- 不正な構文/パス
  設定ファイルに誤字脱字があったり、指定されたパスが存在しなかったりする場合も起動に失敗します。
  - 対処法
    my.cnfの構文を慎重に確認します。

mariadb-upgradeが失敗する

mariadb-upgradeコマンド自体がエラーで終了する場合があります。

考えられる原因とトラブルシューティング

破損したシステムテーブル
稀に、mysqlデータベース内のシステムテーブルが破損していることがあります。
- 対処法
  バックアップからリストアするか、非常に注意して手動で修復を試みる必要がありますが、これは上級者向けです。
MariaDBサーバーが起動していない
mariadb-upgradeは、起動中のMariaDBサーバーに接続して処理を行うため、サーバーが停止していると実行できません。
- 対処法
  MariaDBサービスが起動していることを確認してから実行します。
権限不足
mariadb-upgradeを実行するユーザーに十分な権限がない。
- 対処法
  rootユーザーで実行するか、mysqlデータベースに対する適切な権限を持つユーザーで実行します。

パッケージ管理システムのエラー

アップグレード中にパッケージの競合や依存関係の問題が発生することがあります。

考えられる原因とトラブルシューティング

パッケージの競合
既存のMariaDBまたはMySQLのパッケージと新しいMariaDB 10.11パッケージが競合する。
- 対処法
  公式のアップグレード手順に従い、旧バージョンのパッケージをアンインストールしてから新バージョンをインストールします。アンインストール時にデータディレクトリが削除されないよう注意してください。
  - Debian/Ubuntu系
    sudo apt-get remove mariadb-server
  - RHEL/CentOS系
    sudo yum remove MariaDB-server または sudo dnf remove MariaDB-server
リポジトリの誤設定
誤ったMariaDBリポジトリが設定されている、または複数のMariaDB/MySQLリポジトリが競合している。
- 対処法
  /etc/apt/sources.list.d/ (Debian/Ubuntu) や /etc/yum.repos.d/ (RHEL/CentOS) 内のMariaDB関連のリポジトリ設定ファイルをレビューし、MariaDB 10.11の公式リポジトリのみが正しく設定されていることを確認します。古いバージョンのリポジトリはコメントアウトするか削除します。

アプリケーションの互換性問題

MariaDBサーバー自体のアップグレードは成功しても、それを利用するアプリケーションが正常に動作しなくなることがあります。

考えられる原因とトラブルシューティング

コネクタ/ドライバの非互換性
アプリケーションが使用しているデータベースコネクタやドライバが、新しいMariaDBバージョンに対応していない。
- 対処法
  アプリケーションのプログラミング言語（PHP, Python, Javaなど）に応じた最新のデータベースコネクタ/ドライバにアップデートします。
デフォルト値の変更
sql_modeなどのシステム変数や、文字セットのデフォルト値が変更された。
- 対処法
  my.cnfで旧バージョンと同じsql_modeを設定したり、必要に応じてcharacter_set_serverなどの設定を明示的に指定したりします。
SQL構文の変更/非推奨
MariaDB 10.11で非推奨になったSQL構文や、動作が変更された機能を使用している。
- 対処法
  MariaDB 10.6と10.11の間の非互換な変更点を公式ドキュメントで確認し、アプリケーションのコードを修正します。特にトリガー、ストアドプロシージャ、ビューなどに影響が出ることがあります。

パフォーマンスの低下

アップグレード後、データベースのパフォーマンスが以前より遅くなる場合があります。

考えられる原因とトラブルシューティング

テーブルの再構築が必要な場合
稀に、旧バージョンで作成されたテーブルが新バージョンで最適なパフォーマンスを発揮しないことがあります。
- 対処法
  OPTIMIZE TABLEコマンドや、テーブルをダンプ・リストアすることで、物理的な構造を最適化できる場合があります。
設定の最適化不足
新しいバージョンに合わせたmy.cnfのチューニングが不足している。
- 対処法
  10.11の推奨設定や、お使いのサーバーのスペック（メモリ、CPUなど）に合わせてinnodb_buffer_pool_sizeなどのパラメータを調整します。
オプティマイザの変更
MariaDBのクエリ最適化ロジックが変更され、特定のクエリの実行計画が変わった。
- 対処法
  EXPLAINを使って問題のあるクエリの実行計画を分析し、必要に応じてインデックスの見直しやクエリの書き換えを検討します。optimizer_switchシステム変数でオプティマイザの挙動を調整できる場合があります。

トラブルシューティングの一般的なヒント

バックアップは常に手元に
何か問題が発生した場合に、すぐに元に戻せるように、アップグレード前には完全なバックアップを取得しておくことが絶対条件です。
テスト環境で事前に検証する
本番環境でアップグレードを行う前に、必ずテスト環境で十分なテストと検証を行ってください。
公式ドキュメントを参照する
MariaDBの公式ナレッジベース (mariadb.com/kb) には、各バージョンのアップグレードガイドや非互換な変更点が詳細に記載されています。
ログを徹底的に確認する
MariaDBのエラーログ (/var/log/mysql/error.log など) は、問題解決のための最も重要な情報源です。起動失敗時やエラー発生時は必ず確認してください。

直接的な「プログラミングコード」というよりは、システム管理の自動化スクリプトや、データベース操作のスクリプトとして捉えるのが適切です。

以下に、アップグレードプロセスで役立つ可能性のあるコード例をいくつか示します。

アップグレード前後のバックアップスクリプト（シェルスクリプト）

アップグレード作業において、バックアップは最も重要です。これは、万が一の事態に備えてデータベースを元の状態に戻せるようにするためです。

#!/bin/bash

# 日付形式の定義 (バックアップファイル名に使用)
DATE_FORMAT=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR="/var/backups/mariadb_pre_upgrade_${DATE_FORMAT}"
MARIADB_USER="root" # バックアップ用のMariaDBユーザー
MARIADB_PASSWORD="your_mariadb_root_password" # MariaDBユーザーのパスワード

echo "MariaDBアップグレード前バックアップを開始します..."

# バックアップディレクトリの作成
mkdir -p "$BACKUP_DIR"
if [ $? -ne 0 ]; then
    echo "エラー: バックアップディレクトリ $BACKUP_DIR の作成に失敗しました。"
    exit 1
fi

echo "データディレクトリのフルバックアップ: /var/lib/mysql を $BACKUP_DIR/data にコピーします..."
sudo cp -a /var/lib/mysql "$BACKUP_DIR/data"
if [ $? -ne 0 ]; then
    echo "エラー: データディレクトリのコピーに失敗しました。"
    # エラーログの確認を促す
    echo "ログファイルやパーミッションを確認してください。"
    exit 1
fi

echo "MariaDB設定ファイル: /etc/my.cnf を $BACKUP_DIR にコピーします..."
sudo cp /etc/my.cnf "$BACKUP_DIR/"
if [ $? -ne 0 ]; then
    echo "警告: /etc/my.cnf のコピーに失敗しました。パーミッションを確認してください。"
fi

# my.cnf.d ディレクトリがあれば、その内容もコピー
if [ -d "/etc/my.cnf.d" ]; then
    echo "MariaDB設定ディレクトリ: /etc/my.cnf.d を $BACKUP_DIR にコピーします..."
    sudo cp -a /etc/my.cnf.d "$BACKUP_DIR/"
    if [ $? -ne 0 ]; then
        echo "警告: /etc/my.cnf.d のコピーに失敗しました。パーミッションを確認してください。"
    fi
fi

echo "mysqldump を使用して全データベースを論理バックアップします..."
mysqldump -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" --all-databases --events --routines --triggers > "$BACKUP_DIR/all_databases.sql"
if [ $? -ne 0 ]; then
    echo "エラー: mysqldump による論理バックアップに失敗しました。"
    echo "MariaDBユーザーの認証情報と権限を確認してください。"
    exit 1
fi

echo "バックアップが $BACKUP_DIR に正常に完了しました。"
echo "バックアップを安全な場所に保管してください。"

スクリプトの説明

mysqldump ...: 論理バックアップ（SQLファイル）を作成します。これは、データベース内のデータだけでなく、スキーマ、ビュー、ストアドプロシージャ、トリガー、イベントなども含みます。リストアが容易な形式です。
sudo cp /etc/my.cnf ...: 設定ファイルも必ずバックアップします。
sudo cp -a /var/lib/mysql "$BACKUP_DIR/data": MariaDBのデータディレクトリ全体を物理的にコピーします。これは最も確実なバックアップ方法の一つです。sudoが必要です。
BACKUP_DIR: バックアップを保存するディレクトリ。
DATE_FORMAT: バックアップディレクトリ名にタイムスタンプを付与します。

MariaDBサービス制御とmariadb-upgrade実行スクリプト（シェルスクリプト）

アップグレードの主要なステップを自動化するスクリプトの例です。

#!/bin/bash

echo "MariaDB 10.6 から 10.11 へのアップグレード手順を開始します。"

# 1. MariaDBサービスの停止
echo "MariaDBサービスを停止します..."
sudo systemctl stop mariadb
if [ $? -ne 0 ]; then
    echo "エラー: MariaDBサービスの停止に失敗しました。手動で確認してください。"
    exit 1
fi
echo "MariaDBサービス停止完了。"

# 2. (Debian/Ubuntuの例) 旧バージョンのアンインストールと新バージョンのインストール
# 注: この部分はOSによって異なります。
# RHEL/CentOSの場合は yum/dnf を使用します。
echo "旧バージョンのMariaDBをアンインストールし、新バージョンをインストールします..."
echo "これはシステムのリポジトリ設定に依存します。"
echo "新しいリポジトリ設定が完了していることを前提とします。"

# 既存のmariadb-serverパッケージを削除 (データは残す)
# このコマンドはMariaDBのバージョンやパッケージ名によって調整が必要な場合があります
sudo apt-get remove --purge mariadb-server mariadb-client -y # --purge は設定ファイルも消すので注意
# もしデータディレクトリも削除したい場合は、rm -rf /var/lib/mysql を追加しますが、通常は推奨されません。

# MariaDB 10.11 のリポジトリが正しく設定されていることを確認してから実行
sudo apt-get update
sudo apt-get install mariadb-server mariadb-client -y

if [ $? -ne 0 ]; then
    echo "エラー: MariaDBパッケージのインストールに失敗しました。リポジトリ設定やエラーログを確認してください。"
    exit 1
fi
echo "MariaDB 10.11 のインストール完了。"

# 3. 設定ファイル (my.cnf) の確認と調整
# ここでは自動化は難しいので、手動での確認を促すメッセージにとどめます。
echo "重要: /etc/my.cnf および /etc/my.cnf.d/ の設定ファイルを確認し、"
echo "MariaDB 10.11 との互換性がないオプションを削除または修正してください。"
echo "特に、旧バージョンで使っていたカスタム設定が正しく引き継がれているか確認してください。"
read -p "設定ファイルの確認が完了したらEnterキーを押してください..."

# 4. MariaDBサービスの起動
echo "MariaDBサービスを起動します..."
sudo systemctl start mariadb
if [ $? -ne 0 ]; then
    echo "エラー: MariaDBサービスの起動に失敗しました。エラーログを確認してください。"
    exit 1
fi
echo "MariaDBサービス起動完了。"

# 5. mariadb-upgrade の実行
echo "mariadb-upgrade を実行して、システムテーブルを更新し、既存のテーブルをチェックします..."
MARIADB_ROOT_PASSWORD="your_mariadb_root_password" # MariaDBのrootパスワード
sudo mariadb-upgrade -u root -p"$MARIADB_ROOT_PASSWORD"
if [ $? -ne 0 ]; then
    echo "エラー: mariadb-upgrade の実行に失敗しました。MariaDBサーバーの起動状態やパスワードを確認してください。"
    exit 1
fi
echo "mariadb-upgrade 完了。"

# 6. アップグレードの確認
echo "MariaDBのバージョンを確認します..."
mysql -V
echo "MariaDBに接続してバージョンを確認します: SELECT VERSION();"
mysql -u root -p"$MARIADB_ROOT_PASSWORD" -e "SELECT VERSION();"

echo "MariaDB 10.6 から 10.11 へのアップグレード手順が完了しました。"
echo "アプリケーションが正常に動作するか、 thoroughly にテストしてください。"

スクリプトの説明

mariadb-upgradeは、システムテーブルの更新と既存テーブルのチェック・修復を行う必須のステップです。
my.cnfの変更は自動化が難しいため、ユーザーに手動での確認を促しています。
重要な注意点
パッケージのアンインストール・インストール部分はOSのパッケージマネージャー（apt、yum、dnfなど）に強く依存します。上記は一例であり、ご自身のOS環境に合わせて適宜修正が必要です。特に--purgeオプションは設定ファイルも削除するので、既存のカスタム設定を失う可能性があります。通常はremoveのみで十分です。
このスクリプトは、一般的なLinuxディストリビューション（Debian/Ubuntuを想定）でのMariaDBアップグレードの基本的な流れを自動化しようとするものです。

アップグレード後のデータベース確認用SQLクエリ

アップグレードが成功したか、およびデータベースの状態を確認するためのSQLクエリ例です。

-- MariaDBサーバーのバージョンを確認
SELECT VERSION();

-- 各データベースの文字セットと照合順序を確認
SELECT
    schema_name AS 'Database',
    default_character_set_name AS 'Default Character Set',
    default_collation_name AS 'Default Collation'
FROM
    information_schema.schemata;

-- 各テーブルのストレージエンジンと行フォーマットを確認
-- 特にInnoDB以外のエンジンを使用している場合、互換性を確認
SELECT
    table_schema AS 'Database',
    table_name AS 'Table',
    engine AS 'Storage Engine',
    row_format AS 'Row Format'
FROM
    information_schema.tables
WHERE
    table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY
    table_schema, table_name;

-- 既存のシステム変数の確認
-- 10.6から10.11でデフォルト値が変更された可能性のあるものを確認
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';
SHOW VARIABLES LIKE 'max_connections';
-- その他の重要なシステム変数も確認

-- イベントスケジューラが有効になっているか確認 (必要な場合)
SHOW VARIABLES LIKE 'event_scheduler';

-- サーバーのステータスを確認
SHOW GLOBAL STATUS LIKE 'Uptime';
SHOW GLOBAL STATUS LIKE 'Connections';
SHOW GLOBAL STATUS LIKE 'Threads_connected';

-- 権限テーブルの確認（mariadb-upgradeが正しく実行されたか）
-- 特に問題が無ければ表示は必要ないが、デバッグ目的
SELECT Host, User, Select_priv, Insert_priv, Update_priv, Delete_priv FROM mysql.user;

SHOW GLOBAL STATUS LIKE ...: サーバーが正常に稼働しているか、基本的な接続状況などを確認します。
SHOW VARIABLES LIKE ...: 重要なシステム変数の値を確認します。MariaDBのメジャーバージョンアップでは、一部のシステム変数のデフォルト値が変更されることがあります。これによりアプリケーションの動作に影響が出る場合があるため、以前のバージョンと同じ値を維持したい場合はmy.cnfで明示的に設定する必要があります。
information_schemaデータベースを利用して、データベースやテーブルのメタ情報を確認します。特に文字セットやストレージエンジンは互換性に影響を与える可能性があります。
SELECT VERSION();: MariaDBのバージョンが目的の10.11になっているか確認する最も基本的なクエリです。

論理バックアップとリストアによるアップグレード (Logical Dump and Restore)

これは、最も安全かつ柔軟なアップグレード方法の一つです。既存のデータベースからデータを論理バックアップ（SQLダンプ）として抽出し、新しくインストールされたMariaDB 10.11インスタンスにそのデータをリストアします。

プログラミング要素

新しいMariaDB 10.11サーバーへのデータインポート
新しくクリーンインストールされたMariaDB 10.11サーバーに対して、エクスポートしたSQLファイルをインポートします。

#!/bin/bash

# 論理バックアップのリストアスクリプト
# 新しくインストールされたMariaDB 10.11サーバーで実行

BACKUP_FILE="/path/to/your/mariadb_full_dump_YYYYMMDD-HHMMSS.sql" # 正しいパスを指定
MARIADB_USER="root"
MARIADB_PASSWORD="your_mariadb_root_password"

echo "MariaDB 10.11 へのデータインポートを開始します..."

# MariaDB サービスが起動していることを確認
sudo systemctl status mariadb > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "エラー: MariaDB サービスが起動していません。起動してください。"
    exit 1
fi

# SQLファイルのインポート
mysql -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" < "$BACKUP_FILE"

if [ $? -ne 0 ]; then
    echo "エラー: データインポートに失敗しました。"
    exit 1
fi
echo "データインポートが正常に完了しました。"

# mariadb-upgradeの実行は不要な場合が多いですが、念のため実行しても安全です。
# 論理インポートでは通常必要ありませんが、システムテーブルの最終確認として実行するDBAもいます。
# sudo mariadb-upgrade -u "$MARIADB_USER" -p"$MARIADB_PASSWORD"

mysqldump / mariadb-dump を使用したデータエクスポート
これはSQLスクリプトを生成するツールで、すべてのデータベース、テーブル構造、データ、プロシージャ、ファンクション、トリガー、イベントなどをSQLステートメントの形式で出力します。

#!/bin/bash

# 論理バックアップスクリプト
# アップグレード前のMariaDB 10.6サーバーで実行

DATE_FORMAT=$(date +%Y%m%d-%H%M%S)
BACKUP_FILE="/var/backups/mariadb_full_dump_${DATE_FORMAT}.sql"
MARIADB_USER="root"
MARIADB_PASSWORD="your_mariadb_root_password"

echo "全データベースの論理バックアップを開始します..."
mysqldump -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" \
          --all-databases \
          --events --routines --triggers \
          --single-transaction \
          --set-gtid-purged=OFF \
          > "$BACKUP_FILE"

if [ $? -ne 0 ]; then
    echo "エラー: mysqldump に失敗しました。"
    exit 1
fi
echo "バックアップファイル: $BACKUP_FILE が作成されました。"

# 必要であれば、ファイル圧縮
# gzip "$BACKUP_FILE"

利点

異なるOS/ハードウェアへの移行
OSやハードウェアが異なる場合でも、この方法で移行が可能です。
スキーマの最適化
インポート時に、新バージョンのデフォルト設定（例: 文字セット、行フォーマット）が適用されるため、古いテーブル定義が自動的に最適化される可能性があります。
クリーンな環境
新しいMariaDB 10.11インスタンスはクリーンな状態で構築され、設定ファイルも新バージョンのデフォルトから開始できます。
高い安全性
旧バージョン環境を完全に温存したままアップグレードできるため、問題発生時のロールバックが非常に容易です。

欠点

ディスクスペース
バックアップファイルのため、十分なディスクスペースが必要です。
ダウンタイム
大規模なデータベースでは、エクスポートとインポートに時間がかかり、その間データベースが利用できなくなるダウンタイムが長くなる可能性があります。

MariaDB Galera Clusterのローリングアップグレード

MariaDB Galera Clusterを使用している場合、クラスタ全体を停止することなく、ノードを1つずつアップグレードしていく「ローリングアップグレード」が可能です。これにより、ダウンタイムを最小限に抑えることができます。

プログラミング要素

各ノードのアップグレードは基本的に前述の「インプレースアップグレード」のプロセスに従いますが、クラスタの整合性を保つための追加の手順と、それを自動化するスクリプトが必要になります。

#!/bin/bash

# Galera Cluster ローリングアップグレードスクリプト (ノードN用)
# このスクリプトは各ノードで個別かつ順番に実行する必要があります。

# 環境変数
NODE_ID="node1" # 現在のノード識別子 (例: node1, node2, node3)
MARIADB_USER="root"
MARIADB_PASSWORD="your_mariadb_root_password"

echo "${NODE_ID}: Galera Clusterアップグレード手順を開始します。"

# 1. ロードバランサーからのノード切り離し (該当する場合)
echo "${NODE_ID}: ロードバランサーからノードを切り離します（手動またはプロキシ設定で）。"
# 例: HAProxy, MaxScale などのプロキシの設定を更新するコマンド
# この部分は環境に依存するため、手動またはプロキシAPI経由で実行します。
read -p "${NODE_ID}: ロードバランサーからの切り離しが完了したらEnterキーを押してください..."

# 2. MariaDBサービスの停止 (wsrep_on=OFFで停止)
# 注意: GaleraのWSREPプロバイダーがオフになっていることを確認し、クリーンシャットダウン
echo "${NODE_ID}: MariaDBサービスを停止します..."
# サービス停止前に、Galeraの状態がQuorum状態であることを確認 (SHOW STATUS LIKE 'wsrep_local_state_comment'; が Synced になっていること)
sudo systemctl stop mariadb
if [ $? -ne 0 ]; then
    echo "エラー: ${NODE_ID} のMariaDBサービスの停止に失敗しました。"
    exit 1
fi
echo "${NODE_ID}: MariaDBサービス停止完了。"

# 3. 旧バージョンのMariaDBアンインストールと新バージョンのMariaDB 10.11インストール
echo "${NODE_ID}: 旧MariaDBパッケージをアンインストールし、新パッケージをインストールします..."
# OS依存のパッケージコマンド (例: apt-get remove, apt-get install)
# 前述のインプレースアップグレードのセクションを参照し、コマンドを適用
# 例: sudo apt-get remove mariadb-server galera-4 -y
# 例: sudo apt-get update && sudo apt-get install mariadb-server galera-4 -y

if [ $? -ne 0 ]; then
    echo "エラー: ${NODE_ID} のMariaDBパッケージのインストールに失敗しました。"
    exit 1
fi
echo "${NODE_ID}: MariaDB 10.11 のインストール完了。"

# 4. my.cnf の調整
echo "重要: ${NODE_ID} の my.cnf 設定を確認し、10.11との互換性を確保してください。"
echo "特に wsrep_provider_options の gcache.size などが適切か確認してください。"
read -p "${NODE_ID}: 設定ファイルの確認が完了したらEnterキーを押してください..."

# 5. MariaDBサービスの起動 (wsrep_on=OFF で起動)
# まずはwsrep_on=OFFで起動し、mariadb-upgradeを実行
echo "${NODE_ID}: MariaDBサービスを wsrep_on=OFF で起動します..."
# 通常のsystemctl start mariadbでは wsrep_on=ON になるため、一時的に設定を変更するか、
# MariaDBの起動オプションで --wsrep-on=OFF を指定する方法も考えられます。
# または、my.cnfで一時的に wsrep_on=OFF に設定し、起動後に mariadb-upgrade を実行、
# その後 wsrep_on=ON に戻して再起動する。
sudo systemctl start mariadb
# あるいは、より厳密な方法:
# (一時的に my.cnf を編集するか、起動コマンドでオプションを渡す)
# sudo mysqld_safe --wsrep_on=OFF --skip-grant-tables & # デバッグ目的の場合
# sudo systemctl start mariadb

sleep 10 # 起動を待つ

if [ $? -ne 0 ]; then
    echo "エラー: ${NODE_ID} のMariaDBサービスの起動に失敗しました（wsrep_on=OFF）。エラーログを確認してください。"
    exit 1
fi
echo "${NODE_ID}: MariaDBサービス起動完了（wsrep_on=OFF）。"

# 6. mariadb-upgrade の実行
echo "${NODE_ID}: mariadb-upgrade を実行します..."
# ここで --skip-write-binlog オプションを使うことも推奨される
sudo mariadb-upgrade -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" --skip-write-binlog
if [ $? -ne 0 ]; then
    echo "エラー: ${NODE_ID} の mariadb-upgrade の実行に失敗しました。"
    exit 1
fi
echo "${NODE_ID}: mariadb-upgrade 完了。"

# 7. MariaDBサービスの再起動 (wsrep_on=ON に戻してクラスタに再参加)
echo "${NODE_ID}: MariaDBサービスを再起動し、クラスタに再参加させます..."
sudo systemctl restart mariadb
if [ $? -ne 0 ]; then
    echo "エラー: ${NODE_ID} のMariaDBサービスの再起動に失敗しました（wsrep_on=ON）。"
    exit 1
fi

# クラスタへの同期完了を待つ (wsrep_local_state_comment が Synced になるまで待機)
echo "${NODE_ID}: クラスタの同期完了を待機しています..."
while true; do
    STATE=$(mysql -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" -N -e "SHOW STATUS LIKE 'wsrep_local_state_comment';" | awk '{print $2}')
    if [ "$STATE" == "Synced" ]; then
        echo "${NODE_ID}: クラスタに同期されました。"
        break
    else
        echo "${NODE_ID}: 現在の状態: $STATE - 同期を待機中..."
        sleep 30
    fi
done

# 8. ロードバランサーへのノード復帰 (該当する場合)
echo "${NODE_ID}: ロードバランサーへノードを復帰させます（手動またはプロキシ設定で）。"
read -p "${NODE_ID}: ロードバランサーへの復帰が完了したらEnterキーを押してください..."

echo "${NODE_ID}: アップグレード手順が完了しました。次のノードに進んでください。"

利点

高い可用性
アップグレード中に他のノードがサービスを提供し続けるため、可用性が維持されます。
最小限のダウンタイム
クラスタ全体を停止することなくアップグレードできるため、サービスの継続性が保たれます。

欠点

バージョン互換性
新旧バージョンのMariaDB Galera Clusterが一時的に混在することになるため、レプリケーションの互換性に注意が必要です。MariaDBの公式ドキュメントでGalera Clusterのバージョン互換性を確認してください。
複雑性
通常のインプレースアップグレードよりも手順が複雑で、Galera Clusterの仕組みを理解している必要があります。

コンテナ化された環境（Docker/Kubernetes）でのアップグレード

MariaDBをDockerコンテナやKubernetesで運用している場合、アップグレード戦略はホストOSへの直接インストールとは異なります。

プログラミング要素

データボリュームの永続化と管理
コンテナを再作成してもデータが失われないよう、データボリュームを適切に管理することが最も重要です。

# Dockerの場合のアップグレード手順例
# 1. 既存コンテナの停止
docker-compose down

# 2. データボリュームのバックアップ (重要!)
# データボリュームをホストマシン上の別の場所にコピー
# docker inspect でデータボリュームのパスを確認: docker inspect <volume_name>
# 例: sudo cp -a /var/lib/docker/volumes/my_app_db_data/_data /path/to/backup_location

# 3. docker-compose.yml のイメージバージョンを 10.11 に更新

# 4. 新しいコンテナの起動 (既存のデータボリュームを使用)
# MARIADB_AUTO_UPGRADE=1 が設定されている場合、ここで自動アップグレードが試行されます。
docker-compose up -d

# 5. mariadb-upgrade の手動実行 (MARIADB_AUTO_UPGRADE がない場合や失敗した場合)
# コンテナ内で直接 mariadb-upgrade を実行
docker exec -it my-mariadb mariadb-upgrade -u root -p

Docker Compose / Kubernetes YAML の更新
docker-compose.yml や Kubernetes の Deployment/StatefulSet YAML ファイル内で、MariaDBイメージのバージョンタグを変更します。

# Docker Compose の例 (docker-compose.yml)
version: '3.8'
services:
  db:
    image: mariadb:10.11 # ここを 10.6 から 10.11 に変更
    container_name: my-mariadb
    environment:
      MARIADB_ROOT_PASSWORD: mysecretpassword
      # MariaDB公式イメージには MARIADB_AUTO_UPGRADE オプションが提供される場合がある
      # MARIADB_AUTO_UPGRADE: "1" # これを有効にすると、起動時に自動で mariadb-upgrade を実行してくれる
    volumes:
      - db_data:/var/lib/mysql # 永続化されたデータボリューム
    ports:
      - "3306:3306"
volumes:
  db_data:

利点

自動化しやすい
CI/CDパイプラインに組み込みやすく、テスト環境での反復検証が容易です。
容易なロールバック
データボリュームのバックアップさえあれば、旧バージョンのイメージを使って簡単に元の状態に戻せます。
環境の分離と再現性
コンテナによってデータベース環境が分離されるため、アップグレードの影響が他のシステムに波及しにくいです。

欠点

mariadb-upgradeの実行
公式イメージによっては自動でmariadb-upgradeを実行する機能がありますが、そうでない場合は手動でコンテナ内に入って実行する必要があります。
データボリューム管理
データボリュームの管理を誤ると、データ損失のリスクがあります。

クラウドマネージドデータベースサービスでのアップグレード

AWS RDS for MariaDB, Azure Database for MariaDB, Google Cloud SQL for MariaDBなどのマネージドサービスを利用している場合、アップグレードプロセスはプロバイダーが提供するコンソールやAPIを通じて行われます。

プログラミング要素

クラウドプロバイダーのCLI/SDKを使った操作
Terraform、AnsibleなどのInfrastructure as Code (IaC) ツールや、AWS CLI、Azure CLI、gcloud CLIなどのコマンドラインインターフェース、または各プロバイダーのSDK（Python boto3, Java SDKなど）を使ってアップグレード操作を自動化できます。

# AWS CLI の例 (AWS RDS for MariaDB)
# 1. DBインスタンスの識別子とアップグレードターゲットバージョンを指定
DB_INSTANCE_IDENTIFIER="my-mariadb-instance"
TARGET_ENGINE_VERSION="10.11.x" # 正しいターゲットバージョンを指定

echo "AWS RDS MariaDBインスタンス ${DB_INSTANCE_IDENTIFIER} のアップグレードを開始します..."

# 2. (推奨) 事前にスナップショットを取得 (バックアップ)
echo "アップグレード前にDBスナップショットを作成します..."
aws rds create-db-snapshot \
  --db-instance-identifier "$DB_INSTANCE_IDENTIFIER" \
  --db-snapshot-identifier "${DB_INSTANCE_IDENTIFIER}-pre-10-11-upgrade"
echo "スナップショット作成リクエストが送信されました。完了を待機してください。"

# 3. メジャーバージョンアップグレードの実行 (メンテナンスウィンドウで適用される)
echo "DBインスタンスのメジャーバージョンアップグレードをリクエストします..."
aws rds modify-db-instance \
  --db-instance-identifier "$DB_INSTANCE_IDENTIFIER" \
  --engine-version "$TARGET_ENGINE_VERSION" \
  --allow-major-version-upgrade \
  --apply-immediately # または --no-apply-immediately で次回のメンテナンスウィンドウに適用

if [ $? -ne 0 ]; then
    echo "エラー: RDS DBインスタンスのアップグレードリクエストに失敗しました。"
    exit 1
fi
echo "アップグレードリクエストが正常に送信されました。DBインスタンスの状態を監視してください。"

# 4. アップグレード完了の確認 (aws rds describe-db-instances で確認)
echo "DBインスタンスの状態を監視しています..."
aws rds wait db-instance-available --db-instance-identifier "$DB_INSTANCE_IDENTIFIER"
echo "DBインスタンス ${DB_INSTANCE_IDENTIFIER} のアップグレードが完了し、利用可能になりました。"

# 5. バージョンの最終確認
aws rds describe-db-instances \
  --db-instance-identifier "$DB_INSTANCE_IDENTIFIER" \
  --query "DBInstances[0].EngineVersion" --output text

利点

自動化されたバックアップ
継続的な自動バックアップが提供されることが多く、手動でのバックアップ作業が不要になります。
高可用性/スケーラビリティ
マネージドサービスは通常、高可用性構成やスケーリング機能を簡単に利用できます。
運用負荷の軽減
データベースのアップグレード、バックアップ、パッチ適用などの管理タスクをクラウドプロバイダーが担当します。

欠点

コスト
自己管理型サーバーに比べて運用コストが高くなる可能性があります。
柔軟性の制限
データベースの設定やカスタマイズの自由度が、自己管理型サーバーに比べて低い場合があります。
ベンダーロックイン
特定のクラウドプロバイダーのプラットフォームに依存することになります。

これらの代替方法は、それぞれ異なるメリットとデメリットを持ちます。どの方法を選択するかは、ダウンタイムの許容範囲、データの規模、運用チームのスキルセット、利用しているインフラストラクチャ（オンプレミス、VM、コンテナ、クラウド）によって決定されるべきです。