MySQL スレーブ設定ガイド（SSL対応）

概要

このドキュメントは、MySQL レプリケーションで「スレーブ」を設定し、SSL 経由でマスターと接続するまでの手順を分かりやすく説明します。短い定義: レプリケーションの「スレーブ」はマスターのデータ変更を複製するサーバーです。

重要: server-id はマスターと重複しない一意の数値にしてください。

前提条件

マスター（server1）がバイナリログを有効にしていること。
レプリケーション用ユーザー（例: slave_user）をマスターで作成し、REPLICATION SLAVE 権限を付与済みであること。
マスターで SHOW MASTER STATUS を実行し、ログファイル名と位置（MASTER_LOG_FILE, MASTER_LOG_POS）を控えてあること。
スレーブ側に SSL 証明書（ca-cert.pem, client-cert.pem, client-key.pem）を配置済みであること（SSL を利用する場合）。

手順（ステップごと）

1) /etc/my.cnf を編集

スレーブ（server2）で /etc/my.cnf を開き、[mysqld] セクションに以下の設定を含めてください：server-id、master-connect-retry、replicate-do-db。

server2:

vi /etc/my.cnf

| [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 ssl server-id=2 master-connect-retry=60 replicate-do-db=exampledb [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid |

重要: server-id の値はマスター（例: server1）と重複しないように設定してください。

2) MySQL を再起動

設定を反映させるために MySQL を再起動します：

/etc/init.d/mysqld restart

3) 空のデータベースを作成

レプリケーション対象のデータベース名（ここでは exampledb）をスレーブ上に空で作成します：

mysql -u root -p

mysql> CREATE DATABASE exampledb;
mysql> quit;

※ マスターのダンプをインポートする前に、スレーブ上に同名のデータベースが存在する必要があります。

4) ダンプをインポート（スナップショットを使う場合）

マスターのスナップショット（snapshot.sql）をスレーブにコピーしてから、以下を実行します：

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

インポート後、再び MySQL に接続します：

mysql -u root -p

5) CHANGE MASTER TO を実行

server1 で取得した SHOW MASTER STATUS; の値（MASTER_LOG_FILE, MASTER_LOG_POS）を使って、スレーブにマスター情報を設定します。以下は例です。必ずあなたが取得した値に置き換えてください。

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3096416, MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

各パラメータの意味:

MASTER_HOST: マスターの IP またはホスト名（例: 192.168.0.100）。
MASTER_USER: マスターで作成したレプリケーション用ユーザー。
MASTER_PASSWORD: そのユーザーのパスワード。
MASTER_LOG_FILE / MASTER_LOG_POS: SHOW MASTER STATUS が返すバイナリログ名と位置。
MASTER_SSL: SSL を使う場合は 1。
MASTER_SSL_CA / MASTER_SSL_CERT / MASTER_SSL_KEY: スレーブ上の証明書パス。

6) スレーブを開始

START SLAVE;

その後、状態を確認します：

SHOW SLAVE STATUS \G

期待する出力の重要な項目は次のとおりです：

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_SSL_Allowed: Yes（SSL を有効にした場合）
Master_SSL_CA_File / Master_SSL_Cert / Master_SSL_Key にパスが表示されること

例（抜粋）:

mysql> SHOW SLAVE STATUS \G
* 1. row *
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.100
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 3096416
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: exampledb
Last_Errno: 0
Last_Error:
Exec_Master_Log_Pos: 3096416
Relay_Log_Space: 235
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem
Master_SSL_Cert: /etc/mysql/newcerts/client-cert.pem
Master_SSL_Key: /etc/mysql/newcerts/client-key.pem
Seconds_Behind_Master: 0
1 row in set (0.00 sec)

終了したら MySQL シェルを抜けます：

quit;

これで、マスター上の exampledb での変更はスレーブの exampledb に複製されます。動作確認のためにマスターで簡単な INSERT/UPDATE を試してください。

