[MySQL] レプリケーションしてみた

定期的にmysqldumpとかでバックアップするのもイイんだけど、確実性を求めるならやっぱレプリケーションだろうと思いやってみた。
ちなみに定期的にmysqldumpするのは間違って更新しちゃったり消しちゃった的な時には有用なのでやっとくことに越したことはないです。

MySQLのレプリケーションって?

簡単に説明すると、バックアップを取りたいサーバー(マスター)とバックアップ先のサーバー(スレーブ)を用意して、マスターが更新される度に同じ内容でスレーブを更新する仕組みです。更新はほぼリアルタイムに行われるため、更新系はマスターで、参照系はスレーブでやるとかそういう負荷分散的な使い方ができます。
スレーブは複数にしたり、そのスレーブをマスターとして更に多段にスレーブをつなげることもできます。
ただ、複数のマスターをバックアップするスレーブとかはできないです。(物理的に1台のサーバーに複数のMySQLを立ち上げてスレーブにするってのはアリですが)

手順

レプリケーションユーザー作成

まずレプリケーション用のユーザーを用意します。
これはスレーブからマスターにアクセスする用に使うユーザーで、スレーブから接続できるように設定する必要があります。
んでセキュリティー的にレプリケーションの権限だけにしたほうがよいです。
マスターサーバーで以下を実行

mysql>GRANT REPLICATION SLAVE ON *.* TO ‘hoge_rep’@'スレーブのIP’ IDENTIFIED BY ‘hoge_password’;

ちなみにデフォルトで外部サーバーからmysqlに接続できないように設定されている場合があるので、my.cnfのbind-address設定を確認したほうがよいです。

bind-address = 127.0.0.1

とかなってたら自分自身からしかアクセス出来ませんのでコメントアウトするなりしてください。

マスターサーバーとスレーブサーバーの設定

マスターのバイナリログをスレーブが取得しにきて同期する仕組みなのでバイナリログを有効化擦る必要がありますので以下を追記する(コメントアウトされてたら有効にする)
またマスターとスレーブの文字コードが異なるとまずいことになるので明示的に設定したほうがよいです。
特定のDBのみレプリケーションしたい場合はbinlog_do_dbやbinlog_ignore_dbを設定すればおkです。

[mysqld]
server-id=11111
log_bin=/var/log/mysql/mysql-bin.log
default-character-set=utf8
binlog_do_db=hogehoge_database

[mysql]
default-character-set=utf8

server-idは何でも、スレーブとかぶらなければおkです。
基本的にスレーブ側はserver-idを設定するだけで良いのですが、レプリケーションしたいDBを限定するにはreplicate-do-dbやreplicate-ignore-dbを指定します。ただし、バイナリログを取得してから対象のDBを絞り込むため、ネットワークのトラフィック量は減りません。そのためネットワークの負荷を下げたい場合はマスター側でbinlog-do-dbを設定したほうがよいです。

[mysqld]
server-id=22222
default-character-set=utf8
replicate-do-db=hogehoge_database

[mysql]
default-character-set=utf8

ただし、スレーブをマスターにして更にスレーブをぶら下げたいときは

[mysqld]
server-id=22222
default-character-set=utf8
replicate-do-db=hogehoge_database
log_bin=/var/log/mysql/mysql-bin.log
log_slave_updates

と書く必要があります。

設定が終わったらmysqlは再起動してください。

データの複製

差分で同期していく仕組みなのでレプリケーションを開始する時には全く同じデータである必要があります。そのためマスターのデータをスレーブにコピーします。
ファイルをrsyncとかでコピーしても大丈夫だとは思いますが、普通にmysqldumpを使ってみることにします。
この時、現在のログのファイル名と位置をメモしておきます。

mysql>FLUSH TABLES WITH READ LOCK;
mysql>SHOW MASTER STATUS;
+——————+———-+——————-+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+——————-+——————+
| mysql-bin.000028 | 2849935 | hogehoge_database | |
+——————+———-+——————-+——————+

で、この状態のまま別のターミナルでmysqldumpします

$mysqldump -r root -p hogehoge_database –lock-all-tables > hogehoge.sql

元のターミナルでロックを解除します

mysql>UNLOCK TABLES;

そして今度はスレーブでデータをインポートして、レプリケーションをスタートします。

$mysql -u root -p hogehoge_database < hogehoge.sql

