Redis on Ubuntu 12.04 (Precise Pangolin)
Redis on Ubuntu 12.04 (Precise Pangolin)
Updated Thursday, October 25th, 2012 by Linode
Redis is a high performance persistent key-value store, and is intended as a datastore solution for applications where performance and flexibility are more critical than persistence and absolute data integrity. As such, Redis may be considered a participant in the “NoSQL” movement and is an attractive tool for developers of some kinds of applications. This document provides both instructions for deploying the Redis server and an overview of best practices for maintaining Redis instances.
Prior to beginning this guide for installing Redis, we assume that you have completed the steps outlined in our getting started guide. If you’re new to Linux systems administration, we recommend that you read the guides in our using Linux series, particularly the administration basics guide.
Install Redis
Prepare System for Redis
Issue the following commands to update your system’s package repositories and ensure that all installed packages are up to date:
Download and Install Redis
Install Redis from the Ubuntu repositories:
Redis Configuration
All Redis configuration options can be specified in the
Consider the following configuration:
redis.conf
The values in this configuration mirror the default Redis configuration Ubuntu provides. However, this configuration configures Redis to run ina daemon mode bound only to the local network interface. You may want to change these values depending on the needs of your application.
Managing Redis Instances
Running a Redis Datastore
In the default configuration, Redis runs in an interactive mode after being invoked at the command line. To start Redis in this manner issue the following command:
You may now interact with Redis using any of the language specific bindings or use the built-in command line interface to interact with the Redis instance. Simply prefix any Redis command with the following string:
While running the Redis instance in this configuration is useful for testing and initial deployment, production deployments may have better results by creating a dedicated and unprivileged system user for the Redis instance and controlling Redis using an “init” script. This section covers the creation of an init script and strategies for managing production Redis instances.
Managing Datastore Persistence
Redis is not necessarily intended to provide a completely consistent and fault tolerant data storage layer, and in the default configuration there are some conditions that may cause your data store to lose up to 60 seconds of the most recent data. Make sure you understand the risks associated and the potential impact that this kind of data loss may have on your application before deploying Redis.
If persistence is a major issue for your application, it is possible to use Redis in a transaction journaling mode that provides greater data resilience at the expense of some performance.
To use this mode, ensure that the following values are set in
redis.conf
The first directive enables the journaled “append only file” mode, while the second directive forces Redis to write the journal to the disk every second. The
After applying these configuration changes, restart Redis:
All modifications to the data store will be logged. Every time Redis restarts it will “replay” all transactions and ensure that your data store matches the log. However, in some conditions this may render the data-store unusable while the database restores. To avoid this condition, issue the following command to the Redis command line:
This command should return
You may wish to issue this command regularly, perhaps in a cron job, to ensure that the transaction journal doesn’t expand exponentially. bgrewriteaof` is non-destructive and can fail gracefully.
Distributed Data Stores with Master Slave Replication
Redis contains limited support for master-slave replication which allows you to create a second database that provides a direct real time copy of the data collection on a second system. In addition to providing a “hot spare” or multiple spares for your Redis instance, master-slave systems also allow you to distribute load amongst a group of servers. As long as all write options are applied to the master node, read operations can be distributed to as many slave nodes as required.
To configure master-slave operation, ensure that the following configuration options are applied to the slave instance:
redis.conf
The
When you restart the slave Redis instance, it will attempt to synchronize its data set to the master, and then propagate the changes. Slave Redis instances can accept slave connections, which allows administrators to distribute the slave-replication load in multi-slave architectures. It’s also possible to use a master with less stringent data persistence policies with a slave that keeps a more persistent copy. Master/slave replication creates a number of powerful architectural possibilities that may suit the needs of your application.
The traffic between slave instances and the master instance is not encrypted and does not require authentication in the default configuration. Authentication is available, and can be configured according to the documentation in the
The preferred method for controlling access to Redis instances involves using iptables and possibly some sort of encryption such as an SSH tunnel to ensure that traffic is secure. Slaves will automatically attempt to reestablish a connection to the master node if the link fails in a number of situations. However, clusters cannot automatically promote members from slave status to master status; cluster management of this order must occur within your application.
More Information
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials. Redis Project Home Page Redis Configuration Redis Persistence Redis Command Reference
Redis on Ubuntu 12.04 (Precise Pangolin)
Updated Thursday, October 25th, 2012 by Linode
Redis is a high performance persistent key-value store, and is intended as a datastore solution for applications where performance and flexibility are more critical than persistence and absolute data integrity. As such, Redis may be considered a participant in the “NoSQL” movement and is an attractive tool for developers of some kinds of applications. This document provides both instructions for deploying the Redis server and an overview of best practices for maintaining Redis instances.
Prior to beginning this guide for installing Redis, we assume that you have completed the steps outlined in our getting started guide. If you’re new to Linux systems administration, we recommend that you read the guides in our using Linux series, particularly the administration basics guide.
Install Redis
Prepare System for Redis
Issue the following commands to update your system’s package repositories and ensure that all installed packages are up to date:
1
2apt-get update
apt-get upgrade
Download and Install Redis
Install Redis from the Ubuntu repositories:
1apt-get install redis-server
Redis Configuration
All Redis configuration options can be specified in the
redis.conf file located at /etc/redis/redis.conf . You may wish to make a copy of this file before editing it, to retain default values in case of a problem down the line: 1cp /etc/redis/redis.conf /etc/redis/redis.conf.default
Consider the following configuration:
redis.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21daemonize yes
pidfile /var/run/redis.pid
logfile /var/log/redis.log
port 6379
bind 127.0.0.1
timeout 300
loglevel notice
## Default configuration options
databases 16
save 900 1
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
appendonly no
The values in this configuration mirror the default Redis configuration Ubuntu provides. However, this configuration configures Redis to run ina daemon mode bound only to the local network interface. You may want to change these values depending on the needs of your application.
Managing Redis Instances
Running a Redis Datastore
In the default configuration, Redis runs in an interactive mode after being invoked at the command line. To start Redis in this manner issue the following command:
1redis-server /etc/redis/redis.conf
You may now interact with Redis using any of the language specific bindings or use the built-in command line interface to interact with the Redis instance. Simply prefix any Redis command with the following string:
1redis-cli
While running the Redis instance in this configuration is useful for testing and initial deployment, production deployments may have better results by creating a dedicated and unprivileged system user for the Redis instance and controlling Redis using an “init” script. This section covers the creation of an init script and strategies for managing production Redis instances.
Managing Datastore Persistence
Redis is not necessarily intended to provide a completely consistent and fault tolerant data storage layer, and in the default configuration there are some conditions that may cause your data store to lose up to 60 seconds of the most recent data. Make sure you understand the risks associated and the potential impact that this kind of data loss may have on your application before deploying Redis.
If persistence is a major issue for your application, it is possible to use Redis in a transaction journaling mode that provides greater data resilience at the expense of some performance.
To use this mode, ensure that the following values are set in
redis.conf : redis.conf
1
2appendonly yes
appendfsync everysec
The first directive enables the journaled “append only file” mode, while the second directive forces Redis to write the journal to the disk every second. The
appendfsync directive also accepts the argument always to force writes after every operation which provides maximum durability, or never which allows the operating system to control when data is written to disk which is less reliable. By default, Redis in Ubuntu has appendfsync already set to everysec . After applying these configuration changes, restart Redis:
1service redis-server restart
All modifications to the data store will be logged. Every time Redis restarts it will “replay” all transactions and ensure that your data store matches the log. However, in some conditions this may render the data-store unusable while the database restores. To avoid this condition, issue the following command to the Redis command line:
1redis-cli bgrewriteaof
This command should return
Background append only file rewriting started . You may wish to issue this command regularly, perhaps in a cron job, to ensure that the transaction journal doesn’t expand exponentially. bgrewriteaof` is non-destructive and can fail gracefully.
Distributed Data Stores with Master Slave Replication
Redis contains limited support for master-slave replication which allows you to create a second database that provides a direct real time copy of the data collection on a second system. In addition to providing a “hot spare” or multiple spares for your Redis instance, master-slave systems also allow you to distribute load amongst a group of servers. As long as all write options are applied to the master node, read operations can be distributed to as many slave nodes as required.
To configure master-slave operation, ensure that the following configuration options are applied to the slave instance:
redis.conf
1slaveof 192.168.10.101 6379
The
slaveof directive takes two arguments: the first is the IP address of the master node, and the second is the Redis port specified in the master’s configuration. When you restart the slave Redis instance, it will attempt to synchronize its data set to the master, and then propagate the changes. Slave Redis instances can accept slave connections, which allows administrators to distribute the slave-replication load in multi-slave architectures. It’s also possible to use a master with less stringent data persistence policies with a slave that keeps a more persistent copy. Master/slave replication creates a number of powerful architectural possibilities that may suit the needs of your application.
The traffic between slave instances and the master instance is not encrypted and does not require authentication in the default configuration. Authentication is available, and can be configured according to the documentation in the
/etc/redis/redis.conf file; however, this is not the default method for securing Redis instances. The preferred method for controlling access to Redis instances involves using iptables and possibly some sort of encryption such as an SSH tunnel to ensure that traffic is secure. Slaves will automatically attempt to reestablish a connection to the master node if the link fails in a number of situations. However, clusters cannot automatically promote members from slave status to master status; cluster management of this order must occur within your application.
More Information
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.