MySQLのレプリケーションをLinuxサーバー2台で構築する手順|binlogとGTIDによるソース・レプリカ設定

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux), データーベース管理 > MySQLのレプリケーションをLinuxサーバー2台で構築する手順|binlogとGTIDによるソース・レプリカ設定
「MySQLのレプリケーションを設定しようとしたら、binlogポジションとGTIDのどちらを使えばよいか迷っている」「CHANGE MASTER TOとCHANGE REPLICATION SOURCE TOのどちらが正しいのかわからない」——こういった質問をセミナー受講生からよく受けます。

MySQLのレプリケーションは、ソースサーバーのデータをリアルタイムでレプリカサーバーへ自動同期する機能です。読み取り負荷の分散や、障害発生時のフェイルオーバー準備として、Linuxで自前運用する現場では定番の構成です。

この記事では、Rocky Linux 9(RHEL 9互換)上のMySQL 8.4を対象に、binlogポジション方式とGTID方式、2パターンのレプリケーション構築手順を実機コマンドの出力例とともに解説します。my.cnfの設定・レプリケーション専用ユーザーの作成・CHANGE REPLICATION SOURCEの実行・SHOW REPLICA STATUSによる確認まで、一通りカバーします。

この記事のポイント

・MySQLレプリケーションはbinlogを介してソースからレプリカへ更新を自動同期する仕組み
・binlogポジション方式はFile名+位置で同期、GTID方式は一意IDで自動追跡する
・MySQL 8.4ではCHANGE MASTER TO等の旧構文が廃止。新コマンドへの対応が必須
・SHOW REPLICA STATUSでIO/SQLスレッド両方がYesなら正常動作している


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

MySQLレプリケーションとは?binlogとGTIDの役割

MySQLのレプリケーションは、ソースサーバーで発生した更新をバイナリログ(binlog)に記録し、レプリカサーバーがそのログを取得して再実行する仕組みです。

binlogには大きく2つの同期方式があります。

binlogポジション方式(従来方式)
ソースのバイナリログファイル名とポジション(位置)をレプリカに指定して差分を取得します。設定がシンプルで理解しやすい反面、フェイルオーバー時に手動でポジションを切り替える手間があります。

GTID方式(Global Transaction Identifier)
各トランザクションにサーバーUUID+連番の一意IDを付与します。フェイルオーバー時にGTIDが自動的に引き継がれるため、レプリカの切り替えが容易です。MySQL 5.6以降で利用可能ですが、一部の操作(CREATE TABLE ... SELECT等)に制限があります。

MySQL 8.0以降はコマンド体系が変わっています。旧コマンドと新コマンドの対応は以下のとおりです。
MySQL 5.7以前(旧コマンド) MySQL 8.0以降(新コマンド)
CHANGE MASTER TO CHANGE REPLICATION SOURCE TO
SHOW SLAVE STATUS SHOW REPLICA STATUS
MASTER_HOST= SOURCE_HOST=
START SLAVE START REPLICA
STOP SLAVE STOP REPLICA
MySQL 8.4ではCHANGE MASTER TO等の旧構文は完全に削除されています。8.4を使う場合は必ず新コマンドを使用してください。

構築前の準備|サーバー構成と前提条件

1. 動作確認済み環境

本記事での動作確認環境は以下のとおりです。

# 確認コマンド(両サーバーで実行) cat /etc/redhat-release rpm -q mysql-community-server # 出力例 Rocky Linux release 9.4 (Blue Onyx) mysql-community-server-8.4.5-1.el9.x86_64

OS:Rocky Linux 9.4(RHEL 9互換)
MySQL:MySQL 8.4.5 Community Server
ソースサーバー(source):192.168.1.10
レプリカサーバー(replica):192.168.1.20
前提:両サーバーにMySQLインストール済み・初期化済み・rootでログイン可能な状態

2. ネットワーク構成とポート疎通確認

レプリカがソースに接続するために、MySQL標準ポート(3306)の疎通が必要です。レプリカサーバー側から以下を確認します。

# レプリカサーバー(192.168.1.20)から実行 nc -zv 192.168.1.10 3306 # 疎通OKの場合の出力 Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Connected to 192.168.1.10:3306. Ncat: 0 bytes sent, 0 bytes received in 0.00s.

疎通できない場合はソースサーバーのfirewalldでポート3306を開放します。

# ソースサーバーで実行(レプリカのIPからのみ許可) sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.20/32" port port="3306" protocol="tcp" accept' sudo firewall-cmd --reload

ポートの疎通確認はnc以外にも複数の方法があります。Linux ポート確認の全コマンドも参考にしてください。

ソースサーバーの設定手順

1. my.cnfにbinlogとserver-idを設定する

ソースサーバーの /etc/my.cnf.d/mysql-server.cnf を編集します。

