MariaDBのバージョンアップで失敗しない！よくあるエラーと解決策

2025-06-06

レプリケーションの柔軟性
スレーブはマスターより新しいバージョンであっても動作します。
接続プロトコルの互換性
接続プロトコルも後方互換性があるため、通常、古いクライアントをアップグレードする必要はありません。
テーブルデータファイルの互換性
ほとんどのMariaDBテーブルデータファイルは後方互換性があります。

ただし、メジャーバージョンアップグレードには注意点と推奨される手順があります。

アップグレードの要件と考慮事項

アップグレードノートの確認
各バージョンのリリースノートやアップグレードノートを確認し、主要な変更点や設定オプションの変更がないか確認することが非常に重要です。特定のストレージエンジンがサポートされなくなる場合もあります（例: MariaDB 10.5以降のTokuDB）。
データベースのバックアップ
万が一に備え、必ずデータベースの完全なバックアップを取得してください。特に mysql システムデータベースのディレクトリは、mariadb-dump --add-drop-table mysql (MariaDB 10.3以前では mysqldump) を使ってコピーを取ることを推奨します。システムテーブルのフィールド追加や新規システムテーブルの作成など、アップグレードの変更点のほとんどがここに集中しているためです。
サーバーのクリーンシャットダウン
データファイルは互換性があっても、リカバリログは互換性がない場合があります。そのため、サーバーをクリーンにシャットダウンする必要があります。innodb_fast_shutdown 変数が 2 (高速クラッシュシャットダウン) でないことを確認してください。デフォルトは 1 です。最も安全なオプションは 0 ですが、シャットダウンに時間がかかる可能性があります。また、innodb_force_recovery は 3 未満である必要があります。
RPMパッケージ使用時の注意
RPMパッケージを使用している場合、メジャーバージョン間のアップグレードは直接サポートされていません（マイナーバージョン間のアップグレードは可能です）。古いMariaDB RPMパッケージをアンインストールし、新しいMariaDB RPMパッケージをインストールしてから mariadb-upgrade を実行する必要があります。新しいRPMをインストールする際に mariadb-upgrade が自動的に実行されることもありますが、複数回実行しても問題ありません。
レプリケーション環境の場合
プライマリ-レプリカ（マスター-スレーブ）環境の場合、まずレプリカをアップグレードし、正常に動作することを確認してから残りのレプリカをアップグレードします。その後、1つのレプリカをプライマリに昇格させ、古いプライマリをアップグレードし、レプリカに設定変更します。

推奨されるアップグレード手順

MariaDBバイナリとライブラリのアップグレード
MariaDBサーバーを起動せずに、バイナリとライブラリをアップグレードします。
MariaDBサーバーの起動（必要であれば）
アップグレードの一部として mariadbd プロセスが起動しなかった場合、mariadbd --skip-grant-tables を実行して起動します。これにより、一部のシステムテーブルが最新ではないという警告が表示されることがありますが、これは mariadb-upgrade が修正するため無視して構いません。
mariadb-upgrade の実行
このコマンドがアップグレードの主要な作業を行います。
- mysql データベース内のシステムテーブルを最新バージョンに更新します。これは非常に迅速に完了します。
- mariadb-check --check-upgrade も実行し、メジャーバージョン間で変更された照合順序（collation）の変更がないかを確認します。変更された照合順序を使用している古いテーブルのインデックスを再作成します。
MariaDBサーバーの再起動
アップグレード処理を完了させるために、MariaDBサーバーを再起動します。
アプリケーションの動作テスト
アップグレード後にアプリケーションが以前と同様に動作することを確認します。多くの場合、オプティマイザの改善によりパフォーマンスが向上する可能性がありますが、まれにオプティマイザが間違った判断をすることがあるため、注意が必要です。

問題が発生した場合の対処法

万が一、アップグレードで問題が発生した場合は、以下の手順を試すことができます。

完了したら、mysql-old データディレクトリを削除します。
その後、古いユーザーを再度追加する必要があります。
mysql データディレクトリを mysql-old のように別の名前に移動し、mariadb-install-db を実行して新しいデータディレクトリを生成します。
mysql データディレクトリからInnoDBテーブル（gtid_slave_pos, innodb_table_stats, innodb_index_stats, transaction_registry など）を削除します。

MariaDBはメジャーバージョン間のダウングレードを公式にはサポートしていません。しかし、もしダウングレードが必要になった場合は、以下の手順を試すことができますが、推奨される方法ではありません。

