非同期MySQLレプリケーションの設定：ステップバイステップガイド

MySQLレプリケーションは、高可用性、スケーラビリティ、および堅牢なバックアップ戦略を実現するための基本的な機能です。最も一般的なタイプである非同期レプリケーションでは、プライマリサーバー（マスター）に書き込まれたデータが、マスターがスレーブからのトランザクション確認を待つことなく、最終的に1つまたは複数のセカンダリサーバー（スレーブ）にコピーされます。

この包括的なガイドでは、MySQLを使用した標準的なマスター・スレーブ非同期レプリケーション設定のための詳細なステップバイステップチュートリアルを提供します。必要なサーバー設定の調整、ユーザー設定、およびデータ同期を初期化するための重要な手順について説明します。

前提条件と概要

設定を開始する前に、以下のものが揃っていることを確認してください。

稼働中のMySQLサーバーが2台（サーバーA：マスター、サーバーB：スレーブ）あること。
2台のサーバー間でネットワーク接続が確立されていること（通常、TCPポート3306が開いている必要があります）。
両方のMySQLインスタンスを設定し、my.cnfまたはmy.ini構成ファイルを変更するためのルートまたは管理アクセス権があること。

このガイドの目的のために、マスターサーバーのIPを192.168.1.100、スレーブサーバーのIPを192.168.1.101と仮定します。

フェーズ 1: マスターサーバーの設定

マスターサーバーは、すべてのデータ変更イベントをバイナリログファイルに記録するように設定する必要があります。スレーブはこのファイルから読み取ります。

ステップ 1: マスター設定ファイル (`my.cnf`) の編集

MySQL設定ファイル（通常は/etc/mysql/my.cnfまたは/etc/my.cnf）を見つけ、[mysqld]セクション内に以下のディレクティブを追加または変更します。

[mysqld]
# 1. このサーバーの一意のID (0より大きい必要があります)
server-id=1

# 2. バイナリロギングを有効にする
log-bin=mysql-bin

# 3. レプリケートするデータベースのリスト (オプションですが推奨)
# binlog-do-db=mydatabase

# 4. オプション: 接続にTCP/IPを使用することを確認する (テストに役立ちます)
# bind-address=0.0.0.0

注: server-id は、レプリケーション・トポロジーに参加するすべてのサーバーで一意である必要があります。

ステップ 2: MySQLの再起動とバイナリロギングの確認

設定ファイルを保存した後、マスターサーバーでMySQLサービスを再起動します。

# Debian/Ubuntu
sudo systemctl restart mysql
# RHEL/CentOS
sudo systemctl restart mysqld

MySQLコマンドラインインターフェースにログインし、バイナリロギングがアクティブであることを確認します。

SHOW VARIABLES LIKE 'log_bin';
-- 値は ON であるべきです

ステップ 3: レプリケーションユーザーの作成

レプリケーションには、スレーブが接続してバイナリログを取得するために使用する、特定の権限を持つ専用のユーザーアカウントがマスターサーバー上に必要です。このユーザーがスレーブのIPアドレス (192.168.1.101) からリモートで接続できることを確認してください。

CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';
FLUSH PRIVILEGES;

ステップ 4: 現在のマスター・ステータスの記録

続行する前に、スレーブが読み取りを開始すべきバイナリログ内の正確な位置（ファイルと位置）を確立する必要があります。このステップは同期にとって非常に重要です。

FLUSH TABLES WITH READ LOCK; -- 一時的に書き込みを停止します
SHOW MASTER STATUS;

-- 重要: これらの2つの値を控えてください:
-- File: mysql-bin.000001
-- Position: 1234

-- 初期スナップショットを取得する場合 (ステップ 6)、まだテーブルのロックを解除しないでください

フェーズ 2: スレーブサーバーの設定

ステップ 5: スレーブ設定ファイル (`my.cnf`) の編集

スレーブサーバーに一意のIDとオプションの設定を構成します。

