概要
- redis サーバーをレプリケーション環境で構築してみる
- バックアップとレストアについても試してみる
前回まで
以下を行った。
- ソースコードからコンパイルしてのインストール
- デーモンモードでの稼働
- データを書き出すディレクトリの設定
- 適当にデータを突っ込んでみる
今回は…
実運用を検討する上で、以下の点を検証してみる。
レプリケーションとクラスタリング
レプリケーションの設定
レプリケーションは比較的簡単に行える。スレーブ側の redis.conf に以下を記載し redis-server を起動する。
slaveof xxx.xxx.xxx.xxx 6379
正常に起動した場合には下記のようなログがスレーブ側に出力される。
[3938] 15 Jun 14:23:24.549 * Connecting to MASTER... [3938] 15 Jun 14:23:24.549 * MASTER <-> SLAVE sync started [3938] 15 Jun 14:23:24.552 * Non blocking connect for SYNC fired the event. [3938] 15 Jun 14:23:24.553 * Master replied to PING, replication can continue... [3938] 15 Jun 14:23:24.576 * MASTER <-> SLAVE sync: receiving 93 bytes from master [3938] 15 Jun 14:23:24.576 * MASTER <-> SLAVE sync: Loading DB in memory [3938] 15 Jun 14:23:24.576 * MASTER <-> SLAVE sync: Finished with success
マスター側のキーを確認してみる。
redis 127.0.0.1:6379> keys * 1) "q" 2) "b" 3) "huga" 4) "h" 5) "p" 6) "inokara" 7) "w" 8) "kappa" 9) "a" redis 127.0.0.1:6379> get inokara "ahoaho"
上記を元にスレーブ側でレプリケーションされた key value を確認してみる。
redis 127.0.0.1:6379> get inokara "ahoaho"
マスター側にデータを突っ込んでスレーブ側で key を指定してデータを取り出すスクリーンショット。
うん、簡単。
レプリケーションの疑問
レプリケーション動作に関して幾つか確認してみた。
スレーブを追加した場合、どの時点からのデータを同期してくれるのか？
- レプリケーションを開始するとマスター側のデータを遡って最初から同期が走る
- 大量のデータを持つマスターサーバーと同期する際には注意が必要
うっかりスレーブに書き込んでしまった場合の対処は？
[root@slave ~]# redis-cli redis 127.0.0.1:6379> set hoge aaaaaaaa (error) READONLY You can't write against a read only slave. redis 127.0.0.1:6379>
上記のように (error) READONLY You can't write against a read only slave. となり書き込むことが出来ない。これは redis.conf 内で以下のように指定がある為かと思われる。
slave-read-only yes
想定している運用で上記の設定を slave-read-only no とすることは無さそうだし、こうしておけば対処もヘッタクレもない。
スレーブに書き込みが発生した後で、改めてレプリケーションを再開した場合
- マスター側のデータで完全に上書きされる為、スレーブの書き込みは無効になる
同じキーを持つデータベースを同期した場合
- マスター側のキーが持つ値で上書きされる
バックアップとレストア
バックアップ（永続化）
バックアップに関しては
が参考になった。
永続化処理のコマンドとしては以下のようなコマンドがある。（一部抜粋）
| コマンド | 何をするか | 特徴 |
|---|---|---|
| save | データベースの保存 | すべてのデータセットをディスクに保存する。保存が完了するまでアクセス出来ない。 |
| bgsave | データベースの保存 | バックグラウンドで保存する。保存終了の確認は lastsave で行う。 |
| lastsave | bgsave の動作確認 |
bgsave が成功したかを確認出来る。結果は UNIX タイムで返ってくるので変換が必要。 |
実運用を考慮すると bgsave と lastsave を上手く利用してバックアップ環境を整える必要があるかと思われる。
以下、bgsave と lastsave を使ったバックアップ例。
レストア
バックアップで取得したデータベースファイルを置き換える方法でレストアしてみる。手順としては以下の通り。
bgsaveでバックアップしたファイルをリネームredis-serverを一旦再起動- 再起動後、
redis-cliでアクセスしデータが無いことを確認 - バックアップしたファイルを
dump.rdbと再びリネームしてredis-serverを再起動 - 再起動後、
redis-cliでアクセスし既存のデータを確認
以下は上記の手順を元にした簡単なレストア例。
まとめ
- レプリケーションもバックアップも比較的簡単に行える
slave-read-onlyでスレーブにデータを書き込んでしまう事故は防げそう- バックアップは
bgsaveとlastsaveはセットで利用すること
