MariaDBバージョンアップの秘訣：10.5から10.6へ安全に移行するテクニック

2025-05-26

以下に、MariaDB 10.5 から 10.6 へのアップグレードの一般的な手順と注意点を説明します。

アップグレードの推奨手順

- アップグレード前に必ずデータベース全体のバックアップを取得してください。これは最も重要な手順です。万が一問題が発生した場合でも、バックアップから復旧できます。
- mysqldump --all-databases > backup.sql のようなコマンドで、すべてのデータベースをダンプできます。
- または、データディレクトリ (/var/lib/mysql など) をコピーしてバックアップすることもできます。
リポジトリ設定の変更
- お使いのOS (Debian/Ubuntu, RHEL/CentOS/Fedora, SLES/OpenSUSE など) に合わせて、MariaDB 10.6 をインストールするためのリポジトリ設定に変更します。
- MariaDBの公式ドキュメントに、各OSごとのリポジトリ設定更新方法が記載されています。
MariaDBの停止
- MariaDBサーバーを停止します。
- sudo systemctl stop mariadb (systemdを使用している場合)
古いバージョンのMariaDBのアンインストール
- MariaDBの旧バージョンをアンインストールします。
- Debian/Ubuntu: sudo apt-get remove mariadb-server
- RHEL/CentOS/Fedora: sudo yum remove MariaDB-server
- SLES/OpenSUSE: sudo zypper remove MariaDB-server
新しいバージョンのMariaDBのインストール
- 変更したリポジトリからMariaDB 10.6 をインストールします。
- MariaDBの公式ドキュメントに、各OSごとのインストール方法が記載されています。
設定ファイルの変更
- my.cnf などの設定ファイルに必要な変更を加えます。
- MariaDB 10.6 でサポートされなくなったオプションは削除する必要があります。
- 互換性の問題が発生する可能性のある変更点については、MariaDBの公式アップグレードガイドを確認してください。例えば、MariaDB 10.6ではROW_FORMAT=COMPRESSEDに関する変更点があったため、関連する設定（innodb-read-only-compressed=OFFなど）が必要になる場合があります。
MariaDBの起動
- 新しいバージョンのMariaDBを起動します。
- sudo systemctl start mariadb
mariadb-upgradeの実行
- MariaDBサーバーが起動したら、mariadb-upgradeユーティリティを実行します。
- このツールは、mysqlデータベース内のシステムテーブルが新しいバージョンと完全に互換性があることを確認し、すべてのテーブルが新しいMariaDBバージョンと互換性があることを迅速にチェックしてマークします。
- sudo mariadb-upgrade
動作確認
- MariaDBのバージョンが正しくアップグレードされたか確認します。
- mariadb -V または MariaDBクライアントにログインして SELECT VERSION(); を実行します。
- アプリケーションが正しく動作するか、各種テストを実行して確認してください。

テスト環境での事前確認
本番環境でアップグレードを行う前に、必ずテスト環境でアップグレード手順を試し、問題がないことを確認してください。
クラウド環境 (AWS RDSなど)
AWS RDSのようなマネージドデータベースサービスを利用している場合、アップグレード手順は提供元によって異なります。通常は、RDSの管理コンソールからメジャーバージョンアップグレードを実行するオプションが提供されています。
Galera Cluster
Galera Cluster を使用している場合は、ローリングアップグレードなどの特別な手順が必要です。各ノードを個別にアップグレードし、クラスターの運用を継続しながらアップグレードを進める方法があります。詳細はGalera Clusterのアップグレードガイドを参照してください。
互換性の変更
メジャーバージョンアップグレードでは、システム変数、機能、構文などに非互換な変更が含まれることがあります。アップグレード前にMariaDB 10.6のリリースノートとアップグレードガイドを必ず確認し、お使いのアプリケーションや設定に影響がないか確認してください。

起動時のエラーまたはサーバーが起動しない

原因

破損したログファイル
クリーンシャットダウンされなかった場合など、ログファイルが破損している。
データディレクトリの権限問題
MariaDBプロセスの実行ユーザーがデータディレクトリにアクセスできない。
設定ファイルの互換性問題
10.5で使用していたmy.cnfなどの設定ファイルに、10.6では非推奨になった、あるいは削除されたオプションが含まれている。

トラブルシューティング