mysql>CHANGE MASTER TO
MASTER_HOST=”master.example.com”,
MASTER_USER=”hoge_rep”,
MASTER_PASSWORD=”hoge_password”,
MASTER_LOG_FILE=”mysql-bin.000028″,
MASTER_LOG_POS=2849935;
mysql>START SLAVE;

以上でレプリケーションが開始されます。

参考ページ

MySQL レプリケーションのセットアップ手順

Filed under: MySQL — maesan 7:18 PM

[AWS] EBSブートについての覚え書き

エントリー[AWS] EC2マイクロインスタンスのベンチマークしてみたでも書いてましたが、EC2のマイクロインスタンスはEBSブートのAMIでしか使えません。今までinstance-storeのAMIしか使ったことが無かったので、イメージの保存〜リカバリーの勝手が分からずちょっと自分なりに調べてみたので覚え書きにする。

 

そもそもEC2って?

元々EC2ではEBSってのは無くて、instance-storeのみでサービスしてたらしいです。

AMIイメージから起動して使用する手順

  1. S3に保存されているAMIイメージを選択する
  2. クラウド上にイメージを展開する
  3. オンメモリでインスタンスが展開される。シャットダウンすると消える

起動しているインスタンスを永続化する手順

  1. インスタンスのイメージを作成する
  2. 作成したイメージをS3にアップロードして保存する

この辺の流れはシンガポールが追加されたAmazon EC2で遊んでみた[S3編]を参考にしてください。

S3はストレージサービスと言っても普通にマウントして使うようなやり方はできなくて、httpを使ってファイルを送受信するだけのシンプルなサービス(何せSimple Storage Service → S3ですからw)なので、インスタンスからマウントできるようなストレージサービスとしてEBS(Elastic Block Storage)ってのが提供されるようになったようです。

 

EBSについて

ではS3とは別のEBSって何かってことですが、EBSを使う流れは簡単にいうとこんな感じ

EBSの使い方

  1. サイズを指定してボリュームを作成する
  2. 作成したボリュームを起動中のインスタンスにアタッチする
  3. インスタンスでアタッチしたボリュームをマウントする

ココまではイイんだけど、じゃあEBSブートって何よ?ってのが疑問になったわけ。イメージ的にはシャットダウンしても消えないインスタンスが使えるようになるんだって思って、だいたい合ってました。

EBSブートのインスタンスが起動するまでの流れ

  1. EBSブート用のAMIから起動する
  2. 自動的にEBSボリュームが作成され、イメージが展開される
  3. EBSボリュームからインスタンスが起動する
  4. 終了するとstop状態でEBSボリュームが残る (設定でterminateにもできるので注意)
  5. terminateするとEBSボリュームが消える

インスタンスの状態にはrunningとterminateとstopってのがあって、terminateするとデータ全部消えちゃいます。EBSだとterminateしても消えないのかなって思ったけど残念ながら消えます><その代わりEBSにはstopって状態が存在して、stopにしておくとスナップショットをとって保存しておけます。また、stopならそこからもう一度起動することもできます。

 

スナップショットからAMIイメージを作成してリカバリーする方法

stopにしておけばデータは消えないのですが、同じインスタンスをもう1個立ち上げたいとか誰かにオレオレAMIを公開したいとかできないし、stopのままおいておくのもなんか気持ち悪いのでどうやってEBSブートAMIを作るのか調べました。
スナップショットはManagement Consoleからでも簡単にできるのですが、AMIイメージの作成はManagement Consoleからはできず、コマンドラインインターフェースを使う必要がありました。
実際の手順はこのページ「EC2においてEBS Snapshotでバックアップを取得しそれをリカバリする方法」がスゴくわかりやすかったです。

インスタンスの情報が以下でスナップショットの名前がsnap-xxxxxxxxとすると
Root Device: /dev/sda1
Kernel ID: aki-xxxxxxxx
RAM Disk ID: ari-xxxxxxxx 

コマンドはこんな感じ

#ec2-register -n イメージ名 -d ‘イメージの説明’ –root-device-name /dev/sda1 -b /dev/sda1=snap-xxxxxxxx -a i386 –kernel aki-xxxxxxxx –ramdisk ari-xxxxxxxx

*64bitの場合はi386をx86_64に

これでMy AMIにオレオレイメージが作成されましたのでいつでもインスタンスを立ち上げることができるようになりました。

