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

重要: MASTER_LOG_FILE と MASTER_LOG_POS の値は必ずマスターで実行した SHOW MASTER STATUS の出力を使ってください。値を間違えるとデータ不整合を招く可能性があります。

前提条件

マスター（server1）でレプリケーション用ユーザー（例: slave_user）を作成し、REPLICATION SLAVE 権限を付与していること。
マスター側で SHOW MASTER STATUS を実行し、ログファイル名とポジションをメモしていること。
スレーブ（server2）上にマスターの証明書（ca-cert.pem、client-cert.pem、client-key.pem）が配置されていること。
ネットワークでマスターへ接続可能であること（ファイヤウォール/セキュリティグループの設定確認）。

4 スレーブの設定

server2 にログインして、/etc/mysql/my.cnf の [mysqld] セクションに以下の設定があるか確認します。

server2:

vi /etc/mysql/my.cnf

| [...] server-id=2 master-connect-retry=60 replicate-do-db=exampledb [...] |

サンプルのように server-id はマスターとは異なる一意の数値にしてください（例: マスターが 1 ならスレーブは 2）。

スレーブ設定反映のため MySQL を再起動します。

/etc/init.d/mysql restart

空のデータベースを作成

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

mysql -u root -p

CREATE DATABASE exampledb;
quit;

ダンプのインポート

マスター上で取得したスナップショット（snapshot.sql）をスレーブに流し込みます。まずスレーブの SQL スレッドを停止します。

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

ダンプの読み込みが完了したら MySQL に接続し、マスター情報で CHANGE MASTER を実行します。ここで使う MASTER_LOG_FILE と MASTER_LOG_POS の値はマスター上の SHOW MASTER STATUS の出力から取得したものに置き換えてください。

mysql -u root -p

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=106, 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: スレーブ上に置いた証明書へのパス

注意: パスワードをコマンドラインに直接置くと履歴に残るなどのリスクがあります。運用手順ではファイルや環境変数、より安全な秘密管理方法を検討してください。

スレーブの開始と状態確認

START SLAVE;

SHOW SLAVE STATUS \G

次の 2 つのフィールドが必ず ‘Yes’ になっていることを確認します: Slave_IO_Running, Slave_SQL_Running。SSL を使っている場合は Master_SSL_Allowed, 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: 106
              Relay_Log_File: mysqld-relay-bin.000002
               Relay_Log_Pos: 251
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
           Slave_SQL_Running: Yes
               Replicate_Do_DB: exampledb
           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
Master_SSL_Verify_Server_Cert: No
               Last_IO_Errno: 0
               Last_IO_Error:
              Last_SQL_Errno: 0
              Last_SQL_Error:
1 row in set (0.00 sec)

mysql>

スレーブの MySQL シェルを終了します。

quit;

これで、マスターの exampledb に対する更新はスレーブの exampledb に複製されるようになります。実際に UPDATE / INSERT を試して同期を確認してください。

トラブルシューティング（短いインシデントランブック）

Slave_IO_Running または Slave_SQL_Running が ‘No’ の場合:
- /var/log/syslog と MySQL エラーログを確認する。
- SHOW SLAVE STATUS の Last_IO_Error, Last_SQL_Error を確認する。
- ネットワーク接続（ポート 3306）、TLS 証明書のパスやパーミッション、ユーザー認証を確認する。
レプリケーションが遅い / ストールしている:
- Seconds_Behind_Master を確認。大きい場合はネットワークや I/O 負荷を調査。
- 大きなトランザクションが原因か確認（長時間実行される UPDATE/ALTER 等）。
ログファイル/位置が合わない:
- マスターで正しい SHOW MASTER STATUS を再取得し、CHANGE MASTER TO で再設定する。
- 必要ならスレーブを STOP SLAVE; RESET SLAVE ALL; してやり直す（注意: relay log を消すためデータ整合性に注意）。
SSL 問題:
- 証明書の所有者・権限・パスを確認。
- Master_SSL_Verify_Server_Cert の設定が No のままなら、証明書検証を有効化する方針を検討。

ロール別チェックリスト

DBA
- マスターの binlog 設定を確認（log_bin, server-id, binlog_format）。
- レプリケーションユーザーに適切な最小権限を付与。
- 定期的な差分チェックをスケジュール。
システム管理者
- 証明書の配布と更新、自動ローテーションを担当。
- ファイアウォールルールとバックアップを管理。
開発者
- レプリケーションへ与える影響がある大きな DDL 操作時は DBA と調整。

ミニ手法（短い手順書）

マスターで SHOW MASTER STATUS を実行し、File と Position を記録。
マスターのデータをダンプし（FLUSH TABLES WITH READ LOCK 推奨）、スナップショットを作成。
スレーブ上に空データベースを作成してダンプをインポート。
スレーブで CHANGE MASTER TO を実行（SSL パラメータ含む）。
START SLAVE → SHOW SLAVE STATUS で状態を確認。

決定フローチャート（簡易）

flowchart TD
  A[開始: スレーブを設定する] --> B{マスター情報あり?}
  B -- yes --> C[ダンプ取得/スナップショット]
  B -- no --> Z[マスターで SHOW MASTER STATUS 実行]
  C --> D[スレーブに空DBを作成]
  D --> E[ダンプをインポート]
  E --> F[CHANGE MASTER TO を実行]
  F --> G[START SLAVE]
  G --> H{Slave_IO/SQL Running?}
  H -- yes --> I[完了]
  H -- no --> J[ログ確認・証明書/接続確認]