「アップグレード後にbinlogの位置が把握できなくなり、ポイントインタイムリカバリができなくなった」
こうした事故の共通点は、binlogとGTIDの状態を確認しないまま作業を進めたことにあります。MariaDBのアップグレード手順自体はそれほど難しくありませんが、binlogとGTIDをどう引き継ぐかを理解していなければ、データ整合性を損なうリスクが生じます。
この記事では、Rocky Linux 9系／Ubuntu 24.04 LTSを想定環境として、mariadb upgradeの実施手順と、binlog・GTIDを安全に引き継ぐ移行設計を解説します。マイナーバージョンアップ（例: 10.11.7 ～ 10.11.9）からメジャーバージョンアップ（例: 10.11 LTS → 11.4 LTS）、レプリカを持つ環境での段取りまでをカバーします。
この記事のポイント
・アップグレード前に gtid_current_pos の値を必ず記録する
・マイナーはパッケージ更新 + mariadb-upgrade コマンドで完結
・メジャーはリポジトリ切替・設定移行・GTID引き継ぎの3段構え
・レプリカ環境ではレプリカ → ソースの順に更新する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
MariaDB upgradeで何が変わるのか｜マイナーとメジャーの違い
MariaDBのバージョン番号は「メジャー.マイナー.パッチ」の3桁で表されます（例: 10.11.9）。アップグレードの難易度はこの桁によって大きく異なります。・パッチバージョンアップ（例: 10.11.7 → 10.11.9）: バグ修正・セキュリティパッチが中心。パッケージ更新だけで完結し、mariadb-upgradeの実行は不要なことが多い。
・マイナーバージョンアップ（例: 10.6 → 10.11）: 機能追加あり。システムテーブルの変更が生じることがあるため、mariadb-upgradeを必ず実行する。
・メジャーバージョンアップ（例: 10.11 → 11.4）: 設定ファイルの互換性確認・非推奨オプションの対処が必要。my.cnfの移行も行う。
いずれのケースでも共通して重要なのがbinlogとGTIDの扱いです。これらを適切に管理することで、アップグレード後もレプリケーションの継続性やポイントインタイムリカバリ（PITR）を維持できます。
binlogとGTIDの仕組みをおさらいする
アップグレードで引き継ぐべき2つの状態を整理します。binlog（バイナリログ）とは
MariaDBがすべてのデータ変更操作を記録するログファイルです。/var/lib/mysql/ 配下に mysqld-bin.000001 のような形式でシーケンシャルに保存されます。
・レプリケーションのイベント転送に使用される
・mysqldumpと組み合わせてPITRを実現する
・log_bin = /var/log/mariadb/mysql-bin のようにmy.cnfで有効化する
GTID（Global Transaction ID）とは
MariaDBのGTIDはトランザクションを一意に識別する番号で、「ドメインID-サーバーID-シーケンス番号」（例: 0-1-1042）の形式を取ります。MySQL系のGTIDとは書式が異なります。
・gtid_current_pos: そのサーバーで最後にコミットされたGTID
・gtid_binlog_pos: binlogに書き込まれた最後のGTID
・gtid_slave_pos: レプリカとして受信した最後のGTID
アップグレード時にこれらの値をバックアップファイルと一緒に記録しておくことで、再起動後・再構成後に確実に引き継げます。
アップグレード前に確認すべきこと
1. 現在のバージョンとbinlog・GTID設定を確認する
作業前に現状のスナップショットを取ります。# バージョン確認 mariadb --version # binlogが有効かどうかの確認 mariadb -e "SHOW VARIABLES LIKE 'log_bin%';" # 現在のbinlogファイルとポジション確認 mariadb -e "SHOW MASTER STATUS\G" # GTIDの確認（有効化している場合） mariadb -e "SHOW GLOBAL VARIABLES LIKE 'gtid%';"
# SHOW MASTER STATUS の出力例 *************************** 1. row *************************** File: mysql-bin.001042 Position: 395147 Binlog_Do_DB: Binlog_Ignore_DB: # gtid_current_pos の出力例 Variable_name: gtid_current_pos Value: 0-1-8841
2. innodb_fast_shutdown=0 でクリーンシャットダウンを準備する
MariaDBをアップグレード前に停止する際、InnoDBがダーティページを完全にフラッシュした状態（clean shutdown）にしておくと、スキーマ変換が確実に行われます。# 実行中のサーバーに接続してフラッシュ設定を変更 mariadb -e "SET GLOBAL innodb_fast_shutdown = 0;" # 停止（設定変更後すぐに実施する） sudo systemctl stop mariadb
3. フルバックアップとGTIDポジションを記録する
アップグレードは常に「復旧できる状態」から始めます。# GTIDポジション付き論理バックアップ（mariadb-dump / mysqldump） # --master-data=2 はbinlogファイル名・ポジションをコメントとして埋め込む mariadb-dump \ --all-databases \ --single-transaction \ --master-data=2 \ --gtid \ -u root -p \ > /backup/pre-upgrade-$(date +%Y%m%d).sql # バックアップファイルの冒頭でGTID情報を確認 head -30 /backup/pre-upgrade-$(date +%Y%m%d).sql
マイナーバージョンアップ（例: 10.11.7 → 10.11.9）の手順
1. パッケージをアップデートする
同一メジャー系列内の場合は、リポジトリを変更せずそのままパッケージを更新します。Ubuntu 24.04 LTS（APT）の場合:
sudo apt update sudo apt install mariadb-server
sudo dnf update MariaDB-server
2. mariadb-upgrade を実行してシステムテーブルを更新する
パッケージ更新後にMariaDBを起動し、mariadb-upgrade（旧名: mysql_upgrade）を実行します。sudo systemctl start mariadb sudo mariadb-upgrade -u root -p
MariaDB upgrade detected Phase 1/7: Checking and upgrading mysql database Processing databases mysql mysql.column_stats OK mysql.columns_priv OK ... Phase 7/7: Running 'FLUSH PRIVILEGES' OK
3. binlog・GTIDの継続を確認する
再起動後、binlogの連続性とGTIDの値を確認します。mariadb -e "SHOW MASTER STATUS\G" mariadb -e "SHOW GLOBAL VARIABLES LIKE 'gtid_current_pos';"
# binlogファイルは連続している（001042 → 001043 に進む） File: mysql-bin.001043 Position: 112 # GTIDはアップグレード前のシーケンス番号から継続 Variable_name: gtid_current_pos Value: 0-1-8841
メジャーバージョンアップ（例: 10.11 LTS → 11.4 LTS）の手順
メジャーアップグレードでは、リポジトリの変更とmy.cnfの設定見直しが必要です。1. GTIDポジションを記録して論理バックアップを取得する
前述「アップグレード前に確認すべきこと」で行った手順を改めて実施します。特にGTIDの値は gtid_current_pos と gtid_slave_pos の両方を記録します。# GTIDポジションを記録する mariadb -e "SHOW GLOBAL VARIABLES LIKE 'gtid_current_pos';" # ソース側 mariadb -e "SHOW GLOBAL VARIABLES LIKE 'gtid_slave_pos';" # レプリカ側（レプリカの場合） # フルバックアップ（--gtid付き） mariadb-dump \ --all-databases \ --single-transaction \ --master-data=2 \ --gtid \ -u root -p \ > /backup/pre-major-upgrade-$(date +%Y%m%d).sql # InnoDB クリーンシャットダウン mariadb -e "SET GLOBAL innodb_fast_shutdown = 0;" sudo systemctl stop mariadb
2. リポジトリを切り替えて新バージョンをインストールする
MariaDB公式のセットアップスクリプトを使うと、APT・DNFともにリポジトリを一括で切り替えられます。Ubuntu 24.04 LTS（APT）の場合:
# リポジトリを 11.4 LTS に切り替え curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \ | sudo bash -s -- --mariadb-server-version="mariadb-11.4" # インデックスを更新してインストール sudo apt update sudo apt install mariadb-server
# 旧バージョンの MariaDB パッケージを削除 sudo dnf remove MariaDB-server MariaDB-client MariaDB-common # リポジトリを 11.4 LTS に切り替え curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \ | sudo bash -s -- --mariadb-server-version="mariadb-11.4" # 新バージョンをインストール sudo dnf install MariaDB-server MariaDB-client
インストール後、/etc/mysql/my.cnf（Ubuntu）または /etc/my.cnf（Rocky Linux）を開き、10.11系で使用していたオプションが11.4でも有効かどうか確認します。特に以下の点に注意してください。
・log_bin・server_id・binlog_format の設定はそのまま引き継いでよい
・gtid_strict_mode は11.4でも有効（変更なし）
・query_cache_* 系オプションは10.x系で廃止済みのため削除する
・plugin-load-add 等、バージョン依存のプラグイン行はリリースノートで要確認
3. mariadb-upgrade でシステムテーブルを更新する
sudo systemctl start mariadb sudo mariadb-upgrade -u root -p
4. GTIDを引き継いで再起動確認する
# GTIDポジションの確認 mariadb -e "SHOW GLOBAL VARIABLES LIKE 'gtid_current_pos';" # バージョン確認 mariadb -e "SELECT VERSION();" # テーブルアクセス確認（代表的なテーブルを1つ選ぶ） mariadb -e "SELECT COUNT(*) FROM mysql.user;"
レプリカを持つ環境でのアップグレード戦略
ソース（旧称マスター）とレプリカが存在する構成では、アップグレードの順序が重要です。推奨する順序: レプリカ先行アップグレード
・手順1: レプリカをアップグレードする（ソースは稼働継続）
・手順2: レプリカが新バージョンで正常にレプリケーションを受信できるか確認する
・手順3: ソースをアップグレードする
・手順4: ソース・レプリカ両方のGTIDポジションを照合する
MariaDBはマイナーバージョン間でbinlogの後方互換性を保つ設計になっているため、新バージョンのレプリカが旧バージョンのソースからイベントを受信することは通常問題ありません。逆（新ソース → 旧レプリカ）は非推奨です。
レプリカでのGTID引き継ぎ確認コマンド:
# レプリカサーバーでレプリケーション状態を確認 mariadb -e "SHOW REPLICA STATUS\G" # または旧コマンド（10.5以前） # mariadb -e "SHOW SLAVE STATUS\G" # GTIDポジションの確認 mariadb -e "SHOW GLOBAL VARIABLES LIKE 'gtid_slave_pos';"
# SHOW REPLICA STATUS の抜粋 Using_Gtid: Slave_Pos Gtid_IO_Pos: 0-1-8842 Gtid_Slave_Pos: 0-1-8842 Seconds_Behind_Master: 0
トラブルシュート
「Table 'mysql.gtid_slave_pos' doesn't exist」が出た
mariadb-upgrade が未実行、または途中で失敗した場合に発生します。# mariadb-upgrade を再実行する（--forceで強制上書き） sudo mariadb-upgrade --force -u root -p
「Unknown system variable 'gtid_current_pos'」が出た
GTIDが有効化されていないときに出るエラーです。my.cnfの [mysqld] セクションに以下を追加して再起動します。[mysqld] gtid_strict_mode = ON log_bin = /var/log/mariadb/mysql-bin log_slave_updates = ON
アップグレード後にレプリカがつながらない
エラーメッセージを SHOW REPLICA STATUS\G の Last_IO_Error フィールドで確認します。典型的なケースとして次の2つがあります。・GTIDポジションのギャップ: ソース側で PURGE BINARY LOGS によってレプリカが必要とするbinlogが削除されていた場合。バックアップから再同期が必要。
・server_id の重複: ソースとレプリカの server_id が同じになっている場合。my.cnfで値を変えて再起動する。
binlogとGTIDを使ったLinuxサーバー上のデータベース運用については、Linuxサーバー構築セミナーでも実務の設計思想から体系的に扱っています。
本記事のまとめ
| 場面 | 実施内容 | 確認コマンド |
|---|---|---|
| アップグレード前（全共通） | GTIDポジション記録・フルバックアップ取得・innodb_fast_shutdown=0設定 | SHOW GLOBAL VARIABLES LIKE 'gtid_current_pos'; |
| マイナーバージョンアップ | パッケージ更新 → mariadb-upgrade 実行 | sudo mariadb-upgrade -u root -p |
| メジャーバージョンアップ | リポジトリ切替 → パッケージ更新 → my.cnf確認 → mariadb-upgrade | mariadb -e "SELECT VERSION();" |
| アップグレード後（GTID確認） | gtid_current_pos がアップグレード前の値と一致しているか照合 | SHOW GLOBAL VARIABLES LIKE 'gtid_current_pos'; |
| レプリカ環境 | レプリカ先行でアップグレード → SHOW REPLICA STATUS でGTID照合 | SHOW REPLICA STATUS\G |
| トラブル時 | mariadb-upgrade --force で再実行・server_id重複を確認 | SHOW VARIABLES LIKE 'server_id'; |
mariadb upgradeは「パッケージを入れ替えてmariadb-upgradeを走らせるだけ」と思われがちですが、binlogとGTIDの状態管理を一つひとつ確認することで、アップグレード後のデータ整合性とレプリケーションの継続性が保証されます。メジャーアップグレードの前には必ず論理バックアップとGTIDポジションの記録を残すことを習慣にしてください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
データベース運用・バックアップ設計・レプリケーション管理など、実務直結のLinuxスキルをハンズオンで習得できる2日間のセミナーを開催しています。
＞＞ Linux Master Pro Seminar の詳細・申込はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：サービス停止なしでMariaDB rootパスワード変更する方法｜skip-grant-tablesを使わない手順
- この記事の属するカテゴリ：データーベース管理へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます