2/18のデブサミ2016で発表したスライドになります。 著作権の関係上、ネタスライドは全て削除しております。 Developers Summit 2016【18-C-4】 株式会社アカツキ 駒井祐人 Read less
Redis のレプリケーション設定についてメモ 公式ドキュメント http://redis.io/topics/replication Redis のレプリケーション マスターは複数のスレーブをもてる スレーブは別のスレーブの親になれる マスター/スレーブのレプリケート処理はノンブロッキング スレーブは writable (2.6 からは slave-read-only 設定が追加され、デフォルトは read-only) スレーブの用意 スレーブ用 redis サーバーを起動する。同じサーバ内に起動するのであれば、ポートを変更する必要がある。 redis.conf の port を修正すること。 スレーブ設定方法 confファイルでの設定 redis.conf にマスターの情報を記述する slaveof <masterip> <masterport> ex) slaveof 192.168
実は Redis on ElastiCacheに関しては、先月2013年9月5日に AWSからリリースされてから、すぐにベンチマークをとっていました。 が、記事にするのを忘れていたという、いつもの有様です。 さて、Redis on ElastiCacheに関しては、他にも既にいくつかのベンチマーク記事があります。 まめ畑 - ElastiCache Redis Engineのベンチマークともろもろ インフラ備忘録 - Redis on ElastiCache を試しています Medium - Benchmarking Redis on AWS ElastiCache 今回は、EC2で Redisを実際に高トラフィックで使っている立場から、EC2とRedis on Elastic Cacheを比較したベンチマークを公開します。(他の記事とは違いm2.4xlargeベースの検証です) 目次 目
REDIS cheatsheet [v1.0] starting the server cd redis; ./redis-server running the client ./redis-cli <command> exists key Test if specified key exists. Return: 1 if exists, 0 if not commands generic commands for all types del key1 key2 ... keyN Remove the specified keys. Return: integer > 0 if keys removed, 0 if none of the keys existed type key Return the type of the value stored at key, as a stri
たまにはPowerShell 以外の記事を。 某記事でもRedis (REmote DIctionary Server)が memcached に代わり得る利点がBookSleeveを交えて丁寧に説明されました。 そして、Redisの運用が一定の目途を見せていることから、その初期設定に欠かせないチューニングについて記事にしてみようと思います。 全部明かすわけではありませんが、なかなかRedisに関する記事は少ないので、少し参考になれば幸いです。 経験上、高負荷環境ではRedisはチューニングで大幅に安定性が変わります。 インストール? 沢山記事ありますし、簡単なのでここでは省きます。 どうしても!な場合は希望していただければ記事にしますが。 Redis Quick Start 対象バージョン 2.6系とします。 2.4系でも大方一緒ですが、2.6系に特有な部分があるので、注意です。 対象O
「RedisかわいいよRedis」(by typester)……というほど自分は Redis 期でもないのですが、最近 Redis を使ったサービスの面倒を見ていて時々レスポンスが悪化する現象に出会ったので調べました。 前提 使用しているのは Redis 2.4.16 です。 redis.conf に "save [t] [n]" を定義すると、最後に save をしてから [t]秒間に [n]個以上の key が更新された場合に background で save (=bgsave) が実行されます。 save 60 10000これだと、60秒間に 10,000 keys です。 bgsave では redisは自分自身のプロセスを fork() し、子プロセス側は自分のメモリに乗っている内容をファイルにすべて書き出します。 この仕組みによって、1プロセス 1スレッドで動作している re
どうも初めまして2012年度入社の社内ニート予備軍editnukiです。 普段は引きこもって WebSocketで監視もリアルタイムに を書いた社内ニートさんの下でコミュニティサービスのインフラをやっております。 運用面以外ではrpmパッケージ作ったりしています。 さて、本題ですがコミュニティサービスでもredisを利用したいという声が最近多くなりいくつかのサービスではredisを導入しているのですがマスターとなるredisが死ぬと更新系が一切できなくなるため、マスターが死んだ時はアプリの向き先をスレーブに変更しなければなりません。 今までのredisの構成としては下図の様な構成でした。 redisの2.6系がリリースされた時に「sentinel」というフェイルオーバーの機能が追加されました。 詳細は公式ドキュメントをご参照ください。 フェイルオーバーしたとしてもアプリ側にマスターが切り替
こんにちは、鈴木です。 Redis におけるデータの永続化についてです。 RDB と AOF Redis におけるデータの永続化には 2 つの方式があります。 一つは RDB ファイル(RDB = Redis DataBase だと思います)に書き出す方式で、あるタイミングのスナップショット(フルダンプ)です。 もう一つは更新系のクエリが逐次追記される AOF (Append Only File) です。 RDB と AOF は両方を有効にすることができ、その場合は RDB と AOF の両方が出力されますが、Redis 起動時には AOF からデータが復元されます。 RDB を保存する RDB ファイルを保存するには、save ディレクティブで保存するタイミングを指定します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く