innodb_force_recoveryの使用 (最終手段)
データ破損の可能性がある場合、my.cnfにinnodb_force_recovery = 1 (またはより高い値) を追加して起動を試みます。ただし、これはデータ損失のリスクがあるため、バックアップがある場合に限り、慎重に行ってください。
権限の確認
データディレクトリ (/var/lib/mysql など) の所有者と権限が、MariaDBの実行ユーザー (通常 mysql) に正しく設定されているか確認します。
- sudo chown -R mysql:mysql /var/lib/mysql
- sudo chmod -R 755 /var/lib/mysql (または適切な権限)
設定ファイルの修正
エラーログで「Unknown option」や「Deprecated option」のようなメッセージが出ている場合、my.cnfから該当するオプションを削除するか、MariaDB 10.6に対応する新しい設定に更新します。MariaDBの公式ドキュメントで、10.5と10.6間の変更点を確認してください。
エラーログの確認
最も重要なステップです。MariaDBのエラーログファイル (/var/log/mysql/error.log や /var/lib/mysql/hostname.err など) を確認し、具体的なエラーメッセージを探します。エラーメッセージは問題の根本原因を特定するのに役立ちます。

mariadb-upgradeの失敗または警告

原因

予期せぬエラー
データの一貫性問題など。
テーブルの文字セット/照合順序の変更
10.6でデフォルトの文字セットや照合順序に変更があり、既存のテーブルとの互換性がない。
古いシステムテーブル
mysqlデータベース内のシステムテーブルが、新しいMariaDBバージョンと互換性がない。

トラブルシューティング

文字セット/照合順序の調整
10.6ではデフォルトの文字セットがutf8からutf8mb3に変わったことなどにより、互換性の問題が生じることがあります。アプリケーション側でutf8mb4を使用するように変更したり、必要に応じてデータベースやテーブルの照合順序を明示的に指定したりすることを検討します。
--forceオプションの検討 (慎重に)
特定のエラーでmariadb-upgradeが停止する場合、sudo mariadb-upgrade --forceを試すことができます。ただし、これによりデータの整合性が損なわれる可能性もゼロではないため、バックアップを必ず取得してから実行してください。
エラーメッセージの確認
mariadb-upgradeの出力やMariaDBのエラーログを詳しく確認します。

アプリケーションからの接続エラーまたは動作異常

原因

ソケットパスの変更
MariaDBのソケットファイル (mysql.sock) のパスが変更され、アプリケーションが古いパスを参照している。
Optimizerの変更
クエリの最適化方法が変更されたことで、特定のクエリのパフォーマンスが低下したり、結果が変わったりすることがある。
非推奨のSQL構文
10.6で非推奨になったSQL構文をアプリケーションが使用している。
ユーザー認証プラグインの変更
MariaDB 10.4以降、デフォルトの認証プラグインがmysql_native_passwordからcaching_sha2_passwordに変更されています。アプリケーションが古い認証プラグインを想定していると接続に失敗します。

トラブルシューティング

ソケットパスの確認
my.cnfの[mysqld]セクションと[client]セクションで、socketのパスが一致しているか確認します。アプリケーションの接続設定も確認します。
Optimizerの調整
クエリのパフォーマンス問題が発生した場合、EXPLAINを使ってクエリ実行計画を分析し、optimizer_switchなどのシステム変数を調整することを検討します。Redditの投稿にもあったように、optimizer_use_condition_selectivityを古いデフォルトの1に戻すと問題が解決する場合があります。
SQL構文の確認
アプリケーションのログやMariaDBの一般的なログ（スロークエリログなど）で、エラーを生成しているSQLクエリを特定します。その後、MariaDB 10.6のドキュメントで、該当する構文が変更されていないか確認します。
認証プラグインの確認と修正
- MariaDBエラーログに「Authentication plugin caching_sha2_password cannot be loaded」のようなエラーがある場合、アプリケーションが古い認証プラグインを想定している可能性があります。
- 解決策としては、該当ユーザーの認証プラグインをmysql_native_passwordに戻すか、アプリケーションのコネクタを更新してcaching_sha2_passwordに対応させます。
- ユーザーのプラグインを戻す例: ALTER USER 'your_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';
- my.cnfにdefault_authentication_plugin=mysql_native_passwordを追加して、新しいユーザーのデフォルトを古いものに戻すこともできますが、セキュリティ上の理由から推奨されません。

特定のテーブルが読み取り専用になる (InnoDB COMPRESSED)

原因