クリーンシャットダウン
新しいMariaDBサーバーを停止する前に、innodb_fast_shutdown を 0 に設定してクリーンシャットダウンを行います。これにより、ダウングレードされたサーバーに適用する必要のあるredoログやundoログがないことを確実にします。
mysql データベースのテーブルの削除
(mariadb-dump で --add-drop-table オプションを使用しなかった場合) mysql データベース内のテーブルを削除します。
新しいMariaDBインストールの削除
新しくインストールしたMariaDBを削除します。
古いMariaDBバージョンのインストール
以前のMariaDBバージョンをインストールします。
mariadbd --skip-grant-tables でサーバーを起動
古い mysql データベースのインストール
FLUSH PRIVILEGES の実行
MariaDBクライアントで FLUSH PRIVILEGES を実行します。

サーバーが起動しない、またはシャットダウンできない

エラーの原因

リカバリログの互換性
innodb_fast_shutdown の設定が 2 (高速クラッシュシャットダウン) になっており、クリーンシャットダウンが行われなかった場合、リカバリログが新しいバージョンと互換性がないことがあります。
データファイルの破損
前回の異常終了などにより、データファイルが破損している。
権限の問題
MariaDBを実行するユーザー（通常は mysql または mariadb ユーザー）がデータディレクトリやログファイルにアクセスする権限がない。
ディスク空き容量不足
データディレクトリやログディレクトリの空き容量が不足している。
ポート競合
MariaDBの標準ポート（3306）が他のプロセスによって使用されている。
設定ファイル (my.cnf) の問題
- 古いバージョンで有効だった設定オプションが、新しいバージョンでは廃止されたり、名前が変更されたりしている場合があります。
- 構文エラーやパスの誤りがある。

トラブルシューティング

クリーンシャットダウンの確認
アップグレード前に innodb_fast_shutdown を 0 に設定して、完全にクリーンなシャットダウンが行われたことを確認します。
ファイル・ディレクトリの権限確認
データディレクトリ（例: /var/lib/mysql や /var/lib/mariadb）とログディレクトリの権限が、MariaDBを実行するユーザーに正しく設定されているか確認します。
ディスク空き容量の確認
df -h コマンドなどでディスクの空き容量を確認します。
ポート使用状況の確認
lsof -i :3306 や netstat -anv | grep LISTEN | grep 3306 などのコマンドで、3306ポートが他のプロセスで使用されていないか確認します。競合している場合は、該当プロセスを停止するか、MariaDBのポートを変更します。
設定ファイルの確認
my.cnf を注意深く確認し、廃止されたオプションがないか、構文に誤りがないかチェックします。新しいバージョンで導入された変更点をリリースノートで確認するのが良いでしょう。
- 例: mysqld --defaults-file=/etc/my.cnf --validate-config のように、mysqld コマンドで設定ファイルの検証を試みることもできます（パスは環境に合わせて変更）。
エラーログの確認 (最重要)
まず、MariaDBのエラーログ（通常、データディレクトリ内の <ホスト名>.err ファイル）を確認します。ここに、サーバーが起動しない原因に関する詳細な情報が記録されています。

mariadb-upgrade の失敗

エラーの原因

システムテーブルの不整合
mysql データベース内のシステムテーブルが、古いバージョンから不整合な状態になっている。
特定のストレージエンジンの非サポート
アップグレード先のバージョンで、以前使用していたストレージエンジンがサポートされなくなっている（例: MariaDB 10.5以降のTokuDB）。
権限不足
mariadb-upgrade を実行するユーザーが、データベースの変更に必要な十分な権限を持っていない（通常は root ユーザーで実行する必要があります）。

トラブルシューティング

エラーメッセージの確認
mariadb-upgrade の出力やMariaDBのエラーログに具体的なエラーメッセージが表示されるはずなので、そのメッセージを元に原因を特定します。
リリースノートの確認
アップグレード先のバージョンのリリースノートを確認し、廃止されたストレージエンジンや機能がないか確認します。もし廃止されている場合は、事前に他のストレージエンジンに変換しておく必要があります。
root ユーザーでの実行
mariadb-upgrade は、MariaDBの root ユーザー（またはそれに準ずる管理権限を持つユーザー）で実行する必要があります。

アプリケーションの動作不良（アップグレード後）

エラーの原因

クライアントライブラリの不整合
アプリケーションが使用しているMariaDBクライアントライブラリと、アップグレード後のMariaDBサーバーのバージョンに不整合がある場合、接続エラーや予期せぬ動作が発生することがあります。
プラグインの互換性
使用しているプラグインが新しいMariaDBバージョンと互換性がない場合があります。
文字コード/照合順序の変更
バージョンアップに伴い、デフォルトの文字コードや照合順序が変更されたり、特定の照合順序が非推奨になったりすることがあります。これにより、ソート順や比較結果が変わる可能性があります。
オプティマイザの動作変更
MariaDBのオプティマイザはバージョンアップで改善されることが多いですが、まれに古いバージョンとは異なる実行計画を選択し、パフォーマンスが低下したり、予期せぬ結果になったりすることがあります。
SQL構文の変更
ごくまれに、SQL構文の変更や非推奨化により、既存のアプリケーションが動作しなくなることがあります。

