datchの日記

気がついたら社会人。気になる技術的なことについて少しずつ書いていけたらと思っております。

【Sunrise2nd 復習】レプリケーション

どうも、先日人生初めてのスノーボードに行って全身筋肉痛になりながら東京に行きました。

スノーボードが終わった後には体が動かせなくなる、なんて大袈裟でしょ!

と思って舐めて掛かったら、あんなに辛いスポーツだとは思わなかったです。

一挙手一投足、全ての動作が億劫になり、痛みを伴うようになった。

さて、話を戻して前回はCentOSの導入からしっかりやろうと思ったのですが、現在VOYAGE GROUPインターンシップ「Sunrise」の後日勉強会である「Sunrise2nd」というMySQLの勉強会に参加するため、東京に来ています。

実機もない状態で記事を書くのも疑問に思ったことを手元で動かしながら確認出来ないので、せっかくですから復習ついでに今まで習ったことを今回から数回に分けて記事を書いていこうと思います。


「Sunrise2nd」で使用しているMySQLの参考書

参考書は上記の本を使用している。

あまり内容を書きすぎると色々と問題にもなるので、もっと内容を深く知りたい方は上の広告をわざわざクリックして飛ばなくてもいいので、買って読んでみることをオススメします。

現在まで4回の講義が行われているが、最初の講義には参加出来なかったので二回目から。

レプリケーション

2回目の講義はSunriseでも頻繁に出てきた技術単語、レプリケーションをどのようにオペレーションで準備し、どのような問題があるか、という点を触れていった。

MySQLレプリケーションの概要

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

ここで偉大なるWikipedia, IT用語辞典を見てみよう。

Wikipedia
レプリケーション - Wikipedia


IT用語時点:
レプリケーションとは 〔 リプリケーション 〕 〔 複製 〕 - 意味/解説/説明/定義 : IT用語辞典

上記の2つでもある程度分かると思うが、一台の「マスター」に対して変更を加えると、1台、もしくは複数台の「スレーブ」にその変更が反映される。

そういった動作が提供される仕組みだ。

レプリケーションの役割

主に以下の様な効果が期待されている。

  • 検索の負荷分散、それに伴う更新性能の向上
  • バックアップ・リカバリの手段として利用可能
    「マスター」に障害が発生した場合は、「スレーブ」を「マスター」に変更することで平均復旧時間(MTTR)を短くすることが出来る
レプリケーションの基本用語
  • 片方向
    マスターからスレーブに対して変更は通知されるが、スレーブへの変更はマスターへ通知されない。
    そのため、スレーブに対して更新を行うとマスターとスレーブ間での整合性が崩れることになる。
  • 双方向(マルチマスター)
    片方向に対し、スレーブへの更新もマスターに反映される。MySQLでは、1つのインスタンスがマスターとスレーブを兼用できるので、それを活かして双方向にすることが出来る。
  • 非同期レプリケーション
    マスターからスレーブへの情報の更新が非同期で行われる。
    そのため、常にスレーブの情報が最新であるという保証はない。
  • 同期レプリケーション
    非同期に対して、更新が即座にスレーブへ反映され、スレーブの更新の途中はロックされるため、常に最新のデータをスレーブに対して取得する事が出来る。
MySQLレプリケーションの仕組み

MySQLでは単純に説明すると以下の手順でマスターからスレーブへの情報を反映させる仕組みを作っている。

  1. マスターで生成されたバイナリログをスレーブに転送
  2. 1.のバイナリログにあるSQL文をスレーブで実行
  3. 2.によってマスターとスレーブの同期が完了

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

初期化パラメータファイルの設定

1. 初期化パラメータファイルの設定
[master]
/etc/my.cnfに以下の記述を追記。

server_id=1

[slave]
同様に/etc/my.cnfを

server_id = 2  
relay_log= mysql-relay-bin  
log-slave-updates  
replicate-do-db = test

2. インスタンスの起動
[master & slave]
mysqlを再起動

service restart mysql

3. スレーブからの接続用アカウントの作成
[master]

# IPアドレスはスレーブがあるサーバのIP
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replicator'@'XXX.XXX.XXX.XXX' IDENTIFIED BY 'replicator'; 

4.ポジションの確認
[master]

show master status;

以下の様な情報が表示される。

+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| mysql-bin.003 | 73       | test         | manual,mysql     |
+---------------+----------+--------------+------------------+

5.レプリケーションの設定
[slave]
show master status で得られた

  • XXX.XXX.XXX.XXXにmasterのIPアドレス
  • mysql-bin.XXXXXXをmaster_log_file
  • master_log_pos=YYYを取得したPosition

を設定する。

change master to  
    master_host = 'XXX.XXX.XXX.XXX',  
    master_user='replicator',  
    master_password='replicator',  
    master_port =3306,  
    master_log_file='mysql-bin.XXXXXX',  
    master_log_pos=YYY;  

5'. エラーではないことの確認
[master]

show processlist;

2個のsystemuserが存在すること。
[slave]

show processlist;

1個のreplicatorが存在すれば大丈夫。

6. レプリケーション開始
[slave]

start slave

エラーが出なければレプリケーションの設定を再確認。

7. レプリケーションステータス確認
[slave]

show slave status\G

Slave_IO_Runnning,Slave_SQL_RunningがYesとなっていること。

ちなみに以下のように表示される。

*************************** 1. row ***************************
       Slave_IO_State: Waiting for master to send event
          Master_Host: localhost
          Master_User: root
          Master_Port: 3306
        Connect_Retry: 3
      Master_Log_File: gbichot-bin.005
  Read_Master_Log_Pos: 79
       Relay_Log_File: gbichot-relay-bin.005
        Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
      Replicate_Do_DB:
  Replicate_Ignore_DB:
           Last_Errno: 0
           Last_Error:
         Skip_Counter: 0
  Exec_Master_Log_Pos: 79
      Relay_Log_Space: 552
      Until_Condition: None
       Until_Log_File:
        Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
      Master_SSL_Cert:
    Master_SSL_Cipher:
       Master_SSL_Key:
Seconds_Behind_Master: 8

レプリケーションの動作確認

事前に空のtestデータベースが作成されている前提で話を進める。

テーブルの確認

[slave]

use test;
show tables;

[master]
use test;
show tables;
|

お互いテーブルがないことを確認。

テーブルの作成

[master]

create table test(id int);
select * from test;

[slave]

show tables;
select * from test;

マスターとスレーブの結果が一致することを確認。
また、スレーブの中にcreate tableをしてないのにも関わらずtableが作成されていることを確認。

データの挿入

[master]

insert into test values(10);
select * from test;

[slave]

select * from test;

マスターに挿入したデータがスレーブに反映されていることを確認。

レプリケーションの遅延

最初の用語説明で記述したように非同期レプリケーションの場合は遅延が発生してしまう。

ここで詳細なオペレーションは省くが、ネットワークの状況やトランザクションが大きい場合では

レプリケーションの更新が反映されるのが遅くなり、Select句で古い情報を取得してしまう可能性があります。

最後に

最後まで読んで頂きありがとうございました。

1回の内容でも講義が1~2時間あったので大分ボリュームが出ましたね。

次回は「トランザクション」についてです。