MariaDB 10.6.0 から 10.6.5 までのバージョンでは、COMPRESSED行フォーマットのテーブルがデフォルトで読み取り専用になります。これは一時的な変更でしたが、その期間にアップグレードした場合に影響を受けます。

トラブルシューティング

または、my.cnfにinnodb-read-only-compressed=OFFを設定することで、読み取り専用を無効にできます。
MariaDB 10.6.6 以降にアップグレードします。

パッケージ管理システムの問題

原因

依存関係の問題
パッケージの依存関係が満たされていない。
リポジトリの不適切な変更
旧バージョンのリポジトリが残っていたり、新バージョンのリポジトリが正しく設定されていなかったりする。

依存関係の修復
- Debian/Ubuntu: sudo apt-get -f install
パッケージマネージャーのキャッシュクリア
- Debian/Ubuntu: sudo apt-get clean && sudo apt-get update
- RHEL/CentOS/Fedora: sudo yum clean all && sudo yum update
リポジトリ設定の再確認
MariaDBの公式ドキュメントに従って、お使いのOS用の10.6リポジトリが正しく設定されているか確認します。古いバージョンのリポジトリは削除またはコメントアウトしてください。

テスト環境
本番環境でアップグレードを行う前に、必ず同等のテスト環境でアップグレードプロセスをシミュレートし、すべてのアプリケーションが正常に動作することを確認してください。
公式ドキュメント
MariaDBの公式アップグレードガイド (https://mariadb.com/kb/en/upgrading/) は非常に詳細で役立ちます。各バージョン間の変更点や互換性の問題について記述されています。
エラーログ
エラーが発生したら、まずMariaDBのエラーログを確認します。
バックアップ
アップグレード前には必ず完全なバックアップを取得してください。

MariaDB 10.5 から 10.6 へのアップグレード自体は、主にシステム管理のタスクであり、直接的な「プログラミングコード」というよりは、シェルスクリプトやSQLコマンドを使用して行われます。ただし、アップグレード後のアプリケーションの互換性確認や、特定の変更への対応としてコードの調整が必要になる場合があります。

ここでは、アップグレードに関連する主要なコマンドライン操作と、考えられるプログラミング上の考慮事項を示す例を挙げます。

アップグレード前の準備 (バックアップ)

最も重要なステップです。データベース全体のバックアップを取得します。

シェルコマンド例 (mysqldump)

# 日付付きのバックアップファイル名を作成
BACKUP_DIR="/data/mariadb_backup"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/mariadb_full_backup_${TIMESTAMP}.sql"

echo "MariaDBの完全バックアップを開始します..."
sudo mysqldump --all-databases --single-transaction --skip-lock-tables --flush-privileges > "${BACKUP_FILE}"

if [ $? -eq 0 ]; then
    echo "バックアップが正常に完了しました: ${BACKUP_FILE}"
    # バックアップファイルのサイズ確認 (オプション)
    du -sh "${BACKUP_FILE}"
else
    echo "バックアップ中にエラーが発生しました。"
    exit 1
fi

--flush-privileges: 権限のフラッシュをバックアップに含めます。
--skip-lock-tables: MyISAMテーブルなどでもテーブルロックをスキップします。これにより、バックアップ中にサービスが停止する時間を最小限に抑えます。
--single-transaction: InnoDBテーブルで一貫性のあるバックアップを取得します (オンラインバックアップ)。
--all-databases: すべてのデータベースをバックアップします。

MariaDBの停止とアンインストール（古いバージョン）

シェルコマンド例 (Ubuntu/Debian)

echo "MariaDB サーバーを停止します..."
sudo systemctl stop mariadb

echo "MariaDB サーバーをアンインストールします..."
sudo apt-get remove --purge mariadb-server mariadb-client mariadb-common -y
sudo apt-get autoremove -y

# 古い設定ファイルやデータディレクトリが残っていないか確認 (手動で削除が必要な場合もある)
# ls -la /etc/mysql/
# ls -la /var/lib/mysql/

autoremove: 不要になった依存関係パッケージを削除します。
--purge: 設定ファイルも削除します。データファイルは削除されません。

MariaDB 10.6 リポジトリ設定とインストール

シェルコマンド例 (Ubuntu/Debian - mariadb-apt-repoを使用)

echo "MariaDB 10.6 リポジトリを設定します..."
# 以前のリポジトリファイルを削除 (またはコメントアウト)
sudo rm -f /etc/apt/sources.list.d/mariadb.list

# MariaDB GPGキーをダウンロードして追加
sudo apt-get install software-properties-common dirmngr ca-certificates apt-transport-https -y
sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'

# MariaDB 10.6 リポジトリを追加
# Ubuntu 20.04 (Focal Fossa) の例
sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] https://mirrors.netix.net/mariadb/repo/10.6/ubuntu focal main'

