by shigemk2

当面は技術的なことしか書かない

サーバ/インフラを支える技術2 3 MySQLのレプリケーション

前回
サーバ/インフラを支える技術2 2 キャッシュサーバの導入 - by shigemk2

DBサーバがダウンしたり故障したりしたら、サービス停止に直結してしまう。
そのため、DBサーバが停止したときに、いかに速くDBサービスを復旧できるよ
うにするかを考える

DBサーバが停止するケースとして、

  • DBサーバのプロセス(mysqld)が異常終了した
  • ディスクがいっぱいになった
  • ディスクが故障した
  • サーバの電源が故障した

mysqldが異常終了した場合には、mysqlを再起動すればいい。
ディスクがいっぱいになったときは不要なデータを削除するか
容量を増やすと解決する。
しかし、サーバの電源が故障したときはどうだろう?
故障の修理は思いの外時間がかかるので、短時間でDBサービスを
復旧する方法を考えなくてはならない。

そこで必要となるのがレプリケーションというしくみである。
レプリケーションとはデータの複製のことで、ネットワークを経由して
データの複製をリアルタイムで取ることが可能となる。

DBのサーバを複数台用意して、データをレプリケーションすることで、
片方が故障しても短時間でDBサービスを再開できる。

レプリケーションの構成はマスタとスレーブからなる。
マスタはクライアントからの更新と参照を受け付け、
スレーブはマスタとの連携でデータの更新を行う。

MySQLでサポートしているレプリケーションは非同期である。
同期レプリケーションでも可能ではあるが、どちらも一長一短である。

また、レプリケーションSQL単位で行われる
ただorderd by句を伴わないlimit句がある場合、limit句で選ばれれる行では
マスタとスレーブでデータが変わる可能性があることに留意する

ただし、MySQL5.1.5以降では「行単位のレプリケーション」も可能となってい
る。


レプリケーションの構造

スレーブにはマスタから得た情報をリレーログに記録しつづけるI/Oスレッド
と、リレーログからひたすらSQLを実行しつづけるSQLスレッドの2種類がある。

また、マスタにはスレーブのリレーログに相当するバイナリログが存在する
読んで字の如しバイナリデータなのでmysqlbinlogで変換する必要があるが、データを更新す
る処理(select系は記録されない)がひたすら記録されている

さらに、レプリケーションはリズームが可能である
リズームするときに必要なマスタのホスト名、ログファイル名、ログファイル
中の処理したポイントのことを「ポジション情報」と呼び、master.infoに保
存れている。これはSQL文show slave statusで確認が出来る

レプリケーションの条件

  • マスタは複数のスレーブを持つことが出来る
  • スレーブが持てるマスタは1つだけ
  • すべてのマスタ、スレーブの中で一意なserver-idを指定しないといけない
  • マスタはバイナリログを出力しなければならない

レプリケーションはmy.cnfで設定できる
また、レプリケーションにはmysqldumpを実行したマスタのフルダンプだけで
はなく、ポジション情報も必要となる。

スレーブ(予定)のサーバからマスタ(予定)のサーバへアクセスしたのち、
slave startでレプリケーションが開始する。

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)