間違っている部分がありましたらご指摘いただけると幸いです。
レプリケーションとは?
マスタサーバの DB をサブのスレーブサーバに配布する仕組み。
負荷が高い参照処理はスレーブサーバを利用し、データの作成などの処理をマスタサーバで行う構成をリードレプリカ構成という。
レプリケーションの仕組み
スレーブの I/O スレッドが、マスターからのバイナリログの情報を受け取りその情報を一旦リレーログファイルに書き込む。
そして、SQLスレッドがそのリレーファイルから更新情報を読み取り、データベースに適用することで非同期的にスレーブのデータが更新される。
図で表すと下記のような流れになる。
バイナリログとは?
テーブル作成操作やテーブルデータへの変更などのデータベース変更を記述する「イベント」が格納される。
バイナリログを使用する目的は下記の2つ。
- スレーブサーバーにデータ変更のレコードを提供する。
- 特定のデータリカバリー操作時に使用する。バックアップをリストアした後、バックアップが実行された後に記録されたバイナリログ内のイベントが再実行される。
リレーログファイルとは?
スレーブのみに生成されるファイル。
ファイルの生成タイミングは、下記になる。
-
CHANGE MASTER
でマスターの変更が行われた時 -
RESET SLAVE
が行われた時
今回は、slaveの作成時に、CHANGE MASTER
を利用して masterの設定をしたので、そのタイミングでリレーログファイルが作成されたことになる。
個人的にハマったポイント
MySQL5.7は、デフォルトではバイナリログが無効になっているため、log-bin
オプションを追記して、バイナリログを有効化する必要があった。
この記述をしないままMASTER
指定をしたため、上手くレプリケーションができなかった。
ちなみに、MySQL8.0からはデフォルトでバイナリログが有効になっているらしい。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.1.6.4 バイナリロギングのオプションと変数
参考記事
MySQL 入門 レプリケーション編 - Qiita
MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.2.4 バイナリログ
第 53 回 リレーログファイルについて | gihyo.jp
第8回 MySQLのレプリケーション構成 | gihyo.jp
MySQLレプリケーションについて - DENET 技術ブログ
下記が今回のレプリケーションを作成したレポジトリになります。
https://github.com/hayura-k/mysql-replication
実際にレプリケーションをする際の操作は後で追記します