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なら正常動作している
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
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 |
構築前の準備|サーバー構成と前提条件
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
・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.
# ソースサーバーで実行(レプリカの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
ソースサーバーの設定手順
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;
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 | | | +------------------+----------+--------------+------------------+
レプリカサーバーの設定手順
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
・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
ソースサーバーのロックを解除します。
-- ソースサーバーの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
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
動作確認|ソースへの書き込みがレプリカに反映されるか
ソースにデータを書き込み、レプリカに反映されるかを確認します。-- ソースサーバーの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. ...
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 |
レプリケーションが動き始めたら、次のステップはフェイルオーバーの手順確認やアプリケーション側でのread/write分離です。binlogとGTIDの基本を押さえておくと、その先の構成変更もスムーズに進みます。
Linux Master Pro Seminar の詳細を見る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Amazon DynamoDBの設計入門|パーティションキー設計とグローバルテーブルによるマルチリージョン冗長化
- この記事の属するカテゴリ:AWS(Amazon Linux)・データーベース管理へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます