MariaDBバージョンアップの秘訣：10.11から11.0へのスムーズな移行

2025-05-26

MariaDBのメジャーバージョンアップグレードは、新しい機能や最適化が導入される一方で、一部の非互換な変更が含まれる可能性があるため、細心の注意を払って実行する必要があります。

アップグレードの一般的な手順

- 最重要事項です。 アップグレード前に、現在のMariaDB 10.11のすべてのデータベースを完全にバックアップしてください。これにより、万が一問題が発生した場合でも元の状態に戻すことができます。
- mariadb-dump や mariabackup などのツールを使用してバックアップを取得します。mariabackup は、大規模なデータベースで高速なバックアップ/リストアが可能です。
リポジトリ設定の変更
- お使いのOS（Debian/Ubuntu, RHEL/CentOS/Fedora, SLES/OpenSUSEなど）に応じたMariaDBのリポジトリ設定を、MariaDB 11.0をインストールするように変更します。
- MariaDBの公式ウェブサイトで、お使いのOSとバージョンに合ったリポジトリ設定ツールが提供されていますので、それを利用するのが最も確実です。
MariaDBの停止
- 現在のMariaDBサービスを停止します。
- sudo systemctl stop mariadb (Systemdを使用している場合)
- sudo service mariadb stop (SysVinitを使用している場合)
旧バージョンのMariaDBのアンインストール（オプション、推奨）
- 多くのケースで、古いバージョンのMariaDBパッケージをアンインストールすることが推奨されています。これにより、古い設定ファイルなどが残存することによる問題を回避できます。
- ただし、この手順はデータの削除を伴う可能性があるため、必ずバックアップが完全に取得されていることを確認してください。
- Debian/Ubuntuの場合: sudo apt-get remove mariadb-server
- RHEL/CentOS/Fedoraの場合: sudo yum remove MariaDB-server または sudo dnf remove MariaDB-server
新バージョンのMariaDBのインストール
- 変更したリポジトリ設定に基づいて、MariaDB 11.0をインストールします。
- 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
設定ファイルの確認と変更
- 新しいバージョンのMariaDBがインストールされたら、my.cnf などの設定ファイルを確認し、必要に応じて変更します。
- MariaDB 11.0では、MariaDB 10.11でサポートされていた一部のオプションが非推奨になったり、削除されたりしている可能性があります。起動時にエラーが発生しないように、これらのオプションを特定し、削除または調整する必要があります。
- 特に、最適化関連のパラメータ（innodb_change_buffering など、MariaDB 11.0で削除されたもの）や、非推奨になった機能に関する設定は注意が必要です。
MariaDBの起動
- 新しいバージョンのMariaDBを起動します。
- sudo systemctl start mariadb
mariadb-upgrade の実行
- MariaDBのバージョンアップグレードにおいて最も重要なステップの一つです。これは、データベース内のシステムテーブルを新しいバージョンと互換性のある形式に更新するために必要です。
- 適切な権限を持つデータベースユーザー（例: root）で実行します。
- sudo mariadb-upgrade -u root -p
- このコマンドは、mysql データベース内のシステムテーブルを更新し、すべてのテーブルが新しいMariaDBバージョンと互換性があることを確認します。
アプリケーションのテスト
- MariaDBのアップグレードが完了したら、関連するアプリケーションが正しく動作するかどうかを徹底的にテストします。
- 特に、クエリのパフォーマンスに影響がないか、予期せぬエラーが発生しないかなどを確認してください。
- MariaDB 11.0では新しいオプティマイザが導入されており、一部の複雑なクエリの実行計画が変わる可能性があります。これにより、クエリのパフォーマンスが向上することもあれば、稀に低下することもあります。

考慮すべき点と注意点

十分なテスト: 本番環境に適用する前に、ステージング環境や開発環境で十分なテストを行うことが不可欠です。
ロールバック計画: アップグレードが失敗した場合に備えて、詳細なロールバック計画を立てておくことが重要です。これには、バックアップからのリストア手順などが含まれます。
新しいオプティマイザ: MariaDB 11.0の主要な新機能の一つは、新しいオプティマイザのコストモデルです。これにより、クエリの実行計画がより正確に予測され、多くの場合でパフォーマンスが向上します。しかし、既存のアプリケーションのクエリがどのように影響を受けるか、事前にテストすることをお勧めします。
InnoDB Change Bufferの削除: MariaDB 11.0では、InnoDB Change Bufferが削除されています。これにより、一部のワークロードでパフォーマンス特性が変わる可能性があります。
非互換性: MariaDBの公式ドキュメントで、10.11から11.0への非互換性のリストを必ず確認してください。これには、削除された変数、変更されたデフォルト値、データ型の変更などが含まれる場合があります。
LTS (Long Term Support) バージョン: MariaDB 10.11 は LTS バージョンですが、MariaDB 11.0 は短期間サポート（Short Term Release）の可能性があります。長期的な運用を考える場合、MariaDB 11.4のような次のLTSリリースを検討することも重要です。

メジャーバージョンアップグレードでは、既存の設定やアプリケーションとの互換性に関する問題が発生しやすいため、以下に示す一般的なエラーとそれに対するトラブルシューティング方法を理解しておくことが重要です。

MariaDBが起動しない、または起動時にエラーが発生する

原因

mariadb-upgradeの未実行または失敗
システムテーブルが新しいバージョンと互換性がない状態。
データディレクトリの権限問題
MariaDBサービスがデータディレクトリにアクセスするための適切な権限がない場合。
設定ファイルの互換性の問題
MariaDB 11.0では、10.11で存在した一部のシステム変数やオプションが削除されたり、非推奨になったりしています。古いmy.cnfファイルにこれらのオプションが残っていると、起動エラーの原因となります。特に、innodb_change_bufferingやinnodb_change_buffer_max_sizeは11.0で削除されています。

トラブルシューティング

エラーログの確認
最も重要なステップです。MariaDBのエラーログ（通常、/var/log/mysql/error.log や /var/log/mariadb/mariadb.log などにあります）を確認し、具体的なエラーメッセージを探します。エラーメッセージは問題の特定に役立ちます。
my.cnfの確認と修正
- エラーログに「Unknown system variable」や「deprecated option」などのメッセージがある場合、それが原因です。
- MariaDB 11.0の公式ドキュメントで、削除または非推奨になったオプションのリストを確認し、my.cnfから該当する行をコメントアウトするか削除します。特に以下のオプションに注意してください:
  - innodb_change_buffering
  - innodb_change_buffer_max_size
  - innodb_defragment および関連するinnodb_defragment_n_pagesなどのオプション
- MariaDB 11.0からinnodb_undo_tablespacesのデフォルト値が0から3に変更されています。古い設定でinnodb_undo_tablespaces=0を明示的に指定している場合、この変更が影響を与える可能性があります。
データディレクトリの権限確認
- データディレクトリ（通常/var/lib/mysqlまたは/var/lib/mariadb）と、その中のファイルおよびサブディレクトリの所有者がMariaDBを実行するユーザー（通常mysqlまたはmariadb）になっていることを確認します。
- sudo chown -R mysql:mysql /var/lib/mysql (または適切なユーザーとパス)
mariadb-upgradeの再実行
- MariaDBが起動した後、mariadb-upgradeコマンドを再度実行します。
- sudo mariadb-upgrade -u root -p
- それでも起動しない場合は、mysqld --skip-grant-tables --skip-networking のように、権限テーブルをスキップして最低限の状態で起動し、mariadb-upgradeを実行してから、通常起動を試みることもできます。

アプリケーションの動作不良またはパフォーマンスの低下

原因

