概要
- Redis 3.0のredis.confをざっと読んでみたのでざっと訳してみました。
- 動作未検証（1/27現在）
- （）内は個人的なコメントです。
redis.conf
INCLUDES
複数の設定ファイルを利用できます。同じパラメータをいじってる場合は最後が勝ちのようです。
# include /path/to/local.conf
# include /path/to/other.conf
GENERAL
# デーモン化するときはyes
# （プロダクションなら普通yes）
daemonize no
# デーモン化したときのPID
pidfile /var/run/redis.pid
# クライアント向けの開放port
port 6379
# TCP listen() backlog.
# （tcp connectionの待ちの上限？）
tcp-backlog 511
# 必要に応じて、bindするネットワークのインターフェースを限定できます。
# （private内で運用するならコメントアウトでよいかと）
bind 192.168.1.100 10.0.0.1
bind 127.0.0.1
# クライアントからのコネクションに対してUnix socketで対応します。デフォルトではnoです。
unixsocket /tmp/redis.sock
unixsocketperm 700
# 指定時間過ぎるとコネクションが切れる（秒）。０ならdisable
timeout 0
# ０でなければクライアントへのTCP ACKsに SO_KEEPALIVE を使う（秒）。これは以下の利点がある。
# 1) dead peerの検出
# 2) networkの疎通を確認する。
# Linuxでは数秒で設定されている。
# もし二倍の時間が過ぎたら接続は破棄される。
# （60が一般的と書いてあるので、本番時はそうしておくのが無難でしょうか）
tcp-keepalive 0
# ログレベル
# debug (たくさん。 development/testing向け)
# verbose (多すぎない程度にたくさん)
# notice (普通。本番向き。)
# warning (重要なもののみ。玄人 or リソース厳しいときのみ？)
loglevel notice
# logfile名。空ならstdout
# （pathで指定してもいい？workdir直下のみ？）
logfile ""
# loggingにSyslogを使う
# syslog-enabled no
# syslogの識別子
# syslog-ident redis
# syslogのfacility、LOCAL0-LOCAL7のどれか.
# syslog-facility local0
# databaseの個数。０〜N-1まで作られ、初期の接続先は０。
# クラスタ構成するならv3.0では一つしか使えない。
databases 1
SNAPSHOTTING
Note：スナップショットファイルのことをRDBファイルというらしい。
# DBへの保存の頻度
#
# save <seconds> <changes>
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: saveをコメントアウトすれば、一切diskに書き込まなくなる。
#
# 空文字引数を入れると、これまでの設定全てをなったことにする。
#
# save ""
save 900 1
save 300 10
save 60 10000
# RDBスナップショットが有効なのに作成に失敗している（保存できていない）場合は書き込みを受け付けない。
# デフォルトではyes。
# これにより、ユーザーは永続化できないのを無理矢理に知ることができる。
#
# 永続化プロセスが正常に戻ると書き込みを許容する。
stop-writes-on-bgsave-error yes
# LZFを使ってrdbを圧縮する。
# 普通はONだが、どうしてもCPUリソースを削りたいときはOFF。
rdbcompression yes
# RDBバージョン５から、 CRC64 checksumがファイル末尾につきます。
# 正真性がありますが、その処理にCPUを取られるので場合によってはOFFにします。
# （publicに置かない運用なら不要かと思います。）
rdbchecksum yes
# RDBのファイル名
dbfilename dump.rdb
# The working directory.
#
# dbfilenameのファイルや、redisが使う一時ファイルなどを保存する領域です。
# Note ファイル名でなくディレクトリ名です。
dir ./
REPLICATION
# 対象のマスタのスレーブとなる。
# 以下を理解する必要がある。
#
# 1) レプリケーションは非同期だが、もしレプリカが一定数死んでいれば書き込みを止めることもできる
# 2) スレーブは、少しのネットワーク障害であれば整合性を回復できる。詳しくは後ほど。
# 3) レプリケーションは自動なのでユーザーで気にする必要はない。もしネットワークが瞬断しても自動で復旧する。
#
slaveof <masterip> <masterport>
# もしマスタが認証アリにしていたら、スレーブはまず認証を通ってからでないとレプリケーションできない。
masterauth <master-password>
# もしマスタとの接続が切れたら、
#
# 1) slave-serve-stale-dataが'yes'なら、 古くても多少不整合でもいいからレスポンスを返す。
#
# 2) slave-serve-stale-dataが'no'なら、 INFO and SLAVEOF以外のコマンドは受け付けない。
# （redisのスレーブは古い状態もありうるのが一般的なのでyesでよいかと）
slave-serve-stale-data yes
# スレーブが書き込みを受け付けるかどうか。
# （直ぐにレプリケーションで消されてしまうが、一時的なデータストアならいい。
# しかしクライアントが間違えて使ってしまうケースが起こりうることに注意。
#
# Since Redis 2.6 by default slaves are read-only.
#
# Note: read-onlyはセキュリティのためにあるのではない。スレーブでもINFOやCONFIGなどのコマンドは使えてしまうので、もし気になるのであればrename-commandを使うと良い。
# （yesで良いのでは。）
slave-read-only yes
# Replication SYNC strategy: disk or socket.
#
# 注： disklessはEXPERIMENTAL
#
# クラスタに新しく加わった場合は、差分でなくfull syncをする必要がある。これは二種類の方法がある。
#
# 1) Disk-backed: マスタがRDBファイルを作りスレーブに転送する。
# 一度RDBを作ってしまえば、好きなタイミングで送るだけ。
#
# 2) Diskless: マスタがスレーブのRDBファイルソケットに直接データを送る。
# 複数のソケットに同時に送れるが、送信中に他クライアントの追加はできない。
#
# Diskが遅くてネットワークが速いならDisklessの方が良い。（EXPERIMENTALだけど）
repl-diskless-sync no
# Disklessの場合、一定時間待ってからレプリケーションを開始する。
# これは、一度転送が始まると後から新規ノードが来ても対応できないため。
repl-diskless-sync-delay 5
# pingを送るタイミング（秒）
# （ネットワークが安定しているならもう少し短くていいかも）
repl-ping-slave-period 10
# このオプションはreplication timeoutを設定する。
#
# 1) Bulk transfer I/O during SYNC, from the point of view of slave.
# 2) Master timeout from the point of view of slaves (data, pings).
# 3) Slave timeout from the point of view of masters (REPLCONF ACK pings).
# （イメージはわかるが具体的に理解できてない。）
#
# 重要な点は、この値はrepl-ping-slave-periodよりかなり大きくしないと、一度pingが通らないくらいでtimeout判定されてしまう。（秒）
# （ping × 5くらいでいいのでは）
repl-timeout 60
# Disable TCP_NODELAY on the slave socket after SYNC?
#
# "yes" 少数のpacketでやりとりして帯域を占領しなくなるが、遅延が起きてしまう。
# "no" 多くのpacketで帯域を占領するが、遅延は少なくなる。
#
# デフォルトはnoだが、ネットワーク環境が悪い場合や、物理的に遠い場合はyesを利用する。
repl-disable-tcp-nodelay no
# Set the replication backlog size.
# スレーブが一時的にマスタから見えない時に差分データを溜めておく。fullSyncの時には必要ない。
# このbacklogは、slaveが一つ接続された時のみ作られる（スレーブごとに作られる？）
# repl-backlog-size 1mb
# slaveとの接続が切れて指定時間過ぎたらbacklogが消される。
# 0ならずっと消さない。
# （backlogが消されてからslaveが復帰したら、RDB dumpを取ってくることになる？）
# repl-backlog-ttl 3600
# Redis Sentinelがスレーブ昇格の際に参考にする優先度。
slave-priority 100
# どちらかの設定が０やコメントアウトしてたらこれらはdisabled
# この値はただの設定例
# （データロストを防ぎたいならキツ目に設定しておく）
#
# 書き込みを許容する際のスレーブの最低数。
# min-slaves-to-write 3
# 書き込みを許容する際のスレーブの最終接続からの経過時間。
# min-slaves-max-lag 10
SECURITY
自分としてはredisをpublicに置いておくケースを想定していないのでナシ。
LIMITS
# コネクションの数を制限します。デフォルトは10000クライアント。
# 最大でfile limit -32まで可能です。（redisは他にもfileを扱うので）
# （多くて困ることはない気がする。）
maxclients 10000
# メモリが設定値を超えたら、redisは古いkeyを削除します。
# もし破棄できなければ、set系のコマンドはエラーを返します。（getは問題ないです。）
# デフォルトではLRUを使用しています。
# WARNING: slaveを利用している場合は、output bufferにメモリを持って行かれるので注意
maxmemory <bytes>
# maxmemoryに達したら以下のロジックを選べます。
#
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key according to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys-random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# noeviction -> don't expire at all, just return an error on write operations
#
# Note: もしメモリの空きを作れなければクライアントの書き込み要求にエラーを返します。
maxmemory-policy noeviction
# アルゴリズムの厳密さ？
# （数値が高ければアルゴリズム[LRUとか]に近くなるがメモリを消費する。低ければいいかげんだが速い）
# （とりあえずデフォルト？）
maxmemory-samples 5
APPEND ONLY MODE
# デフォルトでは非同期で永続化するので、あるケースではデータがロストする可能性がある。
# Append Only Fileは、それよりも障害に強いモードです。
# デフォルトでは最悪の場合1秒程度のデータロストの可能性があります。
# AOF と RDBへの保存は両立します。AOFの方がデータが飛びにくいです。
# Please check http://redis.io/topics/persistence for more information.
# （消えたくないデータを使っているなら一旦yesでよいかと。）
appendonly no
# append only fileの名前
appendfilename "appendonly.aof"
# OSのfsync()を利用して即座に書き込むようになる、3種類のモードを用意している。
#
# no: OSの好きなタイミングでfsyncする。速い
# The default is "everysec", 毎秒書き込む
# "always" that's 遅いがデータが飛ばない。
#
# http://antirez.com/post/redis-persistence-demystified.html
#
# とりあえず "everysec".
appendfsync everysec # always/everysec/no
# fsyncがものすごくIO waitを発生してしまったら、現状防ぐすべはないです。
# この問題を解決するには、BGSAVEが既に起動中ならfsync()のコールを止めることです。
#
# waitが発生して入る場合には "yes"
# それ以外は"no"のままにすることで耐障害性は高くなります。
no-appendfsync-on-rewrite no
# （AOF のrewriteのタイミングの調整？読んでない。。。）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# AOFから復旧した場合、読み終わったAOFファイルを消すかどうか？
aof-load-truncated yes
REDIS CLUSTER
WARNING EXPERIMENTAL: stableだが、まだ実用に耐えるか不明。
# クラスタに参加するには、以下のモードをyesにする必要がある。
cluster-enabled yes
# Redisノードが、クラスタの状態を永続化するためにcluster-config-fileを用いる。
# （これによって再起動時にすぐにクラスタに加わるなどが可能になる。）
cluster-config-file nodes-6379.conf
# ノードの死活管理の際に用いるミリ秒指定
cluster-node-timeout 15000
# スレーブは、自身のデータが古いと判断したらマスタに昇格しない。
# dataの古さの明確な指標はないので以下の方法を用いる。
#
# 1) 複数のスレーブがフェイルオーバー可能な場合、offset値を見て一番新しいスレーブにする。
# 2) マスタと最後に連絡がとれた時間を見て判断する。
#
# 2は、ユーザーの方で、どのくらい古くても許容するかを指定できる。
#
# (node-timeout * slave-validity-factor) + repl-ping-slave-period
#
# 可用性を最大化するためにslave-validity-factorを０にすることができる。
# これはスレーブが、マスタと以前通信できていても常にフェイルオーバーをしようとする。
# （しかしマスタが生きていればoffsetを更新して終わり。）
# ０は、常にクラスタが生きていられるようにマスタを維持しようとします。
cluster-slave-validity-factor 10
# クラスタは、もしマスタの一部が飛んでも接続を試み続ける。
# これは、もしスレーブが昇格するとスレーブいなくなる時に、データを維持し続けることができる。
# スレーブは、もしマスタが死んでスレーブの数も十分な場合のみフェイルオーバーする。
# その数に達していなければフェイルオーバー（マイグレーション）しない。
# デフォルトは１で、０にするとデータのロストがありうるので本番時はおすすめしない。
# （スレーブなしのマスタがいると、そいつが死んだらデータは永遠に失われるため。）
cluster-migration-barrier 1
# デフォルトでは、あるslotが応答できなくなったら全部のクエリを止める。
# これは、もし担当ノードが死んでslotが利用できなくなったら、非同期でクラスタ全体を止める。
# slotが復活したら即座に運用を再開する。
# もし一部だけでも動かし続けたい場合はここをnoにする。
# （あるいはデータのロストや不整合を許容しても可用性を確保したいとき以外はyes）
cluster-require-full-coverage yes
SLOW LOG
# 特定時間を超えるクエリを特定する。
# これにはクライアントとのIOは含まない。
# 実行待ちは含まず、純粋に処理時間を扱う。
# 2つのパラメータを設定できる。
# 一つはslowの度合い。（㍉秒）
slowlog-log-slower-than 10000
# 次は容量。もし容量を超えたら古いものが消される
slowlog-max-len 128
LATENCY MONITOR
# これは、インスタンスの遅延度を別プロセスで収集するツールです。
# LATENCYを利用してグラフを表示する。
# 応答速度の許容値㍉秒（もし０なら表示しない。）
# （普段は消しておいて、問題が発覚してからonにするでもいいのでは。）
latency-monitor-threshold 0
EVENT NOTIFICATION
Pub/Subは個人的にまだ使わないので省略
ADVANCED CONFIG
# hashエンコードはkeyの数が小さければ効率化する必要があるし、多ければ閾値を超えないようにする必要がある。
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
# hashと同様にlistも決める必要がある。
list-max-ziplist-entries 512
list-max-ziplist-value 64
# その他は読むの疲れたので放置。
まとめ
とりあえずRedisを使うケースとしては、少しのロストも許容するから、大量で即座に処理したい単純なデータ、というかんじでしょうか。
自分のコメントもその用途を意識したものになっていると思います。
- 誤訳の修正
- 未訳のところの穴埋め
- 僕のコメントが見当違いの場合の指摘
などして頂けるとすごく嬉しいです。