トラブルシューティング（よくある問題と対応）

Slave_IO_Running が No の場合
- ネットワークの疎通（telnet MASTER_HOST 3306）を確認。
- マスターのホスト名や IP が正しいか確認。
- マスターのユーザーとパスワードが正しいか、GRANT 権限を確認。
- /var/log/syslog や MySQL のログを確認。
Slave_SQL_Running が No の場合
- relay log のエラーや SQL エラーが発生している可能性があります。SHOW SLAVE STATUS の Last_Error を確認。
- 必要に応じて SET GLOBAL sql_slave_skip_counter = 1; でスキップし、一時的に回避することもありますが、根本原因を調査してください。
SSL 関連の問題
- Master_SSL_Allowed が No の場合、CHANGE MASTER TO で MASTER_SSL=1 を正しく指定しているか確認。
- 証明書のパスとファイルの権限を確認。MySQL プロセスが読み取れる必要があります。

代替アプローチと拡張

GTID ベースのレプリケーション: MySQL の GTID を使うと failover 時の処理が簡単になります。GTID を導入する場合は設定変更と既存のバイナリログの管理が必要です。
レプリケーション形式の選択: STATEMENT／ROW／MIXED。アプリケーションの特性に応じて選んでください。ROW はデータ整合性が高い反面、ログ量が増えます。
レプリカチェーンや複数スレーブ: マスターから複数スレーブへ複製したり、スレーブを次のレプリカのマスターにすることが可能です。

役割別チェックリスト

DBA
- マスターの SHOW MASTER STATUS を実行してログ位置を記録。
- レプリケーションユーザーの権限を確認。
- バックアップとスナップショットの整合性を確保。
システム管理者
- /etc/my.cnf のバックアップを取り、server-id を設定。
- 証明書（CA/クライアント）の配置とファイル権限を確認。
- MySQL サービスの再起動とログ監視。
アプリケーションエンジニア
- レプリケーションによる遅延（Seconds_Behind_Master）を監視。
- スレーブに対する読み取りクエリの動作確認。

受け入れ基準

SHOW SLAVE STATUS の Slave_IO_Running と Slave_SQL_Running が共に Yes。
MasterSSL* のファイルパスが表示され、SSL 接続が有効になっていること（SSL を使う場合）。
マスター側で行ったテスト変更がスレーブに反映されること（Seconds_Behind_Master が安定して 0 に近いか監視対象の閾値内）。

テストケース（簡易）

マスター上でテーブルを作成し、スレーブに同じテーブルが作成されるか確認。
マスター上で INSERT を行い、スレーブに同じデータが現れるか確認。
マスターのバイナリログ位置を変えて（小さなトランザクションを発行）、スレーブが追従するか確認。

よくある失敗ケース（いつこの方法が向かないか）

ネットワークが不安定で頻繁に切断される環境では、relay log が肥大化しやすい。回復手順を用意してください。
レガシーアプリケーションでトランザクションの再生順序が厳密に必要な場合、ROW ベースにしても問題が残ることがあります。

ミニプレイブック（手順要約）

/etc/my.cnf に server-id 等を設定。2. MySQL 再起動。3. スレーブに空データベースを作成。4. スナップショットをインポート（必要時）。5. CHANGE MASTER TO を実行。6. START SLAVE、SHOW SLAVE STATUS で確認。

用語（1 行定義）

マスター: レプリケーションの変更を発行する MySQL サーバー。
スレーブ: マスターの変更を受け取り反映する MySQL サーバー。
バイナリログ: マスターが出力するトランザクション記録ファイル。

最後に一言

設定手順は簡潔ですが、SSL 証明書の配置やログ位置の取り扱いに注意が必要です。まずは小さなテスト更新で動作確認を行ってください。

リンク

MySQL: http://www.mysql.com/
CentOS: http://www.centos.org/

MySQL スレーブの設定（SSL レプリケーション）

概要