[mysqld]
# このサーバーの一意のID (マスターとは異なる必要があります)
server-id=2

# オプション: 安全性のために推奨
read_only=1

# オプション: リレーロギングを有効にする
relay_log=mysql-relay-bin

変更を保存した後、スレーブサーバーでMySQLサービスを再起動します。

ステップ 6: 初期データ転送（スナップショット）

スレーブサーバーが空の場合、マスターの現在のデータ構造とコンテンツでデータを投入する必要があります。この初期スナップショットは、マスターテーブルがロックされている間に（ステップ4から）取得する必要があります。

マスターサーバーから、mysqldumpコマンドを実行します。ここでは、--master-data=2フラグを使用して、必要なCHANGE MASTER TOステートメントをダンプファイルに自動的に含め、ステップ7を簡素化します。

# マスターサーバーのコンソール/シェルで実行
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > master_dump.sql

# ここで、マスターのMySQL CLIに戻り、ロックを解除します
UNLOCK TABLES;

master_dump.sqlをスレーブサーバーに転送し、インポートします。

# スレーブサーバーのコンソール/シェルで実行
mysql -u root -p < master_dump.sql

ベストプラクティス: master-data=2を使用すると、ダンプの開始時に正しいバイナリログ位置の取得が自動化されるため、強く推奨されます。

フェーズ 3: レプリケーションの開始

ステップ 7: マスター接続の定義

スレーブサーバーのMySQLコマンドラインで、ステップ4で控えた値とステップ3で作成したユーザーに置き換えて、CHANGE MASTER TOコマンドを実行します。

CHANGE MASTER TO
    MASTER_HOST='192.168.1.100',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='secure_password',
    MASTER_LOG_FILE='mysql-bin.000001', -- ステップ 4 で記録したファイル
    MASTER_LOG_POS=1234;              -- ステップ 4 で記録した位置

ステップ 8: レプリケーションの開始と確認

接続パラメータを定義した後、スレーブのレプリケーションスレッドを開始します。

START SLAVE;

SHOW SLAVE STATUSコマンドを使用して、レプリケーションスレッドが正しく実行され、通信していることを確認します。

SHOW SLAVE STATUS\G

出力で以下の重要なフィールドを確認してください。

フィールド	期待される値	説明
`Slave_IO_Running`	`Yes`	スレーブはマスターに正常に接続しています。
`Slave_SQL_Running`	`Yes`	スレーブはデータベースにトランザクションを適用しています。
`Seconds_Behind_Master`	`0` または低い数値	レプリケーションの遅延を示します。すぐに0に近づくはずです。

Slave_IO_RunningまたはSlave_SQL_RunningのいずれかがNoを示している場合は、トラブルシューティングの手がかり（例：ファイアウォールの問題、認証情報の誤り、重複キー）について、Last_IO_ErrorまたはLast_SQL_Errorフィールドを調べてください。

トラブルシューティングとメンテナンスのヒント

レプリケーションエラーの処理

スレーブがエラー（例：重複するプライマリキーを挿入しようとする）に遭遇した場合、Slave_SQL_Runningスレッドは停止します。マイナーで重要でないエラーは、通常、以下を使用してバイパスできます。

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

警告: SQL_SLAVE_SKIP_COUNTERは慎重に使用してください。トランザクションをスキップすると、マスターとスレーブ間でデータの不一致（非一貫性）が発生する可能性があります。

一貫性の確認

非同期レプリケーションは効率的ですが、即時の整合性は保証されません。重要な環境では、Percona Toolkitのpt-table-checksumなどのツールを利用して、マスターとスレーブ間のデータ差異を定期的にチェックしてください。

バイナリログの管理

バイナリログは時間の経過とともにディスク容量を消費します。ディスクの使いすぎを防ぐために、マスター側でログの有効期限を設定してください。

[mysqld]
# 7日以上前のバイナリログを削除 (604800秒)
expire_logs_days=7