トラブルシューティング

クライアントライブラリの更新
アプリケーションが使用しているMariaDBクライアントライブラリ（例: PHPのmysqli、JavaのJDBCドライバなど）を、アップグレードしたMariaDBサーバーのバージョンに対応したものに更新することを検討します。
プラグインの確認
使用しているMariaDBのプラグインが、アップグレードしたバージョンでサポートされているか確認します。必要であれば、新しいバージョンに対応したプラグインに更新します。
文字コードと照合順序の確認
データベース、テーブル、カラムの文字コードと照合順序が意図した通りになっているか確認します。SHOW VARIABLES LIKE 'character_set%'; や SHOW VARIABLES LIKE 'collation%'; で確認できます。
SQLクエリのテスト
影響を受けていると思われるSQLクエリを直接新しいMariaDBサーバーで実行し、期待通りの結果が得られるか、パフォーマンスに問題がないか確認します。
- EXPLAIN コマンドや OPTIMIZER_TRACE を使用して、オプティマイザの実行計画を分析します。
- 必要であれば、optimizer_switch システム変数でオプティマイザの動作を調整することを検討します。
アプリケーションログの確認
アプリケーション側のエラーログを確認し、MariaDBとの接続エラーやSQLエラーが記録されていないか確認します。

RPMパッケージアップグレード時の問題

エラーの原因

RPMの仕様
RPMパッケージは通常、メジャーバージョン間の直接アップグレードをサポートしていません。古いメジャーバージョンのRPMをアンインストールしてから、新しいメジャーバージョンのRPMをインストールする必要があります。

依存関係の問題
RPMの依存関係エラーが発生した場合は、yum や dnf などのパッケージマネージャーが提案する解決策に従うか、競合するパッケージを手動で削除します。
手順の遵守
公式ドキュメントに記載されているRPMを使用したアップグレード手順を厳密に守ります。通常は、古いパッケージのアンインストール、新しいパッケージのインストール、そして mariadb-upgrade の実行という流れになります。

エラーメッセージの検索
エラーログに表示されるエラーメッセージをそのまま検索エンジンで検索すると、同じ問題を経験した他のユーザーや公式フォーラムでの解決策が見つかることが多いです。
ドキュメントの熟読
アップグレード先のMariaDBバージョンの公式ドキュメント（リリースノート、アップグレードノート）を徹底的に読み込みます。これには、廃止された機能、変更された設定、既知のバグなどの重要な情報が含まれています。
テスト環境での事前アップグレード
本番環境でアップグレードを行う前に、必ずテスト環境でアップグレードをシミュレーションし、潜在的な問題を特定して解決しておきます。
十分なバックアップ
アップグレード前には、必ずデータベースの完全なバックアップを取得してください。これが最悪の事態から復旧するための生命線となります。特に mysql システムデータベースのバックアップは重要です。

しかし、「プログラミングに関連する」という側面を考慮すると、以下のような例が考えられます。

アップグレード手順を自動化するシェルスクリプトの例
アップグレード後のデータベースの整合性を確認するためのSQLクエリの例
アップグレードによる変更点に対応するアプリケーションコードの調整例（概念的）

アップグレード手順を自動化するシェルスクリプトの例

これは、MariaDBのメジャーバージョンアップグレードの手順を自動化するためのシェルスクリプトの一般的な例です。OSによってコマンドが異なるため、ここではUbuntu/Debian系のaptコマンドとRHEL/CentOS系のyum/dnfコマンドを併記します。

注意点

設定ファイルの調整
新しいバージョンで廃止された設定オプションやデフォルト値の変更がある場合、手動で my.cnf を調整する必要があります。
管理者権限
スクリプトは管理者権限（rootまたはsudo）で実行する必要があります。
バージョン番号の指定
新旧のMariaDBバージョン番号を正確に指定する必要があります。
テスト環境での確認
事前にテスト環境でスクリプトを実行し、正常に動作することを確認してください。
必ずバックアップを取る
本番環境で実行する前に、必ずデータと設定ファイルの完全なバックアップを取ってください。

#!/bin/bash

# ==============================================================================
# MariaDB メジャーバージョンアップグレード自動化スクリプト例
#
# このスクリプトは一般的な手順を示すものであり、環境に合わせて適宜修正が必要です。
# 必ずテスト環境で十分に検証し、本番環境では細心の注意を払って実行してください。
#
# 前提:
#   - 旧バージョンのMariaDBが稼働していること
#   - MariaDBの公式リポジトリが設定されていること (またはパッケージのローカルコピーがあること)
# ==============================================================================

# 設定可能な変数
OLD_MARIADB_VERSION="10.6" # 現在のMariaDBメジャーバージョン (例: 10.6)
NEW_MARIADB_VERSION="10.11" # アップグレード先のMariaDBメジャーバージョン (例: 10.11)
MARIADB_ROOT_PASSWORD="your_mariadb_root_password" # MariaDBのrootユーザーパスワード

# データディレクトリと設定ファイルのパス (環境に合わせて調整)
DATADIR="/var/lib/mysql"
MYCNF_PATH="/etc/mysql/my.cnf" # または /etc/my.cnf, /etc/mariadb/mariadb.cnf など

# ログファイル
LOG_FILE="/var/log/mariadb_upgrade_$(date +%Y%m%d_%H%M%S).log"

# エラーハンドリング関数
handle_error() {
    echo "エラーが発生しました。詳細はログファイル ($LOG_FILE) を確認してください。"
    exit 1
}

# ログへの出力
log() {
    echo "$(date +%Y-%m-%d_%H:%M:%S) - $1" | tee -a "$LOG_FILE"
}

log "MariaDB メジャーバージョンアップグレードを開始します。"

# 1. 現在のMariaDBバージョンの確認
log "現在のMariaDBバージョンを確認します..."
CURRENT_MARIADB_VERSION=$(mariadb -V | grep -oP 'Distrib \K\d+\.\d+' | head -n 1)
if [[ "$CURRENT_MARIADB_VERSION" != "$OLD_MARIADB_VERSION" ]]; then
    log "警告: 現在のMariaDBバージョン ($CURRENT_MARIADB_VERSION) が指定された旧バージョン ($OLD_MARIADB_VERSION) と異なります。"
    read -p "続行しますか？ (y/n) " -n 1 -r
    echo
    if [[ ! $REPLY =~ ^[Yy]$ ]]; then
        log "アップグレードを中止しました。"
        exit 1
    fi
fi
log "現在のバージョン: $CURRENT_MARIADB_VERSION"

# 2. データベースのバックアップ
log "データベースの完全バックアップを開始します..."
# データディレクトリのバックアップ
log "データディレクトリ ($DATADIR) をコピーします..."
cp -rp "$DATADIR" "${DATADIR}_backup_$(date +%Y%m%d_%H%M%S)" || handle_error

# mysqldumpによる論理バックアップ
log "mysqldump による論理バックアップを開始します..."
# 全データベースのバックアップ。rootユーザーのパスワードは直接指定しない方が安全
# --single-transaction はInnoDBテーブル向け
# --all-databases は全てのデータベースを対象
# --routines --triggers --events はストアドプロシージャ、トリガー、イベントもバックアップ
mariadb-dump -u root -p"$MARIADB_ROOT_PASSWORD" --all-databases --single-transaction --routines --triggers --events > "/tmp/all_databases_backup_$(date +%Y%m%d_%H%M%S).sql" || handle_error
log "バックアップが完了しました。"

# 3. MariaDBサービスの停止
log "MariaDBサービスを停止します..."
systemctl stop mariadb || handle_error
log "MariaDBサービスが停止しました。"
systemctl status mariadb --no-pager

# 4. MariaDBリポジトリ設定の更新
log "MariaDBリポジトリ設定を更新します..."
# Ubuntu/Debianの場合
if [ -f /etc/apt/sources.list.d/mariadb.list ]; then
    log "Ubuntu/Debian: MariaDB APTリポジトリを更新します..."
    sed -i "s|${OLD_MARIADB_VERSION}|${NEW_MARIADB_VERSION}|g" /etc/apt/sources.list.d/mariadb.list || handle_error
    apt update || handle_error
# RHEL/CentOSの場合
elif [ -f /etc/yum.repos.d/mariadb.repo ]; then
    log "RHEL/CentOS: MariaDB YUM/DNFリポジトリを更新します..."
    sed -i "s|${OLD_MARIADB_VERSION}|${NEW_MARIADB_VERSION}|g" /etc/yum.repos.d/mariadb.repo || handle_error
    # yum clean all は dnf clean all でも可
    yum clean all || handle_error
    # dnf makecache または yum makecache でリポジトリキャッシュを更新
    yum makecache || handle_error
else
    log "エラー: MariaDBリポジトリ設定ファイルが見つかりません。手動で設定してください。"
    handle_error
fi
log "リポジトリ設定の更新が完了しました。"

