Posted at

MySQLレプリケーション再入門

More than 3 years have passed since last update.


はじめに

日々何となく使っているMySQLのレプリケーション機能ですが、レプリケーションの概念について、自分自身の再確認とこれから学ぶ方の少しでも参考になればと思い書くことにしました。

実際の設定などについては既にたくさんの良記事がありますので割愛します。


レプリケーションって何?


一言で

「データの複製を別のサーバーに持てる機能です。」

「複製」を直訳するとreplica(レプリカ)とかreplication(レプリケーション)になります。

これがMySQLにおいてデータの複製機能であるレプリケーションと呼ばれる所以です。

複製元となるサーバーを「マスター」(Master)

複製先となるサーバー「スレーブ」(Slave)

と呼びます。

イメージ

1.png

マスターで変更(INSERT,UPDATE,DELETEなど)があった場合に同じ情報をスレーブにも保持します。


マルチスレーブ構成

上記の例ではマスター1台に対してスレーブ1台の構成ですが、マスター1台に対して複数のスレーブを持ち、全てのスレーブに同じデータを複製する事が可能です。

イメージ

2.png

基本的にマスター1台に対してスレーブが複数、つまり1:nの関係でレプリケーションは成立します。

「マルチマスター」と呼ばれるマスターが複数存在する構成もありますが、今回は入門的な位置づけなので割愛します。


どうやってレプリケーションしてるの?

前項の「レプリケーションとは?」でざっくりとしたイメージは掴めたかと思いますので仕組みについて説明していきます。


どうやって複製を作るのか?

MySQLではバイナリログ(Binary Log)というファイルを介してマスター・スレーブ間でデータの同期を行います。


バイナリログはどういうファイル?

データベースに対する操作(INSERT,CREATEなど)が記録されているファイルです。

大ざっくりの動作説明ですが、このファイルがマスターで書き込まれ、スレーブでバイナリログに書き込まれた内容を実行します。

後ほど詳細な挙動を説明しますが、今の段階ではマスターでバイナリログが出来て、それを元にスレーブで処理が実行されてデータの複製が出来る。くらいに思っていてください。

イメージ(かなりざっくり)

3.png


バイナリログの種類

レプリケーションにおいて重要な役割を担うバイナリファイル。

このファイルには3種類の記録方式があります。

記録方式
説明

SBR
SQL文がバイナリログに記録

RBR
更新されたデータが記録

MBR
SBSとRBRが状況に応じて切り替わる

SBRについて

表に書いてるとおり、実行されるSQL文がバイナリログに記載されています。

「ステートメントベースレプリケーション」なんて呼ばれたりもします。

RBRについて

SBSと異なり、SQL文でなくてデータそのもををバイナリログに記録してスレーブとデータの同期を取ります。「行ベースレプリケーション」なんて呼ばれたりもします。

MBRについて

MBRはMixed Based Replicationの略です。

SBRとRBRをミックスする方式なのでこの名称がついています。

MySQL 5.1.12 以降は、このMBR(ミックス ベース レプリケーション)がデフォルトです。

どういう時にSBRとRBRが切り替わるのか?

例えばSBRでUUID()とかSYSDATE()を実行した場合、SBRではバイナリログにSQLが記録されて、そのままスレーブで実行するとマスターと異なる値が記録されてしまいます。

こういったUUIDとかSYSDATEとか実行のたびに結果が変わる場合はSQL文でなくデータそのもので同期を取る必要があるため、RBRでレプリケーション処理が実行されます。


レプリケーションの種類について


準同期か?非同期か?

マスターからスレーブにデータを複製する処理において、準同期非同期の2種類の同期方式があります。

準同期とは?

マスターでデータの更新が行われ、スレーブでも更新が行われた通知を受け取って同期の完了と判断します。

非同期とは?

準同期とは違い、スレーブでも更新が行われたか?の判定は行われません。

文字通りの非同期での実行になります。


準同期・非同期の特徴一覧

同期方式
メリット
デメリット

準同期
同期の精度が高く、障害発生時に直前の更新内容も保持が可能がある
非同期よりマスターの更新処理パフォーマンスが遅い

非同期
準同期よりマスターの更新パフォーマンス高い
同期の精度は準同期より低く、障害発生時に直前の更新内容が保持されていない可能性がある

同期イメージ(ざっくり)

doukiimg.png

こんな感じで準同期の場合はスレーブからの応答をもって同期完了します。


準同期でマルチスレーブ構成の場合どうなるの?

問題です

マルチスレーブ構成(1台のマスターに対して複数のスレーブで構成)において、このケースで準同期を選択していた場合「スレーブで更新が行われました」という通知が行われるわけですが、どういった挙動になるでしょうか?

こういう時↓

スクリーンショット 2015-02-07 17.30.17.png

①全てのスレーブが応答して準同期が完結する

②1台のスレーブが応答して準同期が完結する

③マルチスレーブでは準同期は利用できない

 

答え

答えは②です。

現行のMySQL5.6では1台スレーブの応答が返ればOKです。


おわりに

レプリケーションの入り口の入り口くらいですが、とにかく簡潔に書いてみました。

端折り過ぎてて至らない点あったら申し訳ないです。

MySQLはまだまだレプリケーション機能の強化をしていくようなので、アップデートや書き足りないと感じた点があれば追記していこうと思います。