非推奨/削除された機能の使用
アプリケーションが、11.0で非推奨または削除された機能や構文に依存している場合。
システム変数のデフォルト値の変更
特定のシステム変数のデフォルト値が変更されたことで、アプリケーションの動作に影響が出る場合があります。
オプティマイザの変更
MariaDB 11.0では、新しいコストモデルに基づくオプティマイザが導入されています。これにより、以前のバージョンとは異なる実行計画が選択され、特定のクエリのパフォーマンスが向上することもあれば、稀に低下することもあります。

トラブルシューティング

スロークエリログの確認
パフォーマンスが低下したクエリを特定するために、スロークエリログを有効にして確認します。
EXPLAINによるクエリ実行計画の分析
- 問題のあるクエリに対してEXPLAIN（特にEXPLAIN FORMAT=JSON）を実行し、MariaDB 10.11での実行計画と比較します。
- 新しいオプティマイザは、以前のオプティマイザでは考慮されなかったパスを選択する可能性があります。optimizer_traceを有効にして、オプティマイザがどのようにコスト計算を行ったかを詳細に調べることも有効です。
- MariaDB 11.0では、optimizer_where_cost、optimizer_disk_read_costなどの新しいコスト関連のシステム変数が導入されており、これらの値を調整することでオプティマイザの挙動に影響を与えることができます。ただし、これは高度なチューニングであり、慎重に行う必要があります。
オプティマイザヒントの利用
どうしてもパフォーマンスが改善しない場合、特定のクエリに対してUSE INDEXやFORCE INDEXなどのオプティマイザヒントを使用することを検討します（ただし、これは最後の手段であり、クエリ自体の改善が望ましいです）。
アプリケーションログの確認
アプリケーション側のエラーログも確認し、MariaDBからのエラーメッセージや警告がアプリケーション側でどのように処理されているかを確認します。
既知の非互換性の確認
MariaDBの公式ドキュメントで、MariaDB 10.11と11.0間の既知の非互換性や変更点を確認し、アプリケーションがそれに影響を受けていないかを調べます。

mariadb-upgradeがエラーを出す、またはハングする

原因

メモリ不足
大規模なデータベースの場合、mariadb-upgradeが大量のメモリを消費することがあります。
ディスクスペースの不足
アップグレードプロセス中に一時ファイルやログファイルが増大し、ディスクスペースが枯渇する場合があります。
システムテーブルの破損
まれに、mysqlデータベース内のシステムテーブルが破損している場合があります。

トラブルシューティング

エラーログの確認
mariadb-upgradeの実行中に表示されるエラーメッセージ、またはMariaDBのエラーログを確認します。
ディスクスペースの確認
df -hコマンドなどで、MariaDBのデータディレクトリが置かれているパーティションの空き容量を確認します。不足している場合は、不要なファイルを削除するか、ディスクを拡張します。
メモリの確認
free -hコマンドなどでメモリ使用量を確認します。必要に応じて、一時的にスワップスペースを増やすか、利用可能なメモリを増やします。
mysql_upgrade_infoファイルの確認
データディレクトリ内にmysql_upgrade_infoというファイルがあるか確認します。このファイルはmariadb-upgradeが正常に完了したかどうかを示すもので、問題がある場合は削除してから再実行を試みることもあります（ただし、この操作は慎重に行う必要があります）。

ダンプファイルからのリストアが失敗する（特に古いバージョンからのダンプ）

原因

セキュアなクライアントモードの導入
MariaDB 10.11.8、11.0.6など、新しいMariaDBバージョンでダンプされたファイルには、/*!999999\- enable the sandbox mode */のようなコメントが追加されることがあります。これはセキュリティ向上のためのものですが、古いMariaDBクライアントやMySQLクライアントでリストアしようとすると、この行でエラーになることがあります。
mariadb-dumpの互換性問題
MariaDBの新しいバージョンでダンプしたファイルが、古いMariaDBクライアント/サーバーでリストアできない、またはその逆のケース。

トラブルシューティング