echo "パッケージリストを更新します..."
sudo apt-get update

echo "MariaDB 10.6 をインストールします..."
sudo apt-get install mariadb-server mariadb-client -y

# インストール後にサービスが自動起動することがあります
# sudo systemctl status mariadb

リポジトリのURLは、お使いのOSのバージョンやMariaDBの公式ドキュメントで最新のものを確認してください。

mariadb-upgradeの実行

新しいMariaDBサーバーが起動したら、システムテーブルを更新し、既存のテーブルの互換性を確認します。

シェルコマンド例

echo "MariaDB サービスが起動していることを確認します..."
sudo systemctl start mariadb
sudo systemctl enable mariadb

echo "mariadb-upgrade を実行します..."
sudo mariadb-upgrade

if [ $? -eq 0 ]; then
    echo "mariadb-upgrade が正常に完了しました。"
else
    echo "mariadb-upgrade でエラーが発生しました。エラーログを確認してください。"
    # エラーログの確認を促す
    sudo tail -f /var/log/mysql/error.log
    exit 1
fi

echo "MariaDB バージョンを確認します..."
mariadb -V

MariaDB 10.5 から 10.6 へのアップグレードで、アプリケーションコードに影響を与える可能性のある主な点は以下の通りです。

認証プラグインの変更

MariaDB 10.4 から caching_sha2_password がデフォルトになりました。古いコネクタ（例えば、mysql_native_passwordを想定しているもの）を使用している場合、接続エラーが発生する可能性があります。

PHPの例 (PDO_MYSQL)

古いアプリケーションコードで接続失敗する場合、ユーザーの認証プラグインを明示的に指定するか、PHPのPDO_MYSQLドライバを更新する必要があります。

SQLコマンドでユーザーの認証プラグインを変更する例

-- 既存ユーザーの認証プラグインを mysql_native_password に変更
ALTER USER 'your_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';
FLUSH PRIVILEGES;

これは一時的な解決策であり、セキュリティの観点からは推奨されません。理想的には、アプリケーションのドライバを更新し、caching_sha2_passwordに対応させるべきです。

Javaの例 (MySQL Connector/J)
caching_sha2_passwordを使用するには、MySQL Connector/J 8.0以降が必要です。

// Maven pom.xml の依存関係
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.33</version> </dependency>

Pythonの例 (mysql-connector-python)
mysql-connector-pythonも同様に比較的新しいバージョンを使用する必要があります。

# pip install mysql-connector-python
import mysql.connector

try:
    cnx = mysql.connector.connect(
        host='localhost',
        user='your_user',
        password='your_password',
        database='your_database'
    )
    # 接続成功
    print("データベースに接続しました！")
    cnx.close()
except mysql.connector.Error as err:
    if err.errno == mysql.connector.errorcode.CR_AUTH_PLUGIN_AUTH_FAILURE:
        print("認証プラグインのエラー: コネクタまたはユーザー認証を確認してください。")
    else:
        print(f"接続エラー: {err}")

非推奨または削除されたSQL構文/機能

アプリケーションが使用しているSQLクエリで、10.6で非推奨になったり削除されたりした構文が含まれていないか確認する必要があります。

例 (SHOW ENGINE INNODB STATUS -> SHOW INNODB STATUS)

MariaDB 10.6 では SHOW ENGINE INNODB STATUS が非推奨となり、代わりに SHOW INNODB STATUS を使用するように推奨されています。アプリケーションがデータベースの状態をモニタリングするためにこのコマンドを使用している場合、コードの変更が必要です。

PHPの例

<?php
$conn = new mysqli("localhost", "user", "password", "database");
if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
}

// 10.5以前で使っていたクエリ (非推奨)
$result_old = $conn->query("SHOW ENGINE INNODB STATUS");
if ($result_old) {
    // ... 処理
} else {
    echo "Error: " . $conn->error . "\n";
}