# /etc/my.cnf.d/mysql-server.cnf(ソースサーバー)に追記 [mysqld] # レプリケーション設定 server-id = 1 log_bin = /var/lib/mysql/mysql-bin binlog_format = ROW binlog_expire_logs_seconds = 604800 max_binlog_size = 100M

各オプションの意味は以下のとおりです。

server-id:レプリケーション参加サーバーの識別番号。ソースとレプリカで異なる番号を設定する(ソース=1、レプリカ=2等)
log_bin:バイナリログのファイルパス。指定するだけでbinlogが有効になる
binlog_format:ROWを推奨。STATEMENTは非決定論的関数(NOW()等)でレプリカとのデータ不整合が起きやすい
binlog_expire_logs_seconds:binlogの保持期間(秒)。604800秒=7日間

2. MySQLを再起動してbinlogを有効化する

# ソースサーバーで実行 sudo systemctl restart mysqld sudo systemctl status mysqld # 出力例(Active: active (running) を確認) * mysqld.service - MySQL Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; preset: disabled) Active: active (running) since Mon 2026-08-10 09:12:43 JST; 3s ago

3. レプリケーション専用ユーザーを作成する

ソースサーバーのMySQLにrootでログインし、レプリカ専用ユーザーを作成します。

-- ソースサーバーのMySQLで実行 -- レプリカのIPアドレス(192.168.1.20)からのみ接続を許可 CREATE USER 'repl'@'192.168.1.20' IDENTIFIED WITH mysql_native_password BY 'ReplPassword123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.20'; FLUSH PRIVILEGES;

MySQL 8.0以降のデフォルト認証プラグインは caching_sha2_password です。レプリカとの互換性を確認した上で認証プラグインを選択してください。

4. ソースのバイナリログ位置を記録する

binlogポジション方式では、この時点のソースのbinlogファイル名とポジションをレプリカに教える必要があります。データ整合性を保つため、一時的に書き込みをロックします。

-- ソースサーバーのMySQLで実行 FLUSH TABLES WITH READ LOCK; SHOW BINARY LOG STATUS; -- 出力例 +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000003 | 897 | | | +------------------+----------+--------------+------------------+

`File` と `Position` の値をメモします(上例では mysql-bin.000003 と 897)。このMySQLセッションを切断せずに維持したまま、次のレプリカ設定作業に進みます。セッションを閉じるとロックが解除されます。

レプリカサーバーの設定手順

1. my.cnfにserver-idを設定する

レプリカサーバーの /etc/my.cnf.d/mysql-server.cnf を編集します。

# /etc/my.cnf.d/mysql-server.cnf(レプリカサーバー)に追記 [mysqld] server-id = 2 relay_log = /var/lib/mysql/relay-bin read_only = ON

server-id:ソースと異なる番号(ここでは2)
relay_log:ソースから受信したbinlogを一時保存するリレーログのパス
read_only:レプリカへの直接書き込みを防ぐ。アプリケーションが誤って書き込んでソースとの同期が崩れるのを防止できる

設定後にMySQLを再起動します。

sudo systemctl restart mysqld

2. CHANGE REPLICATION SOURCEでソースを指定する

レプリカサーバーのMySQLにrootでログインし、ソースの情報を設定します。先ほどメモしたbinlogのファイル名とポジションを使います。

-- レプリカサーバーのMySQLで実行 CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.10', SOURCE_USER='repl', SOURCE_PASSWORD='ReplPassword123!', SOURCE_LOG_FILE='mysql-bin.000003', SOURCE_LOG_POS=897;

3. レプリケーションを開始してSTATUSを確認する

-- レプリカサーバーのMySQLで実行 START REPLICA; SHOW REPLICA STATUS\G

正常に動作している場合の出力(抜粋)は以下のようになります。

-- SHOW REPLICA STATUS\G の出力(成功時・抜粋) Replica_IO_Running: Yes Replica_SQL_Running: Yes Source_Host: 192.168.1.10 Source_User: repl Source_Port: 3306 Source_Log_File: mysql-bin.000003 Read_Source_Log_Pos: 897 Seconds_Behind_Source: 0

Replica_IO_Running: YesReplica_SQL_Running: Yes の2つがYesになっていれば、レプリケーションは正常に動作しています。

ソースサーバーのロックを解除します。

-- ソースサーバーのMySQLで実行(FLUSH TABLES WITH READ LOCKのセッション) UNLOCK TABLES;

GTIDモードでレプリケーションを設定する場合

GTID方式を使う場合は、my.cnfの設定とCHANGE REPLICATION SOURCEのオプションが変わります。

1. ソース・レプリカ両方のmy.cnfにGTID設定を追加する