ダンプ時のMariaDBバージョンの確認
ダンプ元とリストア先のMariaDBのバージョンを確認します。
--skip-commentsオプションの使用
ダンプ時にmariadb-dump --skip-commentsを使用すると、このようなコメントが除外され、互換性の問題が回避できる場合があります。
tailコマンドでのフィルタリング
ダンプファイルをリストアする際に、問題のコメント行をtailコマンドなどでスキップしてリストアすることも可能です。例: tail -n +2 your_dump_file.sql | mariadb -u root -p your_database (これはあくまで例であり、行数を確認して正確に実行する必要があります。)
新しいバージョンのクライアントの使用
可能であれば、MariaDB 11.0のクライアントを使用してダンプファイルをリストアします。

MariaDBのメジャーバージョンアップグレードは、計画と準備が最も重要です。

テスト環境での事前検証
本番環境に適用する前に、必ずテスト環境でアップグレード手順とアプリケーションの動作を十分に検証してください。
公式ドキュメントの確認
アップグレードガイドや非互換性のリストを熟読します。
必ずバックアップを取る
これが最大のセーフティネットです。

MariaDBのアップグレードは、主にサーバー側の設定と運用に関わるため、直接的な「プログラミングコード」というよりは、シェルスクリプトやSQLコマンド、設定ファイルの編集が中心となります。アプリケーション側の変更が必要な場合もありますが、それはMariaDBの非互換な変更にアプリケーションが依存している場合に限られます。

データベースのバックアップスクリプト

アップグレード前に最も重要なステップです。 mariadb-dumpまたはmariabackupを使用します。

例1: mariadb-dump を使った全データベースの論理バックアップ

#!/bin/bash

# バックアップディレクトリ
BACKUP_DIR="/var/backups/mariadb"
DATE=$(date +%Y%m%d%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/all_databases_${DATE}.sql.gz"

# MariaDB接続情報 (必要に応じて環境変数や設定ファイルから読み込む)
DB_USER="backup_user"
DB_PASS="your_backup_password" # 本番環境では直接パスワードを書かない方が安全

# バックアップディレクトリが存在しない場合は作成
mkdir -p "$BACKUP_DIR"

echo "MariaDBの全データベースをバックアップ中..."

# mariadb-dumpコマンド
# --all-databases: すべてのデータベースをダンプ
# --single-transaction: InnoDBテーブルの一貫したスナップショットを取得 (InnoDBの場合推奨)
# --set-gtid-purged=OFF: GTID情報をオフにする (レプリケーション設定に依存)
# --routines --events --triggers: ストアドプロシージャ、イベント、トリガもダンプ
# | gzip: 出力をgzipで圧縮
mariadb-dump -u "$DB_USER" -p"$DB_PASS" \
  --all-databases \
  --single-transaction \
  --routines --events --triggers \
  --set-gtid-purged=OFF | gzip > "$BACKUP_FILE"

if [ $? -eq 0 ]; then
  echo "バックアップが正常に完了しました: $BACKUP_FILE"
else
  echo "バックアップ中にエラーが発生しました。"
  exit 1
fi

# 古いバックアップの削除 (例: 7日以上前のもの)
find "$BACKUP_DIR" -type f -name "*.sql.gz" -mtime +7 -delete
echo "7日以上前の古いバックアップを削除しました。"

exit 0

例2: mariabackup を使った物理バックアップ (大規模データベース向け)

mariabackup は通常、InnoDBの物理バックアップに使用され、停止時間が短縮されます。インストールが必要です。

#!/bin/bash

# バックアップディレクトリ
BACKUP_DIR="/var/backups/mariadb_physical"
DATE=$(date +%Y%m%d%H%M%S)
FULL_BACKUP_PATH="${BACKUP_DIR}/full_${DATE}"

# MariaDB接続情報
DB_USER="backup_user"
DB_PASS="your_backup_password"

# バックアップディレクトリが存在しない場合は作成
mkdir -p "$BACKUP_DIR"

echo "MariaDBの物理バックアップを開始中..."

# mariabackupコマンド
# --backup: バックアップを実行
# --target-dir: バックアップの出力先ディレクトリ
# --user --password: 接続情報
mariabackup --backup --target-dir="$FULL_BACKUP_PATH" \
  --user="$DB_USER" --password="$DB_PASS"

if [ $? -eq 0 ]; then
  echo "物理バックアップが正常に完了しました: $FULL_BACKUP_PATH"
  echo "バックアップを準備中 (これはリストアに必要です)..."
  # バックアップ準備フェーズ
  mariabackup --prepare --target-dir="$FULL_BACKUP_PATH"
  if [ $? -eq 0 ]; then
    echo "バックアップの準備が完了しました。"
  else
    echo "バックアップの準備中にエラーが発生しました。"
    exit 1
  fi
else
  echo "物理バックアップ中にエラーが発生しました。"
  exit 1
fi

echo "完了。"
exit 0

MariaDB設定ファイル (my.cnf) の調整

MariaDB 11.0 では、一部のオプションが削除または変更されています。アップグレード後、my.cnf に古いオプションが残っていると起動エラーになる可能性があります。手動での確認と修正が基本ですが、以下のようなスクリプトで起動前に確認することもできます（ただし、これは一般的な例であり、完全な網羅はできません）。

#!/bin/bash

# MariaDB設定ファイルのパス (環境に合わせて調整)
MARIADB_CONFIG="/etc/mysql/my.cnf" # または /etc/my.cnf, /etc/mariadb/my.cnf など

echo "MariaDB 11.0で非推奨/削除された可能性のあるmy.cnfオプションを確認中..."

# 削除されたオプションの例
DELETED_OPTIONS=(
  "innodb_change_buffering"
  "innodb_change_buffer_max_size"
)

# 非推奨になったオプションの例 (完全に削除されたわけではないが、将来削除される可能性)
DEPRECATED_OPTIONS=(
  "innodb_defragment"
  "innodb_defragment_n_pages"
  # 他にもあれば追加
)

FOUND_DELETED=false
FOUND_DEPRECATED=false

for opt in "${DELETED_OPTIONS[@]}"; do
  if grep -q "^[[:space:]]*${opt}" "$MARIADB_CONFIG"; then
    echo "警告: 削除されたオプション '${opt}' が ${MARIADB_CONFIG} に存在します。"
    echo "  このオプションは削除またはコメントアウトする必要があります。"
    FOUND_DELETED=true
  fi
done

for opt in "${DEPRECATED_OPTIONS[@]}"; do
  if grep -q "^[[:space:]]*${opt}" "$MARIADB_CONFIG"; then
    echo "注意: 非推奨のオプション '${opt}' が ${MARIADB_CONFIG} に存在します。"
    echo "  これは将来のバージョンで削除される可能性があるため、代替を検討してください。"
    FOUND_DEPRECATED=true
  fi
done

if ! $FOUND_DELETED && ! $FOUND_DEPRECATED; then
  echo "問題となるオプションは見つかりませんでした。"
else
  echo "my.cnf を慎重に確認し、必要な変更を行ってください。"
fi

exit 0

mariadb-upgrade の実行

MariaDBのアップグレード後に必ず実行する必要があるコマンドです。これにより、システムデータベースの互換性が確保されます。

#!/bin/bash

echo "MariaDBサービスの起動を確認..."
# MariaDBサービスが起動していることを確認する (必要に応じて)
systemctl is-active mariadb > /dev/null
if [ $? -ne 0 ]; then
  echo "MariaDBサービスが起動していません。起動します..."
  sudo systemctl start mariadb
  sleep 5 # 起動を待つ
  if [ $? -ne 0 ]; then
    echo "MariaDBサービスの起動に失敗しました。エラーログを確認してください。"
    exit 1
  fi
fi

echo "mariadb-upgrade を実行中..."

# mariadb-upgradeコマンド
# -u root: rootユーザーで実行
# -p: パスワードの入力を求める
# 必要に応じて --force オプションも検討するが、通常は必要ない
sudo mariadb-upgrade -u root -p

if [ $? -eq 0 ]; then
  echo "mariadb-upgrade が正常に完了しました。"
  echo "MariaDBサービスを再起動して変更を適用します。"
  sudo systemctl restart mariadb
else
  echo "mariadb-upgrade の実行中にエラーが発生しました。エラーログを確認してください。"
  exit 1
fi

echo "アップグレード後の最終確認として、MariaDBのバージョンを確認します。"
mariadb --version

exit 0

アプリケーションからの接続テスト (Pythonの例)

MariaDBサーバーがアップグレードされた後、アプリケーションが新しいサーバーに正しく接続できるか、クエリが問題なく実行されるかを確認するPythonスクリプトの例です。

import mariadb
import sys

# データベース接続情報
DB_CONFIG = {
    'host': 'localhost',
    'user': 'your_app_user',
    'password': 'your_app_password',
    'database': 'your_database_name'
}

try:
    # MariaDBに接続
    conn = mariadb.connect(**DB_CONFIG)
    cur = conn.cursor()

    print("MariaDBへの接続に成功しました。")

    # サーバーのバージョン情報を取得
    cur.execute("SELECT VERSION()")
    version = cur.fetchone()[0]
    print(f"MariaDBサーバーバージョン: {version}")

    # 簡単なクエリを実行して動作確認
    test_table_name = "test_upgrade_check"
    cur.execute(f"DROP TABLE IF EXISTS {test_table_name}")
    cur.execute(f"CREATE TABLE {test_table_name} (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255))")
    cur.execute(f"INSERT INTO {test_table_name} (name) VALUES ('Test Data 1'), ('Test Data 2')")
    conn.commit()
    print(f"テーブル '{test_table_name}' の作成とデータ挿入に成功しました。")

    cur.execute(f"SELECT * FROM {test_table_name}")
    rows = cur.fetchall()
    print(f"取得したデータ: {rows}")

    # パフォーマンスに影響が出やすいクエリのテスト（例）
    # 例: 大量のデータをGROUP BYするクエリなど
    # cur.execute("SELECT complex_column, COUNT(*) FROM large_table GROUP BY complex_column")
    # results = cur.fetchall()
    # print(f"複雑なクエリのテスト結果の行数: {len(results)}")

    print("基本的なデータベース操作は正常に機能しています。")

except mariadb.Error as e:
    print(f"MariaDB接続またはクエリ実行中にエラーが発生しました: {e}", file=sys.stderr)
    sys.exit(1)
finally:
    if 'conn' in locals() and conn:
        conn.close()
        print("MariaDB接続を閉じました。")

アプリケーション接続テストスクリプト
アップグレードがアプリケーションに影響を与えていないかを確認するための基本的なテストです。接続、簡単なCRUD操作、可能であればパフォーマンスに影響が出やすい複雑なクエリもテストします。
mariadb-upgrade実行スクリプト
アップグレードの核心部分であり、データベースのシステムテーブルを新しいバージョンに合わせて更新します。MariaDBサーバーが起動していることを確認し、実行後に再起動して変更を適用します。
設定ファイル確認スクリプト
アップグレード後のMariaDBサーバーが起動しない原因となりやすい、古いmy.cnfオプションの存在を事前にチェックします。これにより、起動後のトラブルシューティングの手間を減らします。
バックアップスクリプト
実際にアップグレードを開始する前に、データ保護のために実行されます。論理バックアップはデータ形式の変化に強く、物理バックアップは大規模なデータベースでのリストアが高速です。

レプリケーションを利用したローリングアップグレード (Replication-based Rolling Upgrade)

これは、MariaDBのレプリケーション機能を利用して、段階的にサーバーをアップグレードしていく方法です。ダウンタイムを大幅に短縮できるのが最大のメリットです。

コンセプト

既存の環境 (MariaDB 10.11): まず、本番環境のMariaDB 10.11サーバー（マスター）があります。
新しいレプリカの構築: 新しいサーバー（またはVM/コンテナ）を準備し、MariaDB 11.0をインストールします。この新しいサーバーを、既存のMariaDB 10.11マスターのレプリカとして設定します。
- 注意点: MariaDBのレプリケーションは、通常、マスターがレプリカと同じかそれよりも古いバージョンである必要があります（または非常に近いバージョン）。しかし、メジャーバージョンアップグレードの場合は、新しいバージョンをレプリカとして設定し、レプリケーションが問題なく動作することを確認する「一時的な非推奨構成」を許容する場合があります。この点は、MariaDBのドキュメントで特定のバージョン間の互換性を確認することが不可欠です。MariaDBの公式ドキュメントでは、「レプリカはマスターと同じか新しいバージョンであるべき」とされています。したがって、通常はまずレプリカをアップグレードし、その後マスターを入れ替える形になります。
レプリケーションの同期: 新しいMariaDB 11.0レプリカが、既存のMariaDB 10.11マスターからすべてのデータを完全に同期するのを待ちます。
アプリケーションの切り替え: レプリカが完全に同期されたことを確認したら、アプリケーションの接続先を既存のMariaDB 10.11マスターから、新しいMariaDB 11.0レプリカに切り替えます。この際、短時間のダウンタイムが発生する可能性がありますが、全体のアップグレード時間と比較すれば非常に短いです。
旧マスターのアップグレード/廃止: アプリケーションが新しいMariaDB 11.0サーバーで正常に動作していることを確認したら、旧MariaDB 10.11サーバーはシャットダウンしてアップグレードするか、あるいは完全に廃止します。その後、必要であれば、新しい11.0サーバーのレプリカとして再構築することもできます。

プログラミング/運用例 (シェルスクリプトとSQL)

新しいMariaDB 11.0サーバーのインストールと起動 (前回の説明と同様)
既存のMariaDB 10.11マスターの設定変更 (バイナリログ有効化など)
- my.cnf に以下を追加または確認:
```
[mysqld]
log_bin = mysql-bin
server_id = 1
```
- MariaDB サービスを再起動。

レプリケーションユーザーの作成 (マスター上で)

CREATE USER 'repl_user'@'%' IDENTIFIED BY 'replication_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

マスターのステータス確認 (マスター上で)

SHOW MASTER STATUS;
-- File と Position の値（例: mysql-bin.000001, 12345）をメモする

新しいMariaDB 11.0レプリカの設定 (レプリカ上で)
- my.cnf に以下を追加または確認:
```
[mysqld]
server_id = 2 # マスターとは異なるID
```
- MariaDB サービスを再起動。

レプリカの設定と開始 (レプリカ上で)

CHANGE MASTER TO
  MASTER_HOST='<マスターのIPアドレス>',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='replication_password',
  MASTER_LOG_FILE='<手順4でメモしたFile>',
  MASTER_LOG_POS=<手順4でメモしたPosition>;

START SLAVE;

レプリケーションの同期状況確認 (レプリカ上で)

SHOW SLAVE STATUS\G
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0
-- が理想的な状態

アプリケーションの接続先変更
- アプリケーションの設定ファイルで、データベース接続文字列を新しいMariaDB 11.0サーバーのIPアドレス/ホスト名に変更します。
- プロキシ（HAProxy, MaxScaleなど）を使用している場合は、そちらの設定を変更します。
旧マスターのシャットダウンと廃止
- sudo systemctl stop mariadb (旧10.11サーバー)

利点
ダウンタイムを最小限に抑えられる。問題発生時のロールバックが比較的容易（旧マスターに戻す）。 欠点: サーバーリソースが一時的に2倍必要になる。レプリケーションの知識が必要。

ブルー/グリーンデプロイメント (Blue/Green Deployment)

レプリケーションベースのアップグレードと似ていますが、より広範なインフラストラクチャレベルのアプローチです。完全に分離された「ブルー」（既存）と「グリーン」（新規）の環境を用意し、トラフィックを切り替えることで、ダウンタイムを最小限に抑えつつ、安全なアップグレードを実現します。

コンセプト

ブルー環境 (MariaDB 10.11): 現在稼働中の本番環境。
グリーン環境 (MariaDB 11.0): 新しいMariaDB 11.0サーバーを含む、ブルー環境と全く同じ構成の新しい環境を構築します。
データ同期: ブルー環境からグリーン環境へ、データベースデータを同期します。これは、論理バックアップ/リストア、またはMariaDBのレプリケーション（ブルー環境がマスター、グリーン環境がレプリカ）を使用することで実現します。レプリケーションがよりダウンタイムを抑えられます。
テスト: グリーン環境でアプリケーションやシステムの徹底的なテストを実施します。これにより、アップグレード後の潜在的な問題を本番稼働前に発見できます。
トラフィックの切り替え: ロードバランサーやDNSの変更などにより、ユーザーからのトラフィックをブルー環境からグリーン環境へ切り替えます。
ブルー環境の廃止/保持: グリーン環境が安定稼定していることを確認した後、旧ブルー環境を廃止するか、あるいは次のアップグレードに備えてスタンバイ状態に保ちます。

プログラミング/運用例

トラフィック切り替えは、DNSのCNAMEレコード更新、ロードバランサーのバックエンドサーバー変更、サービスメッシュのルーティング変更などで行われます。
インフラストラクチャのプロビジョニングには、Ansible, Terraform, KubernetesなどのIaC (Infrastructure as Code) ツールが活用されます。
データ同期の部分は、上述の「レプリケーションを利用したローリングアップグレード」と同様のスクリプトやSQLコマンドが適用されます。

利点
ダウンタイムが極めて短い。問題発生時のロールバックが非常に容易（トラフィックをブルーに戻すだけ）。テスト環境と本番環境が分離されているため、リスクが低い。 欠点: サーバーリソースが一時的に2倍必要になる。インフラストラクチャの自動化と管理が複雑になる。

論理ダンプとリストア (Logical Dump and Restore)

これは最もシンプルで確実な方法ですが、データ量に応じてダウンタイムが長くなる可能性があります。

コンセプト

既存のMariaDB 10.11の停止: アプリケーションからの書き込みを停止し、データベースサーバーを停止します。
全データの論理バックアップ: mariadb-dump を使って、すべてのデータベースとユーザー情報をSQLファイルにダンプします。
MariaDB 11.0のクリーンインストール: 既存のMariaDB 10.11をアンインストールし、MariaDB 11.0を新規インストールします。
設定ファイルの調整: my.cnf をMariaDB 11.0の新しい推奨設定に合わせ、古いバージョンで削除されたオプションなどを除去します。
データのリロード: ダンプしたSQLファイルを新しいMariaDB 11.0にリストアします。
mariadb-upgradeの実行: リストア後、mariadb-upgrade を実行してシステムテーブルを更新します。
アプリケーションの再接続: アプリケーションを再起動し、新しいMariaDB 11.0サーバーに接続します。

プログラミング/運用例

新しいMariaDB 11.0のインストール、設定ファイル修正、mariadb-upgradeの実行は、前回の「一般的な手順」で説明したスクリプトや手動操作に準じます。

リストアは以下のようなコマンドで行います:

# 圧縮されたSQLファイルを解凍しながらmariadbクライアントにパイプする
gzip -dc /var/backups/mariadb/all_databases_YYYYMMDDHHMMSS.sql.gz | mariadb -u root -p

前述のバックアップスクリプト (mariadb-dump) がそのまま利用できます。

利点
手順が比較的シンプルで理解しやすい。データが完全に新しいスキーマと互換性のある形で再構築されるため、データの整合性に関する潜在的な問題を排除しやすい。 欠点: ダウンタイムがデータ量に比例して長くなる（大規模データベースには不向き）。