// 10.6で推奨されるクエリ
$result_new = $conn->query("SHOW INNODB STATUS");
if ($result_new) {
    // ... 処理
} else {
    echo "Error: " . $conn->error . "\n";
}

$conn->close();
?>

パフォーマンスの低下やクエリ結果の変化

MariaDB 10.6ではオプティマイザの改善が行われており、これが特定のクエリの実行計画を変更し、場合によってはパフォーマンスの低下を招いたり、まれにクエリの結果に影響を与えたりすることがあります。

トラブルシューティングの例

オプティマイザ関連のシステム変数の調整
必要に応じて、optimizer_switchなどのシステム変数を調整して、以前の挙動に戻すことを検討します。ただし、これは慎重に行うべきです。
EXPLAINの実行
問題のあるクエリに対してEXPLAINを実行し、実行計画がアップグレード前後でどのように変化したか比較します。
スロークエリログの分析
アップグレード後にスロークエリログを有効にし、以前は速かったクエリが遅くなっていないか確認します。

-- オプティマイザの挙動を確認
SHOW VARIABLES LIKE 'optimizer_switch';

-- 例: optimizer_use_condition_selectivity を一時的に無効にする (問題解決のため)
-- この設定はバージョンによって動作が異なる場合があるので注意
SET GLOBAL optimizer_switch='index_condition_pushdown=on,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on,condition_pushdown_for_derived=on,derived_condition_pushdown=on,split_materialized=on,condition_selectivity_for_derived=off';

Infrastructure as Code (IaC) ツールを利用した自動化

Ansible, Chef, Puppet, SaltStack といった IaC ツールは、サーバーの構成管理とプロビジョニングを自動化するために広く使われています。MariaDBのアップグレードプロセスも、これらのツールを使ってスクリプト化し、反復可能でエラーの少ない形にすることができます。

メリット

ロールバックの容易さ
設定の変更を元に戻すのが容易になります（ただしデータは別）。
バージョン管理
設定ファイルをGitなどのVCSで管理し、変更履歴を追跡できます。
エラーの低減
人為的なミスを排除し、設定の不整合を防ぎます。
自動化と再現性
手動での作業を減らし、同じ手順を何度でも確実に実行できます。

例 (Ansibleの場合のタスクの概念)

# Ansible playbook の一部のタスク例
- name: Stop MariaDB service
  ansible.builtin.systemd:
    name: mariadb
    state: stopped

- name: Remove old MariaDB packages
  ansible.builtin.apt: # Debian/Ubuntu の場合
    name:
      - mariadb-server
      - mariadb-client
      - mariadb-common
    state: absent
    purge: true # 設定ファイルも削除

- name: Add MariaDB 10.6 repository key
  ansible.builtin.apt_key:
    url: https://mariadb.org/mariadb_release_signing_key.asc
    state: present

- name: Add MariaDB 10.6 repository
  ansible.builtin.apt_repository:
    repo: "deb [arch=amd64,arm64,ppc64el] https://mirrors.netix.net/mariadb/repo/10.6/{{ ansible_distribution_release }} main"
    state: present
    update_cache: true

- name: Install MariaDB 10.6 packages
  ansible.builtin.apt:
    name:
      - mariadb-server
      - mariadb-client
    state: present

- name: Start MariaDB service
  ansible.builtin.systemd:
    name: mariadb
    state: started
    enabled: true

- name: Run mariadb-upgrade
  ansible.builtin.command: mariadb-upgrade
  args:
    creates: /var/lib/mysql/.mariadb_upgrade_done_10_6 # 冪等性確保のため、実行済みマーク

# その他の設定ファイル調整や権限設定なども同様にタスクとして追加

これは概念的な例であり、実際のプレイブックはエラーハンドリング、変数管理、テストなど、より複雑になります。

コンテナ技術 (Docker/Kubernetes) を利用したアップグレード

MariaDBをDockerコンテナで運用している場合、アップグレードプロセスはホストOSのパッケージ管理から切り離され、より制御可能になります。

メリット

新しいバージョンの試用
新しいバージョンのMariaDBコンテナを簡単に立ち上げ、アプリケーションとの互換性をテストできます。
ロールバックの容易さ
古いバージョンのイメージに戻すことで、迅速なロールバックが可能です（ただし、データの互換性問題は別途考慮が必要）。
隔離
ホストシステムへの影響を最小限に抑えます。
環境の一貫性
開発、テスト、本番環境で同じMariaDBイメージを使用できます。

アップグレード手順の概念