# ソース・レプリカ両方の /etc/my.cnf.d/mysql-server.cnf に追記 [mysqld] gtid_mode = ON enforce_gtid_consistency = ON

両サーバーのMySQLを再起動します。

2. GTIDモードでCHANGE REPLICATION SOURCEを実行する

GTIDモードではbinlogのファイル名とポジションの指定が不要です。`SOURCE_AUTO_POSITION=1` を指定するだけで、レプリカが必要なGTIDを自動的に判断して取得します。

-- レプリカサーバーのMySQLで実行(GTIDモード) CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.10', SOURCE_USER='repl', SOURCE_PASSWORD='ReplPassword123!', SOURCE_AUTO_POSITION=1; START REPLICA; SHOW REPLICA STATUS\G

GTIDモードでは `Retrieved_Gtid_Set` と `Executed_Gtid_Set` が表示されます。同期が完了していればこの2つの値が一致します。

動作確認|ソースへの書き込みがレプリカに反映されるか

ソースにデータを書き込み、レプリカに反映されるかを確認します。

-- ソースサーバーのMySQLで実行 CREATE DATABASE repl_test; USE repl_test; CREATE TABLE check_table ( id INT AUTO_INCREMENT PRIMARY KEY, val VARCHAR(50), created_at DATETIME DEFAULT NOW() ); INSERT INTO check_table (val) VALUES ('test_row_001'); SELECT * FROM check_table; -- 出力例 +----+--------------+---------------------+ | id | val | created_at | +----+--------------+---------------------+ | 1 | test_row_001 | 2026-08-10 09:35:12 | +----+--------------+---------------------+

-- レプリカサーバーのMySQLで実行(数秒後) USE repl_test; SELECT * FROM check_table; -- 出力例(ソースと同じデータが確認できる) +----+--------------+---------------------+ | id | val | created_at | +----+--------------+---------------------+ | 1 | test_row_001 | 2026-08-10 09:35:12 | +----+--------------+---------------------+

レプリカ側に同一データが表示されれば、レプリケーションは正常に稼働しています。

トラブルシュート|よくあるエラーと対処法

Replica_IO_Running: No になる場合

IOスレッドがソースに接続できていません。`SHOW REPLICA STATUS\G` の `Last_IO_Error` を確認します。

よくある原因と対処:

Host ... is not allowed to connect:ソースでのユーザー作成時にIPアドレスが正しく指定されているか確認する
ポート疎通なし:ソースのfirewalldルールとbind-address設定を確認する(my.cnfに bind-address = 0.0.0.0 が必要な場合がある)
認証プラグイン不一致:caching_sha2_passwordとmysql_native_passwordの組み合わせを確認する

Replica_SQL_Running: No になる場合

SQLスレッドがレプリカでのSQL実行に失敗しています。`Last_SQL_Error` を確認します。

-- エラー確認 SHOW REPLICA STATUS\G -- 出力例(エラー箇所のみ抜粋) Last_SQL_Error: Error 'Duplicate entry '1' for key 'PRIMARY'' on query. ...

`Duplicate entry` エラーはレプリカ側に既存データがある場合に発生します。レプリカのデータをソースのdumpで初期化してからレプリケーションを再設定するのが確実な解決策です。

Seconds_Behind_Source が増え続ける場合

レプリカのSQL実行がソースの更新速度に追いついていません。原因はほぼレプリカ側のディスクI・O性能またはCPU不足です。`SHOW REPLICA STATUS\G` で `Relay_Log_Space` を確認し、リレーログが溜まっていればサーバースペックを見直します。

本記事のまとめ

MySQLのレプリケーション構築において押さえるべきポイントをまとめます。
項目 設定・確認ポイント
ソースのmy.cnf server-id=1, log_bin, binlog_format=ROW
レプリカのmy.cnf server-id=2, relay_log, read_only=ON
レプリカユーザー作成 GRANT REPLICATION SLAVE ON *.* TO ...
binlogポジション確認 SHOW BINARY LOG STATUS(MySQL 8.0以降)
レプリカ接続設定 CHANGE REPLICATION SOURCE TO ...
GTID方式の追加設定 gtid_mode=ON, SOURCE_AUTO_POSITION=1
正常動作確認 SHOW REPLICA STATUS\G でIO/SQL両方がYes
MySQL 8.4以降は旧コマンド(CHANGE MASTER TO等)が完全に廃止されています。新しいコマンド体系で設定することを意識するだけで、ネット上の古い情報による混乱の大半は解消できます。

レプリケーションが動き始めたら、次のステップはフェイルオーバーの手順確認やアプリケーション側でのread/write分離です。binlogとGTIDの基本を押さえておくと、その先の構成変更もスムーズに進みます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアがレプリケーションを含むサーバー管理の実践スキルを教えます。
Linux Master Pro Seminar の詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。