Filed under: AWS,Internet — maesan 11:30 PM

[AWS] EC2マイクロインスタンスのベンチマークしてみた

いつの間にやらEC2にsmallインスタンスの更に下のmicroインスタンスってのが使えるようになったらしいので、ちょっとやってみた。

他のサービスと比較

まずは似たようなサービスと比較してみます。
AWSの東京リージョンも最近できましたが、前からシンガポール使ってたので、それ基準で。
VPSとEC2は違うものですが、値段的に同じくらいのさくらVPSとServersMan@VPSも表に入れてみた。

  スペック 初期費用(年) 料金/時間 料金/月間
EC2 スモール
(オンデマンド)
CPU:仮想1コア
メモリ:1.7GB
ストレージ:160GB*
0 $0.095 $68.4 (約5,700円)
EC2 マイクロ
(オンデマンド)
CPU:仮想1コア
メモリ:613MB
ストレージ:従量(EBS)
0 $0.025 $18 (約1,500円)
EC2 マイクロ
(リザーブ)
CPU:仮想1コア
メモリ:613MB
ストレージ:従量(EBS)
$54 $0.01 $7.2 (約600円)
さくらのVPS
512
CPU:仮想2コア
メモリ:512MB
ストレージ:20GB
0 980円
ServersMan@VPS
Standard
CPU:仮想2コア
メモリ:512MB
ストレージ:30GB
0 980円

*ただしシャットダウンすると跡形も無く消え去ります><

スモールはちょっと頭抜けてますが、マイクロのリザーブは初期費用入れるとだいたい980円くらいなのでさくらVPS 512やServersMan@VPS Standardとほぼぴったりな感じです。
ただ、EC2はデータの転送量に応じた料金がかかりますし、EC2のマイクロインスタンスはEBSブートのみなのでストレージ費用も別途かかります(月$0.1/GB+I/0に応じて)
そのためやっぱちょっと金額は他と比べるとかかっちゃいます。ただ、普通のVPSと違ってアクセスが集中した時でもある程度ブーストしてくれるのでその辺はクラウドの強みかなと思います。

ベンチマーク!

では皆さんも大好きなベンチマーク結果をw
ベンチマークはAWS, さくらVPS, hetemlでベンチマークしてみたと同じくPHPspeedでやってみました。
アレから時間も経ってるので、スモールとさくらVPSも再計測してみました+ServersMan@VPSも最近使い始めたのでそれもまとめてみました。

  EC2 micro
EBS
EC2 small
instance-store
さくらVPS
512
ServersMan@VPS
Standard
Synthetic PHP BenchMark 3,267 1,262 2,507 1,693
Synthetic MySQL BenchMark 13,748 5,234 11,072 5,168
Synthetic Read/Write BenchMark 865 792 1,406 901
Real World PHP BenchMark 2,639 1,320 4,659 3,090
Real World PHP & MySQL BenchMark 838 994 2,179 1,287
Server BenchMark 1,415 969 2,548 1,300

まとめ

いや、何かの間違いと思いたいのですが、EC2のsmallが一番しょぼいってどうよ?w
何かもう全部マイクロインスタンスに変えてやろうかと思ってしまったわ><
ちなみにsmallとmicroは同じAMIで、instance-storeで使ってたAMIをEBSに変換してmicroで使ってみました。
(この辺はまた別エントリーで書いてみます)
EBSブートの方がinstance-storeよりもIO性能が低いってAWSのページには書いてあったのですが、全然変わらないというかむしろ逆転している感が漂っています。。。

相変わらずさくらVPSがスゴすぎるのはいうまでもない感じですが、ServersMan@VPSが意外と健闘している感じがします。実際使ってみるとServersMan@VPSはたまに引っかかる感じというか、遅いと感じる時があるのですが、ベンチマークとってみるとあまり目立ってばらついては無かったです。

一番ばらつきが大きかったのがEC2のmicroでした。短期ブーストってAWSの説明に書いてあったけど、いざという時は瞬発力を発揮してくれるのかもしれないですね。

まぁ取りあえずさくらのVPS
使っとけば間違いは無いってことですかね?W



Filed under: AWS,Internet,MySQL,PHP — maesan 12:36 AM
 iTunes Store(Japan)
 iTunes Store(Japan)
 iTunes Store(Japan)
 iTunes Store(Japan)
 iTunes Store(Japan)