データボリュームの永続化
MariaDBのデータは、コンテナの外の永続ボリュームに保存されている必要があります。
既存コンテナの停止と削除
現在稼働しているMariaDB 10.5コンテナを停止し、削除します。
MariaDB 10.6 イメージのプル
Docker HubなどからMariaDB 10.6の公式イメージをプルします。
MariaDB 10.6 コンテナの起動
既存のデータボリュームをマウントして、MariaDB 10.6コンテナを起動します。
mariadb-upgradeの実行
起動したコンテナ内でmariadb-upgradeコマンドを実行します。これは、コンテナの起動スクリプトに含めるか、手動で実行できます。

例 (Docker Composeを使用)

# docker-compose.yml (MariaDB 10.5)
version: '3.8'
services:
  mariadb:
    image: mariadb:10.5 # 10.5イメージ
    container_name: my-mariadb-10-5
    volumes:
      - mariadb_data:/var/lib/mysql # 永続化されたデータボリューム
    environment:
      - MARIADB_ROOT_PASSWORD=mysecretpassword
    ports:
      - "3306:3306"

volumes:
  mariadb_data:

アップグレード時の変更

# docker-compose.yml (MariaDB 10.6への変更後)
version: '3.8'
services:
  mariadb:
    image: mariadb:10.6 # 10.6イメージに変更
    container_name: my-mariadb-10-6 # コンテナ名を変更しても良い
    volumes:
      - mariadb_data:/var/lib/mysql # 同じデータボリュームをマウント
    environment:
      - MARIADB_ROOT_PASSWORD=mysecretpassword
    ports:
      - "3306:3306"
    # mariadb-upgradeを自動実行する例 (エントリーポイントを上書きする場合など)
    # entrypoint: ["sh", "-c", "docker-entrypoint.sh mysqld && mariadb-upgrade && tail -f /dev/null"] # これは単純な例で、本番環境ではより複雑になります

volumes:
  mariadb_data:

mariadb-upgrade は、コンテナが起動した後に手動で実行するか、docker-entrypoint.sh のカスタマイズや初期化スクリプト (/docker-entrypoint-initdb.d/ 以下) を利用して自動化できます。
docker-compose down で古いコンテナを停止・削除し、docker-compose up -d で新しいイメージのコンテナを起動します。

本番環境でデータベースのダウンタイムを最小限に抑えたい場合、レプリケーションを活用したローリングアップグレードや、マスター/スレーブの切り替えによるアップグレードが有効です。

メリット

安全なロールバックパス
古いバージョンのデータベースが稼働し続けているため、問題発生時にすぐに切り戻しが可能です。
ダウンタイムの最小化
サービスの停止時間を大幅に短縮できます。

手順の概念 (マスター/スレーブ構成の場合)

- 既存のMariaDB 10.5マスターから、新しくMariaDB 10.6のスレーブを構築します。
- このスレーブは、10.5マスターからのレプリケーションを開始します。
- この時点では、10.6スレーブは読み取り専用で、アプリケーションからは使用しません。
mariadb-upgradeの実行 (スレーブ上)
- 10.6スレーブ上でmariadb-upgradeを実行し、システムテーブルやスキーマを更新します。
- この間もマスターからのレプリケーションは継続されます。
アプリケーションの切り替え
- 10.6スレーブがマスターのデータと完全に同期し、アプリケーションとの互換性テストに成功したら、アプリケーションからの接続先を新しい10.6スレーブに切り替えます。
- この操作は通常、非常に短時間で完了します。
古いマスターの停止と削除
- 新しい10.6スレーブが新しいマスターとして安定稼働していることを確認したら、古い10.5マスターを停止し、不要であれば削除します。
- 必要であれば、新しい10.6マスターから、さらに別の10.6スレーブを構築してレプリケーションを再構築します。

Galera Cluster の場合
Galera Cluster では、ローリングアップグレードという手法がサポートされており、クラスターのダウンタイムなしにノードを一つずつアップグレードしていくことができます。

注意点

アップグレード中のバージョンの差異によってレプリケーションに問題が生じないか、事前に確認が必要です。MariaDBは通常、マイナーバージョンアップグレードでは前方互換性（新しいバージョンが古いバージョンのレプリカになれる）を維持しますが、メジャーバージョンでは注意が必要です。
レプリケーションベースのアップグレードは複雑で、慎重な計画とテストが必要です。