Redis の管理¶
このページでは Redis の管理に関する話題を記述します。すべてのトピックは、FAQ 形式で完結しています。新しいトピックは随時追加される予定です。
Redis セットアップヒント¶
Linux オペレーティングシステム 上に Redis をデプロイすることを推奨します。Redis は OSX でも十分に、またしばしば FreeBSD や OpenBSD でもテストされています。しかし、私たちは Linux にて主な負荷テストを実施しており、またほとんどのプロダクション環境は Linux で稼働しています。
Linux のカーネルを overcommit memory setting to 1 としてください。
/etc/sysctl.conf
にvm.overcommit_memory = 1
を設定し、リブートもしくは即時反映のためsysctl vm.overcommit_memory=1
コマンドを発行してください。システムに いくらかの swap を設定してください (メモリと同じ大きさを推奨します)。もし swap がないと、Redis が急激にメモリを消費しすぎてしまったり、クラッシュしたり、Linux カーネルの OOM killer に Redis プロセスが kill されてしまうことがあります。
更新が非常に多いシステムで Redis を使う場合、RDB ファイルの保存時や AOF ログのリライト時に、 Redis は通常の 2 倍のメモリを使用します 。追加で必要なメモリ量は、保存するプロセスが書き込みを行っている間に変更されたメモリページ数に比例します。つまり、この間に変更されたキー(または集約タイプの要素)の数に比例します。そのことを考慮してメモリサイズを見積もってください。
永続化を無効にした場合でも、レプリケーションを行う場合は Redis は RDB の保存を実行します。
Redis の永続化を EC2 EBS ボリュームで行うことは推奨されません 。 EBS の性能はあまり良くないためです。永続化には ephemeral ストレージを使い、可能なタイミングで永続化したファイルを EBS に移動してください。
Xen ハイパーバイザを使った仮想環境にデプロイすると fork() 時間が長くなることがあります 。データセットのサイズによりますが、数ミリ秒から数秒にわたって Redis がブロックされることがあります。より詳しい情報は、 latency の ページ を参照してください。この問題は他のハイパーバイザで一般的なものではありません。
daemontools を使う場合は、
daemonize no
を指定してください。
ダウンタイムなしで Redis インスタンスをアップグレード、再起動する¶
Redis は、非常に長期間稼働し続けるように設計されています。たとえば、多くの設定オプションは CONFIG SET コマンド を使って、再起動なしに変更が可能です。
Redis 2.2 から、再起動なしで AOF から RDB スナップショット永続化へ切り替えることができるようになりました。詳しくは ‘CONFIG GET *’ コマンドの出力を確認してください。
しかし、時には再起動が必須となる場合もあります。たとえば Redis プロセスを新しいバージョンにアップグレードする、CONFIG コマンドが現在のところサポートしていないパラメータを変更する必要がある、などです。
以下のステップは、ダウンタイムを回避[訳注: しながら再起動]するもっとも一般的な方法です。
新しい Redis インスタンスを現在の Redis インスタンスのスレーブとして起動します。そのため、別のサーバーか、2 つの Redis インスタンスを同時に稼働させられるだけの十分な RAM をもつサーバーが必要です。
1 つのサーバーを使う場合、必ずマスターインスタンスとは別のポートで起動させてください。そうしないと、スレーブは起動できません。
レプリケーションの初回同期が完了するまで待ちます(スレーブのログファイルを確認してください)。
INFO コマンドを使って、マスターと同じ数のキーがスレーブ上に存在することを確認してください。redis-cli で、スレーブが期待どおりに稼働していること、コマンドに応答することを確認してください。
すべてのクライアントが、新しいインスタンス(つまり、スレーブ)を向くように設定してください。
マスターがどのようなクエリも受け付けていないことが確認できたら(MONITOR コマンド で確認できます)、 SLAVEOF NO ONE コマンドでスレーブをマスターに昇格させ、マスターを停止してください。