# 5. 旧バージョンのMariaDBパッケージのアンインストール (データは残す)
log "旧バージョンのMariaDBパッケージをアンインストールします..."
# Ubuntu/Debianの場合
if command -v apt &> /dev/null; then
    apt remove --purge mariadb-server mariadb-client mariadb-common -y || handle_error
    apt autoremove -y || handle_error
# RHEL/CentOSの場合
elif command -v dnf &> /dev/null; then
    dnf remove MariaDB-server MariaDB-client MariaDB-common -y || handle_error
    dnf autoremove -y || handle_error
elif command -v yum &> /dev/null; then
    yum remove MariaDB-server MariaDB-client MariaDB-common -y || handle_error
    yum autoremove -y || handle_error
fi
log "旧バージョンのMariaDBパッケージのアンインストールが完了しました。"

# 6. 新しいバージョンのMariaDBパッケージのインストール
log "新しいバージョンのMariaDBパッケージをインストールします..."
# Ubuntu/Debianの場合
if command -v apt &> /dev/null; then
    apt install mariadb-server mariadb-client mariadb-common -y || handle_error
# RHEL/CentOSの場合
elif command -v dnf &> /dev/null; then
    dnf install MariaDB-server MariaDB-client MariaDB-common -y || handle_error
elif command -v yum &> /dev/null; then
    yum install MariaDB-server MariaDB-client MariaDB-common -y || handle_error
fi
log "新しいバージョンのMariaDBパッケージのインストールが完了しました。"

# 7. 設定ファイルの確認と調整
log "設定ファイル ($MYCNF_PATH) を確認・調整してください。"
log "特に、廃止されたオプションやデフォルト値が変更されたオプションに注意してください。"
log "必要に応じて、新しいバージョンの設定ファイル例を参考にしてください。"
# この部分では自動的な調整は難しいので、手動での確認を促す

# 8. MariaDBサービスの起動
log "新しいMariaDBサービスを起動します..."
systemctl start mariadb || handle_error
log "MariaDBサービスが起動しました。"
systemctl status mariadb --no-pager

# 9. mariadb-upgrade の実行
log "mariadb-upgrade を実行して、システムテーブルを更新し、既存のテーブルをチェックします..."
mariadb-upgrade -u root -p"$MARIADB_ROOT_PASSWORD" || handle_error
log "mariadb-upgrade が完了しました。"

# 10. MariaDBサービスの再起動 (mariadb-upgrade後に推奨)
log "MariaDBサービスを再起動します..."
systemctl restart mariadb || handle_error
log "MariaDBサービスが再起動しました。"

# 11. 新しいMariaDBバージョンの確認
log "アップグレード後のMariaDBバージョンを確認します..."
mariadb -V || handle_error
log "MariaDBのメジャーバージョンアップグレードが完了しました！"

# 12. データベースのセキュリティ強化 (初回インストール時と同様に実行推奨)
log "データベースのセキュリティ強化 (mysql_secure_installation) を実行することをお勧めします。"
log "mariadb-secure-installation コマンドを実行し、プロンプトに従ってください。"
# mariadb-secure-installation を自動化するのはリスクがあるため、手動を推奨

log "MariaDBアップグレードスクリプトの実行が終了しました。"
log "最終確認として、アプリケーションが正常に動作するかを確認してください。"

アップグレード後のデータベースの整合性を確認するためのSQLクエリの例

アップグレード後、データベースのテーブルやシステムテーブルの整合性を確認するために、以下のSQLクエリやコマンドが役立ちます。

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

-- システムデータベース 'mysql' のテーブル構造を確認
-- 例えば、特定のテーブルが新しいバージョンで変更されているかを確認
DESCRIBE mysql.user;
DESCRIBE mysql.db;
-- 他にも、mysql.tables_priv, mysql.columns_priv, mysql.proxies_priv など

-- すべてのデータベースとテーブルの健全性を確認 (mariadb-check と同じような機能)
-- しかし、mariadb-checkはサーバーが停止している状態でも実行できる外部ツール
-- サーバー起動中に手動で実行する場合は以下のSQLコマンド
CHECK TABLE your_database.your_table FOR UPGRADE; -- 特定のテーブルの場合
-- または、すべてのテーブルをループしてチェックするスクリプトを書く
-- SELECT CONCAT('CHECK TABLE ', TABLE_SCHEMA, '.', TABLE_NAME, ' FOR UPGRADE;')
-- FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
-- のようなクエリでコマンドリストを生成し、一つずつ実行する。

