MySQLを運用していると、サービスの安定性やパフォーマンス向上を求めてレプリケーションの導入を検討する場面が出てきます。レプリケーションは、データベースの冗長化や読み取り負荷の分散を実現するための仕組みで、多くの企業で採用されている技術です。しかし、レプリケーションにはいくつかの方式があり、それぞれに特徴や注意点があるため、正しく理解しておくことが運用のカギとなります。本記事では、MySQLレプリケーションの基本から構築手順、運用時のポイントまでを体系的に解説します。
※本記事は MySQL 8.0.22 以降を主な対象として記載しています。用語は master/slave ではなく source/replica を使用します。
なお MySQL 8.4.0 以降では、START SLAVE / CHANGE MASTER TO / SHOW MASTER STATUS など、旧来の master/slave 系SQLが削除されました。以降は START REPLICA / CHANGE REPLICATION SOURCE TO / SHOW BINARY LOG STATUS などの source/replica 系SQLを使用してください（本記事でも以降は原則として source/replica 系SQLを記載しますが、MySQL 8.0 系を運用している場合は旧コマンドに読み替え可能です）。
MySQLレプリケーションの基本と種類
MySQLレプリケーションを活用するためには、まずその仕組みと種類を理解することが出発点となります。ここでは、レプリケーションの基本的な動作原理から、主要な同期方式、構成パターンまでを順に見ていきましょう。
レプリケーションの仕組み
MySQLレプリケーションとは、あるMySQLサーバ（ソース）のデータを別のMySQLサーバ（レプリカ）に複製し、同期させる機能のことです。この仕組みを使うと、ソースサーバに障害が起きた際にレプリカへ切り替えてサービスを継続したり、読み取り処理を複数のサーバに分散させたりできるようになります。
具体的な動作としては、ソースサーバがクライアントからの書き込み処理を実行すると、その内容がバイナリログというファイルに記録されます。レプリカサーバはこのバイナリログを受け取り、自身のリレーログに書き込んだ後、SQLスレッドがその内容を順番に適用していく流れです。こうして、ソースとレプリカのデータが同期された状態を維持できます。
非同期と準同期の違いを理解する
MySQLのレプリケーションには、大きく分けて非同期と準同期という2つの方式があります。非同期レプリケーションはMySQLの標準的な動作で、ソースサーバがトランザクションをコミットした時点で処理が完了したとみなされます。つまり、レプリカへの反映を待たずにソース側は次の処理に進めるため、書き込み速度への影響が少ないのが特徴です。
一方、準同期レプリケーションでは、ソースは少なくとも1台のレプリカがトランザクションイベントを受信し、ログに記録したことの確認を受けてからコミットします。なお、必要な確認数は設定により変更できます。
この仕組みにより、データ損失のリスクを低減できる反面、レプリカからの応答を待つ分だけ書き込みの遅延が発生しやすくなるというトレードオフがあります。
GTIDとバイナリログ方式の違い
レプリケーションの位置情報を管理する方法として、従来のバイナリログファイル名と位置（ポジション）による方式と、GTIDを使う方式があります。バイナリログ方式では、どのファイルのどの位置までレプリカが適用済みかをファイル名と数値で管理します。シンプルな構成では問題なく動作しますが、フェイルオーバー時にレプリカを再構成する際は手作業での位置調整が必要になることがあります。
GTIDはGlobal Transaction Identifierの略で、各トランザクションにユニークなIDを付与する仕組みです。どのトランザクションまで適用済みかをIDベースで追跡できるため、フェイルオーバーやレプリカの再構成が簡便になります。MySQL 5.6以降で利用可能となり、現在では新規構築時にGTIDを採用するケースが増えてきました。
レプリケーションの構成例を比べる
MySQLレプリケーションにはさまざまな構成パターンがあります。代表的なものを以下の表で整理しました。
| 構成パターン | 特徴 | 主な用途 |
| 1対1構成 | ソース1台とレプリカ1台のシンプルな構成 | 小規模システムのバックアップや障害対策 |
| 1対多構成 | ソース1台に複数のレプリカを接続 | 読み取り負荷分散や分析用途 |
| カスケード構成 | レプリカの下にさらにレプリカを接続する多段構成 | 大規模な読み取り分散やリージョン展開 |
| Group Replication | 複数台で高可用クラスタを構成し、単一プライマリ構成では自動プライマリ選出が可能。実務では3台構成がよく採用される | 高可用性が求められるミッションクリティカルなシステム |
構成を選ぶ際は、システムの規模や求められる可用性、運用体制を考慮して決定することが大切です。
MySQL レプリケーションのメリット
レプリケーションを導入することで得られる利点について、代表的なものを紹介していきます。
まず挙げられるのが、可用性の向上です。ソースサーバに障害が発生した場合でも、レプリカを昇格させることでサービスを継続できるため、シングルポイントオブフェイルを回避できます。特に24時間365日の稼働が求められるサービスでは、この冗長構成が安心材料になるでしょう。
次に、読み取り負荷の分散があります。書き込みはソースに集中させつつ、SELECTクエリを複数のレプリカに振り分けることで、データベース全体のスループットを向上させられます。アクセス数の多いWebサービスやSaaSでは、この構成が定番となっています。
さらに、バックアップや重い集計処理をレプリカ側で実行することで、本番環境への影響を最小限に抑えられます。分析基盤へのデータ連携やETL処理もレプリカ経由で行えば、ソースサーバのパフォーマンスを維持しやすくなります。災害対策として異なるリージョンにレプリカを配置し、大規模障害時に別拠点でサービスを復旧させる構成も取れるようになります。
MySQL レプリケーションのデメリット
一方で、レプリケーションにはいくつかの課題や注意点も存在します。導入前にこれらを把握しておくことで、トラブルを未然に防ぎやすくなります。
非同期レプリケーションの場合、ソースとレプリカの間にわずかな時間差（レプリケーション遅延）が生じることがあります。このため、書き込み直後にレプリカからデータを読み取ると、最新の情報が取得できないケースが起こり得ます。アプリケーション側で「更新直後はソースから読む」といった制御が必要になる場面もあるでしょう。
また、ソースに障害が発生したタイミングによっては、レプリカにまだ送信されていないトランザクションが失われる可能性があります。これはRPO（目標復旧時点）がゼロにならないことを意味しており、準同期やGroup Replicationを採用してもネットワーク分断などの条件下ではリスクが残ります。
運用面では、レプリケーションラグの監視やフェイルオーバー手順の整備など、一定のDB運用スキルが求められます。通常のソース・レプリカ構成では書き込みは単一ノードに集中するため、書き込み負荷のスケールアウトには向かないという点も考慮しておく必要があります。
MySQL レプリケーションの構築手順と設定
ここからは、実際にMySQLレプリケーション環境を構築する際の基本的な手順を解説します。
レプリケーションの設定方法は、ファイル／位置ベースで構成するか、GTIDベースで構成するかによって一部異なりますが、全体の流れを押さえておくことで初めてでも理解しやすくなります。
事前準備と要件のチェック
レプリケーションを構築する前に、source と replica の両方でいくつか確認しておくべき項目があります。
まず、MySQLのバージョンはできるだけ揃えておくことが推奨されます。バージョン差があると、利用できる機能やコマンド、バイナリログの扱いに違いが生じる可能性があるためです。
次に、source と replica がネットワーク的に疎通できることを確認します。あわせて、レプリケーション専用ユーザを作成する準備も必要です。運用上は root ユーザをそのまま使うのではなく、必要最小限の権限を持つ専用ユーザを用意することが望ましいでしょう。
また、source 側ではバイナリログ出力の設定と一意な server_id が必要です。replica 側でも、source と重複しない server_id を設定しておく必要があります。GTIDベースで構成する場合は、source / replica の両方で GTID 関連設定を有効にしておきます。
source を設定する手順
source 側では、まずレプリケーションに必要な設定を反映し、MySQLを再起動します。その後、レプリケーション用ユーザを作成し、必要な権限を付与します。
ファイル／位置ベースのレプリケーションを構成する場合は、続いて source 側のバイナリログ座標を確認します。
MySQL 8.0 系では SHOW MASTER STATUS; を使用できますが、MySQL 8.4 以降ではこのコマンドは削除されているため、SHOW BINARY LOG STATUS; を使用します。
このとき確認したバイナリログのファイル名と位置情報は、replica 側で複製開始位置を指定する際に必要になります。
replica を設定する手順
replica 側では、source と整合した初期データを取り込んだうえで、レプリケーション設定を行います。
一般的には、source から取得したバックアップやスナップショットを replica にリストアし、その状態を起点として同期を開始します。
ファイル／位置ベースで構成する場合は、CHANGE REPLICATION SOURCE TO コマンドで source への接続情報と、取得しておいたログファイル名・位置を指定します。設定後に START REPLICA を実行すると、replica は source のバイナリログを取得し、順次反映し始めます。
なお、replica 側でのバイナリログ出力は必須ではありません。ただし、カスケード構成にする場合や、フェイルオーバー後にそのサーバを新たな source として利用する可能性がある場合は、有効にしておくと運用しやすくなります。
GTIDを有効にして同期を行う
GTIDベースのレプリケーションを利用する場合は、source / replica の両方で GTID を有効にする設定が必要です。代表的な設定項目としては、以下のようなものがあります。
gtid_mode=ON
enforce_gtid_consistency=ON
GTIDを有効にした環境では、CHANGE REPLICATION SOURCE TO 実行時に SOURCE_AUTO_POSITION=1 を指定することで、ファイル名や位置を明示しなくても、自動的に同期位置を判断できるようになります。これにより、フェイルオーバーやreplica再構成の運用がしやすくなります。
ただし、SOURCE_AUTO_POSITION=1 は、ファイル名・位置を指定する方式と併用できません。どちらの方式で構成するのかを事前に整理したうえで設定することが重要です。
バイナリログとレプリケーション状態の確認方法
レプリケーションが正常に動作しているかどうかは、いくつかの確認コマンドで把握できます。
source 側では、SHOW BINARY LOG STATUS; を実行することで、現在のバイナリログの状態を確認できます。
replica 側では、SHOW REPLICA STATUS\G を実行し、I/OスレッドとSQLスレッドの状態、遅延状況、エラーの有無などを確認します。
主な確認ポイントは次のとおりです。
- Replica_IO_Running が正常に動作していること
- Replica_SQL_Running が正常に動作していること
- Seconds_Behind_Source が過度に増えていないこと
- エラーメッセージが出力されていないこと
replica は、source から受信したバイナリログを一度リレーログとして保持し、その内容を順次適用していきます。
そのため、Seconds_Behind_Source などの指標を確認することで、source に対してどの程度遅れているかを把握できます。
なお、SHOW REPLICA STATUS の実行には、運用ユーザに適切な権限が必要になる場合があります。
MySQLレプリケーションの運用と障害対応
レプリケーションは構築すれば終わりではなく、安定して動かし続けるための運用管理が欠かせません。ここでは、日々の監視で意識したいポイントや、障害が発生した際にどのように対応すべきかを、実務で役立つ形でわかりやすくまとめていきます。
監視すべき指標とおすすめツール
レプリケーションを安定稼働させるためには、いくつかの指標を定期的に監視することが有効です。特に注目すべき項目として、レプリケーション遅延（例：Seconds_Behind_Source）、I/OスレッドとSQLスレッドの状態、バイナリログやリレーログのディスク使用量などがあります。
監視ツールとしては、MySQL Enterprise MonitorやPercona Monitoring and Management（PMM）、Prometheus＋Grafanaの組み合わせなどが広く使われています。しきい値を設定してアラートを上げる仕組みを整えておくと、問題が発生した際に迅速に対応できます。
レプリケーション遅延の原因と対処方法
レプリケーション遅延が発生する原因はさまざまですが、代表的なものとしてソース側の書き込み負荷が高い場合、レプリカ側のリソース不足、ネットワークの帯域制限などが挙げられます。また、大量のデータを更新するバッチ処理やALTER TABLEのようなDDL操作もラグを引き起こしやすい要因です。
対処としては、レプリカのスペックを引き上げる、マルチスレッドレプリカを有効にして並列適用を行う、重いバッチ処理をオフピーク時間にスケジュールするなどの方法があります。根本的な原因を特定するためにはスロークエリログの分析も役立ちます。
データ不整合を検出して修復する
非同期レプリケーションでは、まれにソースとレプリカの間でデータの不整合が生じることがあります。これを検出するツールとしてpt-table-checksumが有名で、テーブル単位でチェックサムを比較し差分を洗い出せます。
不整合が見つかった場合は、pt-table-syncで差分を修復する方法が一般的です。ただし、本番環境での実行は慎重に行う必要があり、事前にテスト環境で動作確認することを推奨します。
フェイルオーバーとスイッチオーバの進め方
ソースサーバに障害が発生した際、レプリカをソースに昇格させて運用を継続するプロセスがフェイルオーバーです。計画的にソースを切り替える場合はスイッチオーバーと呼ばれます。GTIDを使っている環境では、どのレプリカが最も進んでいるかを確認しやすく、昇格対象を選びやすくなります。
手動でのフェイルオーバーはミスが起きやすいため、MHA（Master High Availability Manager）やOrchestrator、MySQL InnoDB Clusterなどのツールを活用して自動化している現場も多いです。定期的にフェイルオーバー訓練を実施しておくと、本番障害時にも落ち着いて対応できます。
セキュリティ対策とバックアップ運用のポイント
レプリケーション経路はネットワーク上でデータが流れるため、SSL/TLSによる通信暗号化を有効にすることが推奨されます。レプリケーション専用ユーザの権限を最小限に絞り、不要なアクセスを防ぐ設定も忘れないようにしましょう。
バックアップについては、レプリカからバックアップを取得することでソースへの負荷を避けられます。ただし、レプリケーション遅延がある状態でバックアップを取ると最新データが含まれない可能性があるため、バックアップ取得前にラグを確認する運用が望ましいです。
MySQLレプリケーションの設計・運用に不安がある方へ
レプリケーションは、構築できれば終わりではありません。
遅延対策、障害時の切り替え、監視設計、バックアップ、バージョンアップ時の整合性確認など、安定運用には継続的な知見が求められます。
株式会社パソナデータ&デザインでは、MySQLに関する設計・構築・運用・性能改善・アップグレードまで、幅広く支援するMySQLコンサルティングサービスを提供しています。
「レプリケーション構成が自社に合っているかわからない」
「障害時の切り替えや運用設計に不安がある」
「属人的な運用から見直したい」
そのようなお悩みがある場合は、ぜひ一度ご相談ください。
まとめ
本記事では、MySQLレプリケーションの基本的な仕組みから構築手順、運用時の注意点までを解説しました。レプリケーションは可用性向上や負荷分散に有効な技術ですが、適切な設計と継続的な監視が求められます。
- レプリケーションはバイナリログを使ってソースからレプリカへデータを複製する仕組み
- 非同期と準同期の違いを理解し、要件に合った方式を選択することが重要
- GTIDを活用するとフェイルオーバーやレプリカ再構成が容易になる
- レプリケーション遅延やデータ不整合を防ぐためには定期的な監視が欠かせない
- 専門的なサポートが必要な場合は外部パートナーの活用も検討する
まずは自社のシステム要件を整理し、適切なレプリケーション構成を検討してみてください。運用に不安がある場合は、専門家への相談も有効な選択肢となります。