-- 照合順序 (collation) の確認
-- 新しいバージョンでデフォルトの照合順序が変更された場合、古いテーブルが古い照合順序のままか確認
SHOW VARIABLES LIKE 'collation_database';
SHOW VARIABLES LIKE 'character_set_database';
SHOW TABLE STATUS FROM your_database; -- 各テーブルの Collation を確認

-- グローバル変数やシステム変数の変更を確認
-- 新しいバージョンでデフォルト値が変更されたり、廃止されたりした変数がないか
SHOW GLOBAL VARIABLES;
-- 特定の変数を確認する場合
SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW GLOBAL VARIABLES LIKE 'old_passwords'; -- MariaDB 10.4で廃止

-- 権限の確認
-- 新しい権限モデルやGRANT構文の変更がないか
SHOW GRANTS FOR 'your_user'@'localhost';
-- 特に、REPLICATION_SLAVEなどの権限名が変更されたり、新しい権限が追加されたりする場合がある

MariaDBのメジャーバージョンアップグレードは、通常、アプリケーションコードに直接的な変更を必要としないように設計されています。しかし、以下のような場合には、アプリケーションコードの調整が必要になる可能性があります。

オプティマイザの変更によるクエリのパフォーマンス低下
- MariaDBのオプティマイザはバージョンアップで改善されますが、まれに特定の複雑なクエリの実行計画が変更され、パフォーマンスが低下することがあります。
- 対策
  EXPLAIN を使用してクエリの実行計画を分析し、必要に応じてインデックスの追加、クエリの書き換え、または OPTIMIZER_SWITCH 変数でオプティマイザの動作を調整することを検討します。これはプログラミングコードの変更というよりは、SQLの最適化とデプロイ前のテストの範疇です。

ドライバ/コネクタのバージョンアップ

新しいMariaDBバージョンに対応するために、アプリケーションが使用するデータベースドライバ（例: PHPのmysqli、JavaのJDBCドライバ、Pythonのmysqlclientなど）を更新する必要がある場合があります。ドライバのバージョンアップに伴い、APIの変更や設定の変更が必要になることがあります。

PHP (mysqli の例)

<?php
// 旧バージョンのMariaDBでも動作するが、新しいドライバを使用していることを確認
$mysqli = new mysqli("localhost", "user", "password", "database");

if ($mysqli->connect_errno) {
    echo "Failed to connect to MariaDB: (" . $mysqli->connect_errno . ") " . $mysqli->connect_error;
}

// 新しいMariaDBの機能を利用する場合、必要に応じてコードを変更
// 例: 新しいJSON関数など
$result = $mysqli->query("SELECT JSON_EXTRACT('{\"a\": 1}', '$.a') AS json_value");
if ($result) {
    $row = $result->fetch_assoc();
    echo "JSON Value: " . $row['json_value'] . "\n";
}
$mysqli->close();
?>

Python (mysql.connector の例)

import mysql.connector

try:
    # 新しいMariaDBサーバーに接続
    cnx = mysql.connector.connect(
        user='user',
        password='password',
        host='localhost',
        database='database'
    )
    cursor = cnx.cursor()

    # 新しいMariaDBの機能を利用するクエリ (例: Window Functions など)
    # MariaDB 10.2 以降で利用可能
    query = """
    SELECT
        employee_name,
        salary,
        SUM(salary) OVER (PARTITION BY department_id ORDER BY salary) as running_total_salary
    FROM
        employees;
    """
    cursor.execute(query)
    for (employee_name, salary, running_total_salary) in cursor:
        print(f"Employee: {employee_name}, Salary: {salary}, Running Total: {running_total_salary}")

except mysql.connector.Error as err:
    if err.errno == mysql.connector.errorcode.ER_ACCESS_DENIED_ERROR:
        print("Something is wrong with your user name or password")
    elif err.errno == mysql.connector.errorcode.ER_BAD_DB_ERROR:
        print("Database does not exist")
    else:
        print(err)
finally:
    if 'cnx' in locals() and cnx.is_connected():
        cursor.close()
        cnx.close()
        print("MariaDB connection closed.")

文字コードや照合順序の変更による影響
- データベースのデフォルト文字コードや照合順序が変更された場合、文字列の比較やソート順に影響が出る可能性があります。
- 対策
  アプリケーション側で文字コードを明示的に指定するか、データベース接続時の設定（SET NAMES utf8mb4; など）を確認する。
- 例: OLD_PASSWORD() 関数が非推奨になり、より強力なハッシュ関数が推奨される場合。アプリケーションがこれらの古い関数を使用している場合、新しい関数に切り替える必要がある。
- 対策
  データベース接続時に PDO::ATTR_EMULATE_PREPARES を false に設定するなど、プレースホルダを使ったSQLインジェクション対策を徹底する。

MariaDBのメジャーバージョンアップグレードは、基本的にはコマンドラインツールとパッケージ管理システムを使用しますが、本番環境でのダウンタイムの最小化、リスクの低減、そして自動化のために、いくつかの代替手段や高度なプログラミング手法が利用されます。

レプリケーションを使用したローリングアップグレード

これは、最も一般的なダウンタイムを最小化するアップグレード方法であり、プログラミング（シェルスクリプトやオーケストレーションツール）と深く関連します。レプリケーション環境（プライマリ/レプリカ構成）を活用することで、サービスを停止せずにアップグレードを進めることができます。

概念

レプリカのアップグレード
まず、既存のレプリカ（スレーブ）サーバーを新しいMariaDBバージョンにアップグレードします。
正常性確認
アップグレードされたレプリカがプライマリ（マスター）から正常にデータをレプリケーションしていることを確認します。
プライマリの切り替え
レプリカが最新の状態であることを確認後、アプリケーションの接続先をアップグレード済みのレプリカに切り替えます。この切り替えは、ロードバランサーの設定変更、DNSの切り替え、またはアプリケーション設定の動的な更新によって行われます。
旧プライマリのアップグレード
サービスを停止した旧プライマリサーバーを新しいバージョンにアップグレードし、必要であれば新しいレプリカとして構成します。

プログラミングによる実装例

監視スクリプト
レプリケーション遅延（SHOW SLAVE STATUS\G）やMariaDBの正常性を継続的に監視するスクリプトを記述し、問題があれば自動で通知・ロールバックを試みます。
構成管理ツール
Ansible, Chef, Puppetなどの構成管理ツールを使用して、複数サーバーにわたるアップグレードプロセスをオーケストレーションします。これにより、冪等性（何度実行しても同じ結果になること）を確保し、エラーハンドリングを強化できます。
シェルスクリプト
各ステップ（MariaDBの停止、パッケージのアンインストール/インストール、mariadb-upgradeの実行、サービスの起動、レプリケーション状態の確認）を自動化するシェルスクリプトを作成します。

論理バックアップ/リストアによるアップグレード

これは、データ量が比較的小さい場合や、レプリケーション環境がない場合に選択される方法です。mysqldump（またはmariadb-dump）をプログラミング的に利用します。

概念

旧バージョンの完全バックアップ
旧バージョンのMariaDBから mariadb-dump を使って、全てのデータベースの論理バックアップ（SQLファイル）を取得します。
旧バージョンのアンインストールと新バージョンのインストール
旧MariaDBを完全にアンインストールし、新しいMariaDBバージョンをクリーンインストールします。
バックアップのリストア
新しいMariaDBサーバーに、取得したSQLファイルをリストアします。

プログラミングによる実装例

プロビジョニングツール
Terraformなどのインフラプロビジョニングツールを使って、新しいバージョンのMariaDBインスタンスを完全に新規作成し、バックアップをリストアするフローを定義することも可能です。

シェルスクリプト

#!/bin/bash
BACKUP_FILE="/tmp/full_backup_$(date +%Y%m%d%H%M%S).sql"
MARIADB_ROOT_PASSWORD="your_password"

echo "--- バックアップ開始 ---"
mariadb-dump -u root -p"$MARIADB_ROOT_PASSWORD" --all-databases --single-transaction --routines --triggers --events > "$BACKUP_FILE"
if [ $? -ne 0 ]; then
    echo "バックアップに失敗しました。"
    exit 1
fi
echo "バックアップ完了: $BACKUP_FILE"

echo "--- 旧MariaDBの停止とアンインストール（手動または自動） ---"
# systemctl stop mariadb
# apt remove ... / yum remove ...

echo "--- 新MariaDBのインストール（手動または自動） ---"
# apt install ... / yum install ...

echo "--- リストア開始 ---"
mariadb -u root -p"$MARIADB_ROOT_PASSWORD" < "$BACKUP_FILE"
if [ $? -ne 0 ]; then
    echo "リストアに失敗しました。"
    exit 1
fi
echo "リストア完了。"

echo "--- mariadb-upgrade の実行 ---"
mariadb-upgrade -u root -p"$MARIADB_ROOT_PASSWORD"
if [ $? -ne 0 ]; then
    echo "mariadb-upgrade に失敗しました。"
    exit 1
fi
echo "アップグレード完了。"

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

コンテナ環境では、アップグレードのプロセスが非常に柔軟になります。これはプログラミング（Dockerfile、Kubernetes YAML、スクリプト）によって定義されます。

概念

新しいイメージのビルド/プル
新しいMariaDBメジャーバージョンを含むDockerイメージをビルドまたはプルします。
データボリュームの保持
データベースのデータは永続ボリュームに保存されているため、コンテナイメージを置き換えてもデータは保持されます。
既存コンテナの停止と新しいコンテナの起動
既存のMariaDBコンテナを停止し、新しいバージョンのイメージを使って新しいコンテナを起動します。
mariadb-upgradeの実行
新しいコンテナが起動した後、docker exec や Kubernetesのkubectl exec を使ってコンテナ内で mariadb-upgrade コマンドを実行します。
（Kubernetesの場合）ローリングアップデート
Kubernetesのデプロイメント定義を更新することで、ダウンタイムなしでローリングアップデートを実行できます。

プログラミングによる実装例

CI/CDパイプライン
Jenkins, GitLab CI/CD, GitHub Actionsなどを使って、上記の手順を自動化し、新しいMariaDBバージョンをテストし、デプロイするパイプラインを構築します。

Kubernetes YAML
Deployment定義でMariaDBのイメージバージョンを更新し、initContainers や postStart フックを使って mariadb-upgrade を実行するロジックを含めることができます。

# Kubernetes Deployment の例 (抜粋)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mariadb
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: mariadb
    spec:
      containers:
      - name: mariadb
        image: mariadb:10.11 # ここを新しいバージョンに更新
        env:
          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mariadb-secret
                key: root_password
        volumeMounts:
        - name: mariadb-persistent-storage
          mountPath: /var/lib/mysql
      # initContainer を使って mariadb-upgrade を実行する例
      initContainers:
      - name: mariadb-upgrade-init
        image: mariadb:10.11 # アップグレードするバージョンと同じイメージ
        command: ["sh", "-c", "mysql_upgrade -u root -p$(MYSQL_ROOT_PASSWORD) || mariadb-upgrade -u root -p$(MYSQL_ROOT_PASSWORD)"]
        env:
          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mariadb-secret
                key: root_password
        volumeMounts:
        - name: mariadb-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mariadb-persistent-storage
        persistentVolumeClaim:
          claimName: mariadb-pv-claim

Dockerfile
MariaDBのベースイメージを指定し、必要に応じて設定ファイルなどを追加します。

クラウドプロバイダのマネージドサービス（例: AWS RDS, Azure Database for MariaDB, Google Cloud SQL）

これは最も「プログラミング要素が少ない」アップグレード方法ですが、裏側ではクラウドプロバイダが高度なオーケストレーションをプログラミングしています。

概念

プロバイダが自動的にスナップショットの取得、新しいバージョンのインスタンスのプロビジョニング、データ移行、DNS切り替えなどを行います。ダウンタイムは最小限に抑えられます。
クラウドコンソールやCLIから、簡単な操作でデータベースエンジンのメジャーバージョンアップグレードを開始します。

プログラミングによる実装例

Infrastructure as Code (IaC)
TerraformやCloudFormationなどのIaCツールで、データベースインスタンスのバージョン情報を変更し、デプロイすることでアップグレードをトリガーします。
CLIツール/SDK
クラウドプロバイダのCLIツール（aws rds modify-db-instance --engine-versionなど）やSDK（PythonのBoto3など）を使用して、アップグレード操作をスクリプトから実行できます。

MariaDBのメジャーバージョンアップグレードにおける「プログラミングに関連する代替手段」は、単なるコマンド実行以上の、自動化、ダウンタイム削減、そしてリスク管理に焦点を当てたアプローチを指します。

マネージドデータベースサービスは、最もシンプルなアップグレード体験を提供しますが、その裏側にはプロバイダによる複雑な自動化のプログラミングが存在します。
コンテナ化環境は、アップグレードプロセス自体をコードとして管理し、CI/CDパイプラインに組み込むことを可能にします。
レプリケーションを活用したローリングアップグレードは、ダウンタイムを最小限に抑えるための高度な戦略であり、スクリプトやオーケストレーションが不可欠です。
シェルスクリプトや構成管理ツールは、オンプレミスやVM環境での手順を自動化する基本的な手段です。

MariaDBパスワード有効期限の基本：設定と管理方法を徹底解説

MariaDBでは、主に以下の2つの方法でパスワードの有効期限を設定・管理できます。このシステム変数は、新しく作成されるユーザーのパスワードのデフォルト有効期限を日単位で設定します。デフォルト値は0であり、これは自動的なパスワード有効期限が無効であることを意味します。この値を正の整数（例: 90）に設定すると、その日数経過後にユーザーのパスワードが期限切れになります。設定例: SET GLOBAL default_password_lifetime = 90; -- 新規ユーザーのパスワード有効期限を90日に設定この設定は、変更後に作成されるユーザーに適用され、既存のユーザーには影響しません。