Merge ~ubuntu-docker-images/ubuntu-docker-images/+git/redis:readme into ~ubuntu-docker-images/ubuntu-docker-images/+git/redis:edge
- Git
- lp:~ubuntu-docker-images/ubuntu-docker-images/+git/redis
- readme
- Merge into edge
Proposed by
Sergio Durigan Junior
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Sergio Durigan Junior | ||||
Approved revision: | 5a29550f0523d59defade47334fd9e35c478fe96 | ||||
Merge reported by: | Sergio Durigan Junior | ||||
Merged at revision: | 5a29550f0523d59defade47334fd9e35c478fe96 | ||||
Proposed branch: | ~ubuntu-docker-images/ubuntu-docker-images/+git/redis:readme | ||||
Merge into: | ~ubuntu-docker-images/ubuntu-docker-images/+git/redis:edge | ||||
Diff against target: |
1673 lines (+1613/-10) 6 files modified
HACKING.md (+19/-0) README.md (+89/-10) examples/README.md (+74/-0) examples/config/redis.conf (+1373/-0) examples/docker-compose.yml (+10/-0) examples/microk8s-deployments.yml (+48/-0) |
||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Richard Harding (community) | Approve | ||
Lucas Kanashiro | Pending | ||
Review via email:
|
Commit message
Description of the change
Improve on the existing README file; add HACKING and examples. As per requested by LP #1904004.
To post a comment you must log in.
Revision history for this message
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Sergio Durigan Junior (sergiodj) wrote : | # |
Thanks for the review, Rick! I've addressed your comments, and will push the changes now.
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1 | diff --git a/HACKING.md b/HACKING.md | |||
2 | 0 | new file mode 100644 | 0 | new file mode 100644 |
3 | index 0000000..4de80f4 | |||
4 | --- /dev/null | |||
5 | +++ b/HACKING.md | |||
6 | @@ -0,0 +1,19 @@ | |||
7 | 1 | # Contributing | ||
8 | 2 | |||
9 | 3 | In order to contribute to the redis OCI image, do the following: | ||
10 | 4 | |||
11 | 5 | * Create a new branch. | ||
12 | 6 | |||
13 | 7 | * Make your changes. Keep your commits logically separated. If it is | ||
14 | 8 | fixing a bug do not forget to mention it in the commit message. | ||
15 | 9 | |||
16 | 10 | * Build a new image with your changes. You can use the following command: | ||
17 | 11 | |||
18 | 12 | ``` | ||
19 | 13 | $ docker build -t squeakywheel/redis:test . | ||
20 | 14 | ``` | ||
21 | 15 | |||
22 | 16 | * Test the new image. Run it in some way that exercise your changes, | ||
23 | 17 | you can also check th README.md file. | ||
24 | 18 | |||
25 | 19 | * If everything goes well submit a merge proposal. | ||
26 | diff --git a/README.md b/README.md | |||
27 | index 4011330..77cd3bc 100644 | |||
28 | --- a/README.md | |||
29 | +++ b/README.md | |||
30 | @@ -1,21 +1,42 @@ | |||
31 | 1 | # Ubuntu redis OCI image | 1 | # Ubuntu redis OCI image |
32 | 2 | 2 | ||
34 | 3 | This is the OCI image for redis. | 3 | This is the OCI image for redis. In Ubuntu, redis is available as a |
35 | 4 | `.deb.` package. For this reason, this image was built by installing | ||
36 | 5 | the redis Ubuntu Focal package inside a docker container. | ||
37 | 6 | |||
38 | 7 | ## Versions supported | ||
39 | 8 | |||
40 | 9 | * `edge` = `5.0.7-2` | ||
41 | 10 | |||
42 | 11 | ## Architectures supported | ||
43 | 12 | |||
44 | 13 | * amd64 | ||
45 | 14 | |||
46 | 15 | * arm64 | ||
47 | 16 | |||
48 | 17 | * ppc64el | ||
49 | 18 | |||
50 | 19 | * s390x | ||
51 | 4 | 20 | ||
52 | 5 | ## How to use it | 21 | ## How to use it |
53 | 6 | 22 | ||
55 | 7 | `$ docker run --name redis -e ALLOW_EMPTY_PASSWORD=yes <TODONAMEHERE>/redis:edge` | 23 | To obtain this image, run: |
56 | 8 | 24 | ||
59 | 9 | Bear in mind that the use of `ALLOW_EMPTY_PASSWORD=yes` is not | 25 | ``` |
60 | 10 | recommended in production environments. | 26 | $ docker pull squeakywheel/redis:edge |
61 | 27 | ``` | ||
62 | 11 | 28 | ||
64 | 12 | ## Differences between our image and upstream's | 29 | You will be able to launch `redis-server` by doing: |
65 | 13 | 30 | ||
71 | 14 | Upstream's redis image does not enforce the use of a password when | 31 | ``` |
72 | 15 | connecting to `redis-server`, whereas our image does. For this | 32 | $ docker run --name redis -e ALLOW_EMPTY_PASSWORD=yes squeakywheel/redis:edge |
73 | 16 | reason, you have to explicitly provide the password via an environment | 33 | ``` |
74 | 17 | variable (see below), or disable it via the | 34 | |
75 | 18 | `ALLOW_EMPTY_PASSWORD=yes`, as mentioned above. | 35 | Bear in mind that the use of `ALLOW_EMPTY_PASSWORD=yes` is not |
76 | 36 | recommended in production environments. For production environments, | ||
77 | 37 | it is recommended that you specify the `REDIS_PASSWORD` environment | ||
78 | 38 | variable, or instruct the entrypoint script to create a random | ||
79 | 39 | password for you by specifying `REDIS_RANDOM_PASSWORD=1`. | ||
80 | 19 | 40 | ||
81 | 20 | ## Environment variables | 41 | ## Environment variables |
82 | 21 | 42 | ||
83 | @@ -42,3 +63,61 @@ the behaviour of `redis-server`. | |||
84 | 42 | - `REDIS_EXTRA_FLAGS`: If you would like to specify any extra flags to | 63 | - `REDIS_EXTRA_FLAGS`: If you would like to specify any extra flags to |
85 | 43 | be passed to `redis-server` when initializing it, use this | 64 | be passed to `redis-server` when initializing it, use this |
86 | 44 | environment variable to do so. | 65 | environment variable to do so. |
87 | 66 | |||
88 | 67 | ## Specifying your own configuration file | ||
89 | 68 | |||
90 | 69 | You can specify your own `redis.conf` file by mounting it: | ||
91 | 70 | |||
92 | 71 | ``` | ||
93 | 72 | $ docker run -v /myredis/redis.conf:/etc/redis/redis.conf -e ALLOW_EMPTY_PASSWORD=yes --name redis squeakywheel/redis:edge | ||
94 | 73 | ``` | ||
95 | 74 | |||
96 | 75 | ## Connecting to the redis-server via redis-cli | ||
97 | 76 | |||
98 | 77 | If you want, you can launch another container with the `redis-cli` | ||
99 | 78 | program, and connect to the `redis-server` that is running in the | ||
100 | 79 | first container. | ||
101 | 80 | |||
102 | 81 | For example, suppose that you already have a docker network named | ||
103 | 82 | `redis-network` configured, and you launch `redis-server` like this: | ||
104 | 83 | |||
105 | 84 | ``` | ||
106 | 85 | $ docker run --network redis-network --name redis-container -e REDIS_PASSWORD=mypassword -d squeakywheel/redis:edge | ||
107 | 86 | ``` | ||
108 | 87 | |||
109 | 88 | You can now launch `redis-cli` by doing: | ||
110 | 89 | |||
111 | 90 | ``` | ||
112 | 91 | $ docker run --network redis-network --rm squeakywheel/redis:edge redis-cli -h redis-container | ||
113 | 92 | redis:6379> AUTH mypassword | ||
114 | 93 | OK | ||
115 | 94 | redis:6379> PING | ||
116 | 95 | PONG | ||
117 | 96 | redis:6379> | ||
118 | 97 | ``` | ||
119 | 98 | |||
120 | 99 | ## Differences between our image and upstream's | ||
121 | 100 | |||
122 | 101 | Upstream's redis image does not enforce the use of a password when | ||
123 | 102 | connecting to `redis-server`, whereas our image does. For this | ||
124 | 103 | reason, you have to explicitly provide the password via an environment | ||
125 | 104 | variable (see below), or disable it via the | ||
126 | 105 | `ALLOW_EMPTY_PASSWORD=yes`, as mentioned above. | ||
127 | 106 | |||
128 | 107 | ## Bugs and Features request | ||
129 | 108 | |||
130 | 109 | If you find a bug in our image or want to request a specific feature | ||
131 | 110 | file a bug here: | ||
132 | 111 | |||
133 | 112 | https://bugs.launchpad.net/ubuntu-server-oci/+filebug | ||
134 | 113 | |||
135 | 114 | In the title of the bug add `redis: <reason>`. | ||
136 | 115 | |||
137 | 116 | Make sure to include: | ||
138 | 117 | |||
139 | 118 | * The tag of the image you are using | ||
140 | 119 | |||
141 | 120 | * Reproduction steps for the deployment | ||
142 | 121 | |||
143 | 122 | * If it is a feature request, please provide as much detail as | ||
144 | 123 | possible | ||
145 | diff --git a/examples/README.md b/examples/README.md | |||
146 | 45 | new file mode 100644 | 124 | new file mode 100644 |
147 | index 0000000..09e3cd1 | |||
148 | --- /dev/null | |||
149 | +++ b/examples/README.md | |||
150 | @@ -0,0 +1,74 @@ | |||
151 | 1 | # Running the examples | ||
152 | 2 | |||
153 | 3 | ## docker-compose | ||
154 | 4 | |||
155 | 5 | Install `docker-compose` from the Ubuntu archive: | ||
156 | 6 | |||
157 | 7 | ``` | ||
158 | 8 | $ sudo apt install -y docker-compose | ||
159 | 9 | ``` | ||
160 | 10 | |||
161 | 11 | Call `docker-compose` from the examples directory: | ||
162 | 12 | |||
163 | 13 | ``` | ||
164 | 14 | $ docker-compose up -d | ||
165 | 15 | ``` | ||
166 | 16 | |||
167 | 17 | You can now access the redis server on port 6379, using `redis-cli`: | ||
168 | 18 | |||
169 | 19 | ``` | ||
170 | 20 | $ redis-cli -h 127.0.0.1 | ||
171 | 21 | 127.0.0.1:6379> auth mypassword | ||
172 | 22 | OK | ||
173 | 23 | 127.0.0.1:6379> ping | ||
174 | 24 | PONG | ||
175 | 25 | 127.0.0.1:6379> | ||
176 | 26 | ``` | ||
177 | 27 | |||
178 | 28 | Notice that the default password set in the `docker-compose` file is | ||
179 | 29 | `mypassword`. | ||
180 | 30 | |||
181 | 31 | To stop `docker-compose`, run: | ||
182 | 32 | |||
183 | 33 | ``` | ||
184 | 34 | $ docker-compose down | ||
185 | 35 | ``` | ||
186 | 36 | |||
187 | 37 | # Microk8s | ||
188 | 38 | |||
189 | 39 | Install microk8s from snap: | ||
190 | 40 | |||
191 | 41 | ``` | ||
192 | 42 | $ snap install microk8s | ||
193 | 43 | ``` | ||
194 | 44 | |||
195 | 45 | With microk8s running, enable the `dns` and `storage` add-ons: | ||
196 | 46 | |||
197 | 47 | ``` | ||
198 | 48 | $ microk8s enable dns storage | ||
199 | 49 | ``` | ||
200 | 50 | |||
201 | 51 | Create a configmap for the configuration files: | ||
202 | 52 | |||
203 | 53 | ``` | ||
204 | 54 | $ microk8s kubectl create configmap redis-config \ | ||
205 | 55 | --from-file=redis=config/redis.conf \ | ||
206 | 56 | ``` | ||
207 | 57 | |||
208 | 58 | Apply the `microk8s-deployments.yml`: | ||
209 | 59 | |||
210 | 60 | ``` | ||
211 | 61 | $ microk8s kubectl apply -f microk8s-deployments.yml | ||
212 | 62 | ``` | ||
213 | 63 | |||
214 | 64 | You will now be able to connect to the redis server using port 30073 | ||
215 | 65 | on `localhost`: | ||
216 | 66 | |||
217 | 67 | ``` | ||
218 | 68 | $ redis-cli -h 127.0.0.1 -p 30073 | ||
219 | 69 | 127.0.0.1:30073> auth mypassword | ||
220 | 70 | OK | ||
221 | 71 | 127.0.0.1:30073> ping | ||
222 | 72 | PONG | ||
223 | 73 | 127.0.0.1:30073> | ||
224 | 74 | ``` | ||
225 | diff --git a/examples/config/redis.conf b/examples/config/redis.conf | |||
226 | 0 | new file mode 100644 | 75 | new file mode 100644 |
227 | index 0000000..d01b31e | |||
228 | --- /dev/null | |||
229 | +++ b/examples/config/redis.conf | |||
230 | @@ -0,0 +1,1373 @@ | |||
231 | 1 | # Redis configuration file example. | ||
232 | 2 | # | ||
233 | 3 | # Note that in order to read the configuration file, Redis must be | ||
234 | 4 | # started with the file path as first argument: | ||
235 | 5 | # | ||
236 | 6 | # ./redis-server /path/to/redis.conf | ||
237 | 7 | |||
238 | 8 | # Note on units: when memory size is needed, it is possible to specify | ||
239 | 9 | # it in the usual form of 1k 5GB 4M and so forth: | ||
240 | 10 | # | ||
241 | 11 | # 1k => 1000 bytes | ||
242 | 12 | # 1kb => 1024 bytes | ||
243 | 13 | # 1m => 1000000 bytes | ||
244 | 14 | # 1mb => 1024*1024 bytes | ||
245 | 15 | # 1g => 1000000000 bytes | ||
246 | 16 | # 1gb => 1024*1024*1024 bytes | ||
247 | 17 | # | ||
248 | 18 | # units are case insensitive so 1GB 1Gb 1gB are all the same. | ||
249 | 19 | |||
250 | 20 | ################################## INCLUDES ################################### | ||
251 | 21 | |||
252 | 22 | # Include one or more other config files here. This is useful if you | ||
253 | 23 | # have a standard template that goes to all Redis servers but also need | ||
254 | 24 | # to customize a few per-server settings. Include files can include | ||
255 | 25 | # other files, so use this wisely. | ||
256 | 26 | # | ||
257 | 27 | # Notice option "include" won't be rewritten by command "CONFIG REWRITE" | ||
258 | 28 | # from admin or Redis Sentinel. Since Redis always uses the last processed | ||
259 | 29 | # line as value of a configuration directive, you'd better put includes | ||
260 | 30 | # at the beginning of this file to avoid overwriting config change at runtime. | ||
261 | 31 | # | ||
262 | 32 | # If instead you are interested in using includes to override configuration | ||
263 | 33 | # options, it is better to use include as the last line. | ||
264 | 34 | # | ||
265 | 35 | # include /path/to/local.conf | ||
266 | 36 | # include /path/to/other.conf | ||
267 | 37 | |||
268 | 38 | ################################## MODULES ##################################### | ||
269 | 39 | |||
270 | 40 | # Load modules at startup. If the server is not able to load modules | ||
271 | 41 | # it will abort. It is possible to use multiple loadmodule directives. | ||
272 | 42 | # | ||
273 | 43 | # loadmodule /path/to/my_module.so | ||
274 | 44 | # loadmodule /path/to/other_module.so | ||
275 | 45 | |||
276 | 46 | ################################## NETWORK ##################################### | ||
277 | 47 | |||
278 | 48 | # By default, if no "bind" configuration directive is specified, Redis listens | ||
279 | 49 | # for connections from all the network interfaces available on the server. | ||
280 | 50 | # It is possible to listen to just one or multiple selected interfaces using | ||
281 | 51 | # the "bind" configuration directive, followed by one or more IP addresses. | ||
282 | 52 | # | ||
283 | 53 | # Examples: | ||
284 | 54 | # | ||
285 | 55 | # bind 192.168.1.100 10.0.0.1 | ||
286 | 56 | # bind 127.0.0.1 ::1 | ||
287 | 57 | # | ||
288 | 58 | # ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the | ||
289 | 59 | # internet, binding to all the interfaces is dangerous and will expose the | ||
290 | 60 | # instance to everybody on the internet. So by default we uncomment the | ||
291 | 61 | # following bind directive, that will force Redis to listen only into | ||
292 | 62 | # the IPv4 loopback interface address (this means Redis will be able to | ||
293 | 63 | # accept connections only from clients running into the same computer it | ||
294 | 64 | # is running). | ||
295 | 65 | # | ||
296 | 66 | # IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES | ||
297 | 67 | # JUST COMMENT THE FOLLOWING LINE. | ||
298 | 68 | # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
299 | 69 | #bind 127.0.0.1 ::1 | ||
300 | 70 | bind 0.0.0.0 | ||
301 | 71 | |||
302 | 72 | # Protected mode is a layer of security protection, in order to avoid that | ||
303 | 73 | # Redis instances left open on the internet are accessed and exploited. | ||
304 | 74 | # | ||
305 | 75 | # When protected mode is on and if: | ||
306 | 76 | # | ||
307 | 77 | # 1) The server is not binding explicitly to a set of addresses using the | ||
308 | 78 | # "bind" directive. | ||
309 | 79 | # 2) No password is configured. | ||
310 | 80 | # | ||
311 | 81 | # The server only accepts connections from clients connecting from the | ||
312 | 82 | # IPv4 and IPv6 loopback addresses 127.0.0.1 and ::1, and from Unix domain | ||
313 | 83 | # sockets. | ||
314 | 84 | # | ||
315 | 85 | # By default protected mode is enabled. You should disable it only if | ||
316 | 86 | # you are sure you want clients from other hosts to connect to Redis | ||
317 | 87 | # even if no authentication is configured, nor a specific set of interfaces | ||
318 | 88 | # are explicitly listed using the "bind" directive. | ||
319 | 89 | protected-mode yes | ||
320 | 90 | |||
321 | 91 | # Accept connections on the specified port, default is 6379 (IANA #815344). | ||
322 | 92 | # If port 0 is specified Redis will not listen on a TCP socket. | ||
323 | 93 | port 6379 | ||
324 | 94 | |||
325 | 95 | # TCP listen() backlog. | ||
326 | 96 | # | ||
327 | 97 | # In high requests-per-second environments you need an high backlog in order | ||
328 | 98 | # to avoid slow clients connections issues. Note that the Linux kernel | ||
329 | 99 | # will silently truncate it to the value of /proc/sys/net/core/somaxconn so | ||
330 | 100 | # make sure to raise both the value of somaxconn and tcp_max_syn_backlog | ||
331 | 101 | # in order to get the desired effect. | ||
332 | 102 | tcp-backlog 511 | ||
333 | 103 | |||
334 | 104 | # Unix socket. | ||
335 | 105 | # | ||
336 | 106 | # Specify the path for the Unix socket that will be used to listen for | ||
337 | 107 | # incoming connections. There is no default, so Redis will not listen | ||
338 | 108 | # on a unix socket when not specified. | ||
339 | 109 | # | ||
340 | 110 | # unixsocket /var/run/redis/redis-server.sock | ||
341 | 111 | # unixsocketperm 700 | ||
342 | 112 | |||
343 | 113 | # Close the connection after a client is idle for N seconds (0 to disable) | ||
344 | 114 | timeout 0 | ||
345 | 115 | |||
346 | 116 | # TCP keepalive. | ||
347 | 117 | # | ||
348 | 118 | # If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence | ||
349 | 119 | # of communication. This is useful for two reasons: | ||
350 | 120 | # | ||
351 | 121 | # 1) Detect dead peers. | ||
352 | 122 | # 2) Take the connection alive from the point of view of network | ||
353 | 123 | # equipment in the middle. | ||
354 | 124 | # | ||
355 | 125 | # On Linux, the specified value (in seconds) is the period used to send ACKs. | ||
356 | 126 | # Note that to close the connection the double of the time is needed. | ||
357 | 127 | # On other kernels the period depends on the kernel configuration. | ||
358 | 128 | # | ||
359 | 129 | # A reasonable value for this option is 300 seconds, which is the new | ||
360 | 130 | # Redis default starting with Redis 3.2.1. | ||
361 | 131 | tcp-keepalive 300 | ||
362 | 132 | |||
363 | 133 | ################################# GENERAL ##################################### | ||
364 | 134 | |||
365 | 135 | # By default Redis does not run as a daemon. Use 'yes' if you need it. | ||
366 | 136 | # Note that Redis will write a pid file in /var/run/redis.pid when daemonized. | ||
367 | 137 | daemonize yes | ||
368 | 138 | |||
369 | 139 | # If you run Redis from upstart or systemd, Redis can interact with your | ||
370 | 140 | # supervision tree. Options: | ||
371 | 141 | # supervised no - no supervision interaction | ||
372 | 142 | # supervised upstart - signal upstart by putting Redis into SIGSTOP mode | ||
373 | 143 | # supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET | ||
374 | 144 | # supervised auto - detect upstart or systemd method based on | ||
375 | 145 | # UPSTART_JOB or NOTIFY_SOCKET environment variables | ||
376 | 146 | # Note: these supervision methods only signal "process is ready." | ||
377 | 147 | # They do not enable continuous liveness pings back to your supervisor. | ||
378 | 148 | supervised no | ||
379 | 149 | |||
380 | 150 | # If a pid file is specified, Redis writes it where specified at startup | ||
381 | 151 | # and removes it at exit. | ||
382 | 152 | # | ||
383 | 153 | # When the server runs non daemonized, no pid file is created if none is | ||
384 | 154 | # specified in the configuration. When the server is daemonized, the pid file | ||
385 | 155 | # is used even if not specified, defaulting to "/var/run/redis.pid". | ||
386 | 156 | # | ||
387 | 157 | # Creating a pid file is best effort: if Redis is not able to create it | ||
388 | 158 | # nothing bad happens, the server will start and run normally. | ||
389 | 159 | pidfile /var/run/redis/redis-server.pid | ||
390 | 160 | |||
391 | 161 | # Specify the server verbosity level. | ||
392 | 162 | # This can be one of: | ||
393 | 163 | # debug (a lot of information, useful for development/testing) | ||
394 | 164 | # verbose (many rarely useful info, but not a mess like the debug level) | ||
395 | 165 | # notice (moderately verbose, what you want in production probably) | ||
396 | 166 | # warning (only very important / critical messages are logged) | ||
397 | 167 | loglevel notice | ||
398 | 168 | |||
399 | 169 | # Specify the log file name. Also the empty string can be used to force | ||
400 | 170 | # Redis to log on the standard output. Note that if you use standard | ||
401 | 171 | # output for logging but daemonize, logs will be sent to /dev/null | ||
402 | 172 | logfile /var/log/redis/redis-server.log | ||
403 | 173 | |||
404 | 174 | # To enable logging to the system logger, just set 'syslog-enabled' to yes, | ||
405 | 175 | # and optionally update the other syslog parameters to suit your needs. | ||
406 | 176 | # syslog-enabled no | ||
407 | 177 | |||
408 | 178 | # Specify the syslog identity. | ||
409 | 179 | # syslog-ident redis | ||
410 | 180 | |||
411 | 181 | # Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7. | ||
412 | 182 | # syslog-facility local0 | ||
413 | 183 | |||
414 | 184 | # Set the number of databases. The default database is DB 0, you can select | ||
415 | 185 | # a different one on a per-connection basis using SELECT <dbid> where | ||
416 | 186 | # dbid is a number between 0 and 'databases'-1 | ||
417 | 187 | databases 16 | ||
418 | 188 | |||
419 | 189 | # By default Redis shows an ASCII art logo only when started to log to the | ||
420 | 190 | # standard output and if the standard output is a TTY. Basically this means | ||
421 | 191 | # that normally a logo is displayed only in interactive sessions. | ||
422 | 192 | # | ||
423 | 193 | # However it is possible to force the pre-4.0 behavior and always show a | ||
424 | 194 | # ASCII art logo in startup logs by setting the following option to yes. | ||
425 | 195 | always-show-logo yes | ||
426 | 196 | |||
427 | 197 | ################################ SNAPSHOTTING ################################ | ||
428 | 198 | # | ||
429 | 199 | # Save the DB on disk: | ||
430 | 200 | # | ||
431 | 201 | # save <seconds> <changes> | ||
432 | 202 | # | ||
433 | 203 | # Will save the DB if both the given number of seconds and the given | ||
434 | 204 | # number of write operations against the DB occurred. | ||
435 | 205 | # | ||
436 | 206 | # In the example below the behaviour will be to save: | ||
437 | 207 | # after 900 sec (15 min) if at least 1 key changed | ||
438 | 208 | # after 300 sec (5 min) if at least 10 keys changed | ||
439 | 209 | # after 60 sec if at least 10000 keys changed | ||
440 | 210 | # | ||
441 | 211 | # Note: you can disable saving completely by commenting out all "save" lines. | ||
442 | 212 | # | ||
443 | 213 | # It is also possible to remove all the previously configured save | ||
444 | 214 | # points by adding a save directive with a single empty string argument | ||
445 | 215 | # like in the following example: | ||
446 | 216 | # | ||
447 | 217 | # save "" | ||
448 | 218 | |||
449 | 219 | save 900 1 | ||
450 | 220 | save 300 10 | ||
451 | 221 | save 60 10000 | ||
452 | 222 | |||
453 | 223 | # By default Redis will stop accepting writes if RDB snapshots are enabled | ||
454 | 224 | # (at least one save point) and the latest background save failed. | ||
455 | 225 | # This will make the user aware (in a hard way) that data is not persisting | ||
456 | 226 | # on disk properly, otherwise chances are that no one will notice and some | ||
457 | 227 | # disaster will happen. | ||
458 | 228 | # | ||
459 | 229 | # If the background saving process will start working again Redis will | ||
460 | 230 | # automatically allow writes again. | ||
461 | 231 | # | ||
462 | 232 | # However if you have setup your proper monitoring of the Redis server | ||
463 | 233 | # and persistence, you may want to disable this feature so that Redis will | ||
464 | 234 | # continue to work as usual even if there are problems with disk, | ||
465 | 235 | # permissions, and so forth. | ||
466 | 236 | stop-writes-on-bgsave-error yes | ||
467 | 237 | |||
468 | 238 | # Compress string objects using LZF when dump .rdb databases? | ||
469 | 239 | # For default that's set to 'yes' as it's almost always a win. | ||
470 | 240 | # If you want to save some CPU in the saving child set it to 'no' but | ||
471 | 241 | # the dataset will likely be bigger if you have compressible values or keys. | ||
472 | 242 | rdbcompression yes | ||
473 | 243 | |||
474 | 244 | # Since version 5 of RDB a CRC64 checksum is placed at the end of the file. | ||
475 | 245 | # This makes the format more resistant to corruption but there is a performance | ||
476 | 246 | # hit to pay (around 10%) when saving and loading RDB files, so you can disable it | ||
477 | 247 | # for maximum performances. | ||
478 | 248 | # | ||
479 | 249 | # RDB files created with checksum disabled have a checksum of zero that will | ||
480 | 250 | # tell the loading code to skip the check. | ||
481 | 251 | rdbchecksum yes | ||
482 | 252 | |||
483 | 253 | # The filename where to dump the DB | ||
484 | 254 | dbfilename dump.rdb | ||
485 | 255 | |||
486 | 256 | # The working directory. | ||
487 | 257 | # | ||
488 | 258 | # The DB will be written inside this directory, with the filename specified | ||
489 | 259 | # above using the 'dbfilename' configuration directive. | ||
490 | 260 | # | ||
491 | 261 | # The Append Only File will also be created inside this directory. | ||
492 | 262 | # | ||
493 | 263 | # Note that you must specify a directory here, not a file name. | ||
494 | 264 | dir /var/lib/redis | ||
495 | 265 | |||
496 | 266 | ################################# REPLICATION ################################# | ||
497 | 267 | |||
498 | 268 | # Master-Replica replication. Use replicaof to make a Redis instance a copy of | ||
499 | 269 | # another Redis server. A few things to understand ASAP about Redis replication. | ||
500 | 270 | # | ||
501 | 271 | # +------------------+ +---------------+ | ||
502 | 272 | # | Master | ---> | Replica | | ||
503 | 273 | # | (receive writes) | | (exact copy) | | ||
504 | 274 | # +------------------+ +---------------+ | ||
505 | 275 | # | ||
506 | 276 | # 1) Redis replication is asynchronous, but you can configure a master to | ||
507 | 277 | # stop accepting writes if it appears to be not connected with at least | ||
508 | 278 | # a given number of replicas. | ||
509 | 279 | # 2) Redis replicas are able to perform a partial resynchronization with the | ||
510 | 280 | # master if the replication link is lost for a relatively small amount of | ||
511 | 281 | # time. You may want to configure the replication backlog size (see the next | ||
512 | 282 | # sections of this file) with a sensible value depending on your needs. | ||
513 | 283 | # 3) Replication is automatic and does not need user intervention. After a | ||
514 | 284 | # network partition replicas automatically try to reconnect to masters | ||
515 | 285 | # and resynchronize with them. | ||
516 | 286 | # | ||
517 | 287 | # replicaof <masterip> <masterport> | ||
518 | 288 | |||
519 | 289 | # If the master is password protected (using the "requirepass" configuration | ||
520 | 290 | # directive below) it is possible to tell the replica to authenticate before | ||
521 | 291 | # starting the replication synchronization process, otherwise the master will | ||
522 | 292 | # refuse the replica request. | ||
523 | 293 | # | ||
524 | 294 | # masterauth <master-password> | ||
525 | 295 | |||
526 | 296 | # When a replica loses its connection with the master, or when the replication | ||
527 | 297 | # is still in progress, the replica can act in two different ways: | ||
528 | 298 | # | ||
529 | 299 | # 1) if replica-serve-stale-data is set to 'yes' (the default) the replica will | ||
530 | 300 | # still reply to client requests, possibly with out of date data, or the | ||
531 | 301 | # data set may just be empty if this is the first synchronization. | ||
532 | 302 | # | ||
533 | 303 | # 2) if replica-serve-stale-data is set to 'no' the replica will reply with | ||
534 | 304 | # an error "SYNC with master in progress" to all the kind of commands | ||
535 | 305 | # but to INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG, | ||
536 | 306 | # SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, | ||
537 | 307 | # COMMAND, POST, HOST: and LATENCY. | ||
538 | 308 | # | ||
539 | 309 | replica-serve-stale-data yes | ||
540 | 310 | |||
541 | 311 | # You can configure a replica instance to accept writes or not. Writing against | ||
542 | 312 | # a replica instance may be useful to store some ephemeral data (because data | ||
543 | 313 | # written on a replica will be easily deleted after resync with the master) but | ||
544 | 314 | # may also cause problems if clients are writing to it because of a | ||
545 | 315 | # misconfiguration. | ||
546 | 316 | # | ||
547 | 317 | # Since Redis 2.6 by default replicas are read-only. | ||
548 | 318 | # | ||
549 | 319 | # Note: read only replicas are not designed to be exposed to untrusted clients | ||
550 | 320 | # on the internet. It's just a protection layer against misuse of the instance. | ||
551 | 321 | # Still a read only replica exports by default all the administrative commands | ||
552 | 322 | # such as CONFIG, DEBUG, and so forth. To a limited extent you can improve | ||
553 | 323 | # security of read only replicas using 'rename-command' to shadow all the | ||
554 | 324 | # administrative / dangerous commands. | ||
555 | 325 | replica-read-only yes | ||
556 | 326 | |||
557 | 327 | # Replication SYNC strategy: disk or socket. | ||
558 | 328 | # | ||
559 | 329 | # ------------------------------------------------------- | ||
560 | 330 | # WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY | ||
561 | 331 | # ------------------------------------------------------- | ||
562 | 332 | # | ||
563 | 333 | # New replicas and reconnecting replicas that are not able to continue the replication | ||
564 | 334 | # process just receiving differences, need to do what is called a "full | ||
565 | 335 | # synchronization". An RDB file is transmitted from the master to the replicas. | ||
566 | 336 | # The transmission can happen in two different ways: | ||
567 | 337 | # | ||
568 | 338 | # 1) Disk-backed: The Redis master creates a new process that writes the RDB | ||
569 | 339 | # file on disk. Later the file is transferred by the parent | ||
570 | 340 | # process to the replicas incrementally. | ||
571 | 341 | # 2) Diskless: The Redis master creates a new process that directly writes the | ||
572 | 342 | # RDB file to replica sockets, without touching the disk at all. | ||
573 | 343 | # | ||
574 | 344 | # With disk-backed replication, while the RDB file is generated, more replicas | ||
575 | 345 | # can be queued and served with the RDB file as soon as the current child producing | ||
576 | 346 | # the RDB file finishes its work. With diskless replication instead once | ||
577 | 347 | # the transfer starts, new replicas arriving will be queued and a new transfer | ||
578 | 348 | # will start when the current one terminates. | ||
579 | 349 | # | ||
580 | 350 | # When diskless replication is used, the master waits a configurable amount of | ||
581 | 351 | # time (in seconds) before starting the transfer in the hope that multiple replicas | ||
582 | 352 | # will arrive and the transfer can be parallelized. | ||
583 | 353 | # | ||
584 | 354 | # With slow disks and fast (large bandwidth) networks, diskless replication | ||
585 | 355 | # works better. | ||
586 | 356 | repl-diskless-sync no | ||
587 | 357 | |||
588 | 358 | # When diskless replication is enabled, it is possible to configure the delay | ||
589 | 359 | # the server waits in order to spawn the child that transfers the RDB via socket | ||
590 | 360 | # to the replicas. | ||
591 | 361 | # | ||
592 | 362 | # This is important since once the transfer starts, it is not possible to serve | ||
593 | 363 | # new replicas arriving, that will be queued for the next RDB transfer, so the server | ||
594 | 364 | # waits a delay in order to let more replicas arrive. | ||
595 | 365 | # | ||
596 | 366 | # The delay is specified in seconds, and by default is 5 seconds. To disable | ||
597 | 367 | # it entirely just set it to 0 seconds and the transfer will start ASAP. | ||
598 | 368 | repl-diskless-sync-delay 5 | ||
599 | 369 | |||
600 | 370 | # Replicas send PINGs to server in a predefined interval. It's possible to change | ||
601 | 371 | # this interval with the repl_ping_replica_period option. The default value is 10 | ||
602 | 372 | # seconds. | ||
603 | 373 | # | ||
604 | 374 | # repl-ping-replica-period 10 | ||
605 | 375 | |||
606 | 376 | # The following option sets the replication timeout for: | ||
607 | 377 | # | ||
608 | 378 | # 1) Bulk transfer I/O during SYNC, from the point of view of replica. | ||
609 | 379 | # 2) Master timeout from the point of view of replicas (data, pings). | ||
610 | 380 | # 3) Replica timeout from the point of view of masters (REPLCONF ACK pings). | ||
611 | 381 | # | ||
612 | 382 | # It is important to make sure that this value is greater than the value | ||
613 | 383 | # specified for repl-ping-replica-period otherwise a timeout will be detected | ||
614 | 384 | # every time there is low traffic between the master and the replica. | ||
615 | 385 | # | ||
616 | 386 | # repl-timeout 60 | ||
617 | 387 | |||
618 | 388 | # Disable TCP_NODELAY on the replica socket after SYNC? | ||
619 | 389 | # | ||
620 | 390 | # If you select "yes" Redis will use a smaller number of TCP packets and | ||
621 | 391 | # less bandwidth to send data to replicas. But this can add a delay for | ||
622 | 392 | # the data to appear on the replica side, up to 40 milliseconds with | ||
623 | 393 | # Linux kernels using a default configuration. | ||
624 | 394 | # | ||
625 | 395 | # If you select "no" the delay for data to appear on the replica side will | ||
626 | 396 | # be reduced but more bandwidth will be used for replication. | ||
627 | 397 | # | ||
628 | 398 | # By default we optimize for low latency, but in very high traffic conditions | ||
629 | 399 | # or when the master and replicas are many hops away, turning this to "yes" may | ||
630 | 400 | # be a good idea. | ||
631 | 401 | repl-disable-tcp-nodelay no | ||
632 | 402 | |||
633 | 403 | # Set the replication backlog size. The backlog is a buffer that accumulates | ||
634 | 404 | # replica data when replicas are disconnected for some time, so that when a replica | ||
635 | 405 | # wants to reconnect again, often a full resync is not needed, but a partial | ||
636 | 406 | # resync is enough, just passing the portion of data the replica missed while | ||
637 | 407 | # disconnected. | ||
638 | 408 | # | ||
639 | 409 | # The bigger the replication backlog, the longer the time the replica can be | ||
640 | 410 | # disconnected and later be able to perform a partial resynchronization. | ||
641 | 411 | # | ||
642 | 412 | # The backlog is only allocated once there is at least a replica connected. | ||
643 | 413 | # | ||
644 | 414 | # repl-backlog-size 1mb | ||
645 | 415 | |||
646 | 416 | # After a master has no longer connected replicas for some time, the backlog | ||
647 | 417 | # will be freed. The following option configures the amount of seconds that | ||
648 | 418 | # need to elapse, starting from the time the last replica disconnected, for | ||
649 | 419 | # the backlog buffer to be freed. | ||
650 | 420 | # | ||
651 | 421 | # Note that replicas never free the backlog for timeout, since they may be | ||
652 | 422 | # promoted to masters later, and should be able to correctly "partially | ||
653 | 423 | # resynchronize" with the replicas: hence they should always accumulate backlog. | ||
654 | 424 | # | ||
655 | 425 | # A value of 0 means to never release the backlog. | ||
656 | 426 | # | ||
657 | 427 | # repl-backlog-ttl 3600 | ||
658 | 428 | |||
659 | 429 | # The replica priority is an integer number published by Redis in the INFO output. | ||
660 | 430 | # It is used by Redis Sentinel in order to select a replica to promote into a | ||
661 | 431 | # master if the master is no longer working correctly. | ||
662 | 432 | # | ||
663 | 433 | # A replica with a low priority number is considered better for promotion, so | ||
664 | 434 | # for instance if there are three replicas with priority 10, 100, 25 Sentinel will | ||
665 | 435 | # pick the one with priority 10, that is the lowest. | ||
666 | 436 | # | ||
667 | 437 | # However a special priority of 0 marks the replica as not able to perform the | ||
668 | 438 | # role of master, so a replica with priority of 0 will never be selected by | ||
669 | 439 | # Redis Sentinel for promotion. | ||
670 | 440 | # | ||
671 | 441 | # By default the priority is 100. | ||
672 | 442 | replica-priority 100 | ||
673 | 443 | |||
674 | 444 | # It is possible for a master to stop accepting writes if there are less than | ||
675 | 445 | # N replicas connected, having a lag less or equal than M seconds. | ||
676 | 446 | # | ||
677 | 447 | # The N replicas need to be in "online" state. | ||
678 | 448 | # | ||
679 | 449 | # The lag in seconds, that must be <= the specified value, is calculated from | ||
680 | 450 | # the last ping received from the replica, that is usually sent every second. | ||
681 | 451 | # | ||
682 | 452 | # This option does not GUARANTEE that N replicas will accept the write, but | ||
683 | 453 | # will limit the window of exposure for lost writes in case not enough replicas | ||
684 | 454 | # are available, to the specified number of seconds. | ||
685 | 455 | # | ||
686 | 456 | # For example to require at least 3 replicas with a lag <= 10 seconds use: | ||
687 | 457 | # | ||
688 | 458 | # min-replicas-to-write 3 | ||
689 | 459 | # min-replicas-max-lag 10 | ||
690 | 460 | # | ||
691 | 461 | # Setting one or the other to 0 disables the feature. | ||
692 | 462 | # | ||
693 | 463 | # By default min-replicas-to-write is set to 0 (feature disabled) and | ||
694 | 464 | # min-replicas-max-lag is set to 10. | ||
695 | 465 | |||
696 | 466 | # A Redis master is able to list the address and port of the attached | ||
697 | 467 | # replicas in different ways. For example the "INFO replication" section | ||
698 | 468 | # offers this information, which is used, among other tools, by | ||
699 | 469 | # Redis Sentinel in order to discover replica instances. | ||
700 | 470 | # Another place where this info is available is in the output of the | ||
701 | 471 | # "ROLE" command of a master. | ||
702 | 472 | # | ||
703 | 473 | # The listed IP and address normally reported by a replica is obtained | ||
704 | 474 | # in the following way: | ||
705 | 475 | # | ||
706 | 476 | # IP: The address is auto detected by checking the peer address | ||
707 | 477 | # of the socket used by the replica to connect with the master. | ||
708 | 478 | # | ||
709 | 479 | # Port: The port is communicated by the replica during the replication | ||
710 | 480 | # handshake, and is normally the port that the replica is using to | ||
711 | 481 | # listen for connections. | ||
712 | 482 | # | ||
713 | 483 | # However when port forwarding or Network Address Translation (NAT) is | ||
714 | 484 | # used, the replica may be actually reachable via different IP and port | ||
715 | 485 | # pairs. The following two options can be used by a replica in order to | ||
716 | 486 | # report to its master a specific set of IP and port, so that both INFO | ||
717 | 487 | # and ROLE will report those values. | ||
718 | 488 | # | ||
719 | 489 | # There is no need to use both the options if you need to override just | ||
720 | 490 | # the port or the IP address. | ||
721 | 491 | # | ||
722 | 492 | # replica-announce-ip 5.5.5.5 | ||
723 | 493 | # replica-announce-port 1234 | ||
724 | 494 | |||
725 | 495 | ################################## SECURITY ################################### | ||
726 | 496 | |||
727 | 497 | # Require clients to issue AUTH <PASSWORD> before processing any other | ||
728 | 498 | # commands. This might be useful in environments in which you do not trust | ||
729 | 499 | # others with access to the host running redis-server. | ||
730 | 500 | # | ||
731 | 501 | # This should stay commented out for backward compatibility and because most | ||
732 | 502 | # people do not need auth (e.g. they run their own servers). | ||
733 | 503 | # | ||
734 | 504 | # Warning: since Redis is pretty fast an outside user can try up to | ||
735 | 505 | # 150k passwords per second against a good box. This means that you should | ||
736 | 506 | # use a very strong password otherwise it will be very easy to break. | ||
737 | 507 | # | ||
738 | 508 | requirepass mypassword | ||
739 | 509 | |||
740 | 510 | # Command renaming. | ||
741 | 511 | # | ||
742 | 512 | # It is possible to change the name of dangerous commands in a shared | ||
743 | 513 | # environment. For instance the CONFIG command may be renamed into something | ||
744 | 514 | # hard to guess so that it will still be available for internal-use tools | ||
745 | 515 | # but not available for general clients. | ||
746 | 516 | # | ||
747 | 517 | # Example: | ||
748 | 518 | # | ||
749 | 519 | # rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 | ||
750 | 520 | # | ||
751 | 521 | # It is also possible to completely kill a command by renaming it into | ||
752 | 522 | # an empty string: | ||
753 | 523 | # | ||
754 | 524 | # rename-command CONFIG "" | ||
755 | 525 | # | ||
756 | 526 | # Please note that changing the name of commands that are logged into the | ||
757 | 527 | # AOF file or transmitted to replicas may cause problems. | ||
758 | 528 | |||
759 | 529 | ################################### CLIENTS #################################### | ||
760 | 530 | |||
761 | 531 | # Set the max number of connected clients at the same time. By default | ||
762 | 532 | # this limit is set to 10000 clients, however if the Redis server is not | ||
763 | 533 | # able to configure the process file limit to allow for the specified limit | ||
764 | 534 | # the max number of allowed clients is set to the current file limit | ||
765 | 535 | # minus 32 (as Redis reserves a few file descriptors for internal uses). | ||
766 | 536 | # | ||
767 | 537 | # Once the limit is reached Redis will close all the new connections sending | ||
768 | 538 | # an error 'max number of clients reached'. | ||
769 | 539 | # | ||
770 | 540 | # maxclients 10000 | ||
771 | 541 | |||
772 | 542 | ############################## MEMORY MANAGEMENT ################################ | ||
773 | 543 | |||
774 | 544 | # Set a memory usage limit to the specified amount of bytes. | ||
775 | 545 | # When the memory limit is reached Redis will try to remove keys | ||
776 | 546 | # according to the eviction policy selected (see maxmemory-policy). | ||
777 | 547 | # | ||
778 | 548 | # If Redis can't remove keys according to the policy, or if the policy is | ||
779 | 549 | # set to 'noeviction', Redis will start to reply with errors to commands | ||
780 | 550 | # that would use more memory, like SET, LPUSH, and so on, and will continue | ||
781 | 551 | # to reply to read-only commands like GET. | ||
782 | 552 | # | ||
783 | 553 | # This option is usually useful when using Redis as an LRU or LFU cache, or to | ||
784 | 554 | # set a hard memory limit for an instance (using the 'noeviction' policy). | ||
785 | 555 | # | ||
786 | 556 | # WARNING: If you have replicas attached to an instance with maxmemory on, | ||
787 | 557 | # the size of the output buffers needed to feed the replicas are subtracted | ||
788 | 558 | # from the used memory count, so that network problems / resyncs will | ||
789 | 559 | # not trigger a loop where keys are evicted, and in turn the output | ||
790 | 560 | # buffer of replicas is full with DELs of keys evicted triggering the deletion | ||
791 | 561 | # of more keys, and so forth until the database is completely emptied. | ||
792 | 562 | # | ||
793 | 563 | # In short... if you have replicas attached it is suggested that you set a lower | ||
794 | 564 | # limit for maxmemory so that there is some free RAM on the system for replica | ||
795 | 565 | # output buffers (but this is not needed if the policy is 'noeviction'). | ||
796 | 566 | # | ||
797 | 567 | # maxmemory <bytes> | ||
798 | 568 | |||
799 | 569 | # MAXMEMORY POLICY: how Redis will select what to remove when maxmemory | ||
800 | 570 | # is reached. You can select among five behaviors: | ||
801 | 571 | # | ||
802 | 572 | # volatile-lru -> Evict using approximated LRU among the keys with an expire set. | ||
803 | 573 | # allkeys-lru -> Evict any key using approximated LRU. | ||
804 | 574 | # volatile-lfu -> Evict using approximated LFU among the keys with an expire set. | ||
805 | 575 | # allkeys-lfu -> Evict any key using approximated LFU. | ||
806 | 576 | # volatile-random -> Remove a random key among the ones with an expire set. | ||
807 | 577 | # allkeys-random -> Remove a random key, any key. | ||
808 | 578 | # volatile-ttl -> Remove the key with the nearest expire time (minor TTL) | ||
809 | 579 | # noeviction -> Don't evict anything, just return an error on write operations. | ||
810 | 580 | # | ||
811 | 581 | # LRU means Least Recently Used | ||
812 | 582 | # LFU means Least Frequently Used | ||
813 | 583 | # | ||
814 | 584 | # Both LRU, LFU and volatile-ttl are implemented using approximated | ||
815 | 585 | # randomized algorithms. | ||
816 | 586 | # | ||
817 | 587 | # Note: with any of the above policies, Redis will return an error on write | ||
818 | 588 | # operations, when there are no suitable keys for eviction. | ||
819 | 589 | # | ||
820 | 590 | # At the date of writing these commands are: set setnx setex append | ||
821 | 591 | # incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd | ||
822 | 592 | # sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby | ||
823 | 593 | # zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby | ||
824 | 594 | # getset mset msetnx exec sort | ||
825 | 595 | # | ||
826 | 596 | # The default is: | ||
827 | 597 | # | ||
828 | 598 | # maxmemory-policy noeviction | ||
829 | 599 | |||
830 | 600 | # LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated | ||
831 | 601 | # algorithms (in order to save memory), so you can tune it for speed or | ||
832 | 602 | # accuracy. For default Redis will check five keys and pick the one that was | ||
833 | 603 | # used less recently, you can change the sample size using the following | ||
834 | 604 | # configuration directive. | ||
835 | 605 | # | ||
836 | 606 | # The default of 5 produces good enough results. 10 Approximates very closely | ||
837 | 607 | # true LRU but costs more CPU. 3 is faster but not very accurate. | ||
838 | 608 | # | ||
839 | 609 | # maxmemory-samples 5 | ||
840 | 610 | |||
841 | 611 | # Starting from Redis 5, by default a replica will ignore its maxmemory setting | ||
842 | 612 | # (unless it is promoted to master after a failover or manually). It means | ||
843 | 613 | # that the eviction of keys will be just handled by the master, sending the | ||
844 | 614 | # DEL commands to the replica as keys evict in the master side. | ||
845 | 615 | # | ||
846 | 616 | # This behavior ensures that masters and replicas stay consistent, and is usually | ||
847 | 617 | # what you want, however if your replica is writable, or you want the replica to have | ||
848 | 618 | # a different memory setting, and you are sure all the writes performed to the | ||
849 | 619 | # replica are idempotent, then you may change this default (but be sure to understand | ||
850 | 620 | # what you are doing). | ||
851 | 621 | # | ||
852 | 622 | # Note that since the replica by default does not evict, it may end using more | ||
853 | 623 | # memory than the one set via maxmemory (there are certain buffers that may | ||
854 | 624 | # be larger on the replica, or data structures may sometimes take more memory and so | ||
855 | 625 | # forth). So make sure you monitor your replicas and make sure they have enough | ||
856 | 626 | # memory to never hit a real out-of-memory condition before the master hits | ||
857 | 627 | # the configured maxmemory setting. | ||
858 | 628 | # | ||
859 | 629 | # replica-ignore-maxmemory yes | ||
860 | 630 | |||
861 | 631 | ############################# LAZY FREEING #################################### | ||
862 | 632 | |||
863 | 633 | # Redis has two primitives to delete keys. One is called DEL and is a blocking | ||
864 | 634 | # deletion of the object. It means that the server stops processing new commands | ||
865 | 635 | # in order to reclaim all the memory associated with an object in a synchronous | ||
866 | 636 | # way. If the key deleted is associated with a small object, the time needed | ||
867 | 637 | # in order to execute the DEL command is very small and comparable to most other | ||
868 | 638 | # O(1) or O(log_N) commands in Redis. However if the key is associated with an | ||
869 | 639 | # aggregated value containing millions of elements, the server can block for | ||
870 | 640 | # a long time (even seconds) in order to complete the operation. | ||
871 | 641 | # | ||
872 | 642 | # For the above reasons Redis also offers non blocking deletion primitives | ||
873 | 643 | # such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and | ||
874 | 644 | # FLUSHDB commands, in order to reclaim memory in background. Those commands | ||
875 | 645 | # are executed in constant time. Another thread will incrementally free the | ||
876 | 646 | # object in the background as fast as possible. | ||
877 | 647 | # | ||
878 | 648 | # DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled. | ||
879 | 649 | # It's up to the design of the application to understand when it is a good | ||
880 | 650 | # idea to use one or the other. However the Redis server sometimes has to | ||
881 | 651 | # delete keys or flush the whole database as a side effect of other operations. | ||
882 | 652 | # Specifically Redis deletes objects independently of a user call in the | ||
883 | 653 | # following scenarios: | ||
884 | 654 | # | ||
885 | 655 | # 1) On eviction, because of the maxmemory and maxmemory policy configurations, | ||
886 | 656 | # in order to make room for new data, without going over the specified | ||
887 | 657 | # memory limit. | ||
888 | 658 | # 2) Because of expire: when a key with an associated time to live (see the | ||
889 | 659 | # EXPIRE command) must be deleted from memory. | ||
890 | 660 | # 3) Because of a side effect of a command that stores data on a key that may | ||
891 | 661 | # already exist. For example the RENAME command may delete the old key | ||
892 | 662 | # content when it is replaced with another one. Similarly SUNIONSTORE | ||
893 | 663 | # or SORT with STORE option may delete existing keys. The SET command | ||
894 | 664 | # itself removes any old content of the specified key in order to replace | ||
895 | 665 | # it with the specified string. | ||
896 | 666 | # 4) During replication, when a replica performs a full resynchronization with | ||
897 | 667 | # its master, the content of the whole database is removed in order to | ||
898 | 668 | # load the RDB file just transferred. | ||
899 | 669 | # | ||
900 | 670 | # In all the above cases the default is to delete objects in a blocking way, | ||
901 | 671 | # like if DEL was called. However you can configure each case specifically | ||
902 | 672 | # in order to instead release memory in a non-blocking way like if UNLINK | ||
903 | 673 | # was called, using the following configuration directives: | ||
904 | 674 | |||
905 | 675 | lazyfree-lazy-eviction no | ||
906 | 676 | lazyfree-lazy-expire no | ||
907 | 677 | lazyfree-lazy-server-del no | ||
908 | 678 | replica-lazy-flush no | ||
909 | 679 | |||
910 | 680 | ############################## APPEND ONLY MODE ############################### | ||
911 | 681 | |||
912 | 682 | # By default Redis asynchronously dumps the dataset on disk. This mode is | ||
913 | 683 | # good enough in many applications, but an issue with the Redis process or | ||
914 | 684 | # a power outage may result into a few minutes of writes lost (depending on | ||
915 | 685 | # the configured save points). | ||
916 | 686 | # | ||
917 | 687 | # The Append Only File is an alternative persistence mode that provides | ||
918 | 688 | # much better durability. For instance using the default data fsync policy | ||
919 | 689 | # (see later in the config file) Redis can lose just one second of writes in a | ||
920 | 690 | # dramatic event like a server power outage, or a single write if something | ||
921 | 691 | # wrong with the Redis process itself happens, but the operating system is | ||
922 | 692 | # still running correctly. | ||
923 | 693 | # | ||
924 | 694 | # AOF and RDB persistence can be enabled at the same time without problems. | ||
925 | 695 | # If the AOF is enabled on startup Redis will load the AOF, that is the file | ||
926 | 696 | # with the better durability guarantees. | ||
927 | 697 | # | ||
928 | 698 | # Please check http://redis.io/topics/persistence for more information. | ||
929 | 699 | |||
930 | 700 | appendonly no | ||
931 | 701 | |||
932 | 702 | # The name of the append only file (default: "appendonly.aof") | ||
933 | 703 | |||
934 | 704 | appendfilename "appendonly.aof" | ||
935 | 705 | |||
936 | 706 | # The fsync() call tells the Operating System to actually write data on disk | ||
937 | 707 | # instead of waiting for more data in the output buffer. Some OS will really flush | ||
938 | 708 | # data on disk, some other OS will just try to do it ASAP. | ||
939 | 709 | # | ||
940 | 710 | # Redis supports three different modes: | ||
941 | 711 | # | ||
942 | 712 | # no: don't fsync, just let the OS flush the data when it wants. Faster. | ||
943 | 713 | # always: fsync after every write to the append only log. Slow, Safest. | ||
944 | 714 | # everysec: fsync only one time every second. Compromise. | ||
945 | 715 | # | ||
946 | 716 | # The default is "everysec", as that's usually the right compromise between | ||
947 | 717 | # speed and data safety. It's up to you to understand if you can relax this to | ||
948 | 718 | # "no" that will let the operating system flush the output buffer when | ||
949 | 719 | # it wants, for better performances (but if you can live with the idea of | ||
950 | 720 | # some data loss consider the default persistence mode that's snapshotting), | ||
951 | 721 | # or on the contrary, use "always" that's very slow but a bit safer than | ||
952 | 722 | # everysec. | ||
953 | 723 | # | ||
954 | 724 | # More details please check the following article: | ||
955 | 725 | # http://antirez.com/post/redis-persistence-demystified.html | ||
956 | 726 | # | ||
957 | 727 | # If unsure, use "everysec". | ||
958 | 728 | |||
959 | 729 | # appendfsync always | ||
960 | 730 | appendfsync everysec | ||
961 | 731 | # appendfsync no | ||
962 | 732 | |||
963 | 733 | # When the AOF fsync policy is set to always or everysec, and a background | ||
964 | 734 | # saving process (a background save or AOF log background rewriting) is | ||
965 | 735 | # performing a lot of I/O against the disk, in some Linux configurations | ||
966 | 736 | # Redis may block too long on the fsync() call. Note that there is no fix for | ||
967 | 737 | # this currently, as even performing fsync in a different thread will block | ||
968 | 738 | # our synchronous write(2) call. | ||
969 | 739 | # | ||
970 | 740 | # In order to mitigate this problem it's possible to use the following option | ||
971 | 741 | # that will prevent fsync() from being called in the main process while a | ||
972 | 742 | # BGSAVE or BGREWRITEAOF is in progress. | ||
973 | 743 | # | ||
974 | 744 | # This means that while another child is saving, the durability of Redis is | ||
975 | 745 | # the same as "appendfsync none". In practical terms, this means that it is | ||
976 | 746 | # possible to lose up to 30 seconds of log in the worst scenario (with the | ||
977 | 747 | # default Linux settings). | ||
978 | 748 | # | ||
979 | 749 | # If you have latency problems turn this to "yes". Otherwise leave it as | ||
980 | 750 | # "no" that is the safest pick from the point of view of durability. | ||
981 | 751 | |||
982 | 752 | no-appendfsync-on-rewrite no | ||
983 | 753 | |||
984 | 754 | # Automatic rewrite of the append only file. | ||
985 | 755 | # Redis is able to automatically rewrite the log file implicitly calling | ||
986 | 756 | # BGREWRITEAOF when the AOF log size grows by the specified percentage. | ||
987 | 757 | # | ||
988 | 758 | # This is how it works: Redis remembers the size of the AOF file after the | ||
989 | 759 | # latest rewrite (if no rewrite has happened since the restart, the size of | ||
990 | 760 | # the AOF at startup is used). | ||
991 | 761 | # | ||
992 | 762 | # This base size is compared to the current size. If the current size is | ||
993 | 763 | # bigger than the specified percentage, the rewrite is triggered. Also | ||
994 | 764 | # you need to specify a minimal size for the AOF file to be rewritten, this | ||
995 | 765 | # is useful to avoid rewriting the AOF file even if the percentage increase | ||
996 | 766 | # is reached but it is still pretty small. | ||
997 | 767 | # | ||
998 | 768 | # Specify a percentage of zero in order to disable the automatic AOF | ||
999 | 769 | # rewrite feature. | ||
1000 | 770 | |||
1001 | 771 | auto-aof-rewrite-percentage 100 | ||
1002 | 772 | auto-aof-rewrite-min-size 64mb | ||
1003 | 773 | |||
1004 | 774 | # An AOF file may be found to be truncated at the end during the Redis | ||
1005 | 775 | # startup process, when the AOF data gets loaded back into memory. | ||
1006 | 776 | # This may happen when the system where Redis is running | ||
1007 | 777 | # crashes, especially when an ext4 filesystem is mounted without the | ||
1008 | 778 | # data=ordered option (however this can't happen when Redis itself | ||
1009 | 779 | # crashes or aborts but the operating system still works correctly). | ||
1010 | 780 | # | ||
1011 | 781 | # Redis can either exit with an error when this happens, or load as much | ||
1012 | 782 | # data as possible (the default now) and start if the AOF file is found | ||
1013 | 783 | # to be truncated at the end. The following option controls this behavior. | ||
1014 | 784 | # | ||
1015 | 785 | # If aof-load-truncated is set to yes, a truncated AOF file is loaded and | ||
1016 | 786 | # the Redis server starts emitting a log to inform the user of the event. | ||
1017 | 787 | # Otherwise if the option is set to no, the server aborts with an error | ||
1018 | 788 | # and refuses to start. When the option is set to no, the user requires | ||
1019 | 789 | # to fix the AOF file using the "redis-check-aof" utility before to restart | ||
1020 | 790 | # the server. | ||
1021 | 791 | # | ||
1022 | 792 | # Note that if the AOF file will be found to be corrupted in the middle | ||
1023 | 793 | # the server will still exit with an error. This option only applies when | ||
1024 | 794 | # Redis will try to read more data from the AOF file but not enough bytes | ||
1025 | 795 | # will be found. | ||
1026 | 796 | aof-load-truncated yes | ||
1027 | 797 | |||
1028 | 798 | # When rewriting the AOF file, Redis is able to use an RDB preamble in the | ||
1029 | 799 | # AOF file for faster rewrites and recoveries. When this option is turned | ||
1030 | 800 | # on the rewritten AOF file is composed of two different stanzas: | ||
1031 | 801 | # | ||
1032 | 802 | # [RDB file][AOF tail] | ||
1033 | 803 | # | ||
1034 | 804 | # When loading Redis recognizes that the AOF file starts with the "REDIS" | ||
1035 | 805 | # string and loads the prefixed RDB file, and continues loading the AOF | ||
1036 | 806 | # tail. | ||
1037 | 807 | aof-use-rdb-preamble yes | ||
1038 | 808 | |||
1039 | 809 | ################################ LUA SCRIPTING ############################### | ||
1040 | 810 | |||
1041 | 811 | # Max execution time of a Lua script in milliseconds. | ||
1042 | 812 | # | ||
1043 | 813 | # If the maximum execution time is reached Redis will log that a script is | ||
1044 | 814 | # still in execution after the maximum allowed time and will start to | ||
1045 | 815 | # reply to queries with an error. | ||
1046 | 816 | # | ||
1047 | 817 | # When a long running script exceeds the maximum execution time only the | ||
1048 | 818 | # SCRIPT KILL and SHUTDOWN NOSAVE commands are available. The first can be | ||
1049 | 819 | # used to stop a script that did not yet called write commands. The second | ||
1050 | 820 | # is the only way to shut down the server in the case a write command was | ||
1051 | 821 | # already issued by the script but the user doesn't want to wait for the natural | ||
1052 | 822 | # termination of the script. | ||
1053 | 823 | # | ||
1054 | 824 | # Set it to 0 or a negative value for unlimited execution without warnings. | ||
1055 | 825 | lua-time-limit 5000 | ||
1056 | 826 | |||
1057 | 827 | ################################ REDIS CLUSTER ############################### | ||
1058 | 828 | |||
1059 | 829 | # Normal Redis instances can't be part of a Redis Cluster; only nodes that are | ||
1060 | 830 | # started as cluster nodes can. In order to start a Redis instance as a | ||
1061 | 831 | # cluster node enable the cluster support uncommenting the following: | ||
1062 | 832 | # | ||
1063 | 833 | # cluster-enabled yes | ||
1064 | 834 | |||
1065 | 835 | # Every cluster node has a cluster configuration file. This file is not | ||
1066 | 836 | # intended to be edited by hand. It is created and updated by Redis nodes. | ||
1067 | 837 | # Every Redis Cluster node requires a different cluster configuration file. | ||
1068 | 838 | # Make sure that instances running in the same system do not have | ||
1069 | 839 | # overlapping cluster configuration file names. | ||
1070 | 840 | # | ||
1071 | 841 | # cluster-config-file nodes-6379.conf | ||
1072 | 842 | |||
1073 | 843 | # Cluster node timeout is the amount of milliseconds a node must be unreachable | ||
1074 | 844 | # for it to be considered in failure state. | ||
1075 | 845 | # Most other internal time limits are multiple of the node timeout. | ||
1076 | 846 | # | ||
1077 | 847 | # cluster-node-timeout 15000 | ||
1078 | 848 | |||
1079 | 849 | # A replica of a failing master will avoid to start a failover if its data | ||
1080 | 850 | # looks too old. | ||
1081 | 851 | # | ||
1082 | 852 | # There is no simple way for a replica to actually have an exact measure of | ||
1083 | 853 | # its "data age", so the following two checks are performed: | ||
1084 | 854 | # | ||
1085 | 855 | # 1) If there are multiple replicas able to failover, they exchange messages | ||
1086 | 856 | # in order to try to give an advantage to the replica with the best | ||
1087 | 857 | # replication offset (more data from the master processed). | ||
1088 | 858 | # Replicas will try to get their rank by offset, and apply to the start | ||
1089 | 859 | # of the failover a delay proportional to their rank. | ||
1090 | 860 | # | ||
1091 | 861 | # 2) Every single replica computes the time of the last interaction with | ||
1092 | 862 | # its master. This can be the last ping or command received (if the master | ||
1093 | 863 | # is still in the "connected" state), or the time that elapsed since the | ||
1094 | 864 | # disconnection with the master (if the replication link is currently down). | ||
1095 | 865 | # If the last interaction is too old, the replica will not try to failover | ||
1096 | 866 | # at all. | ||
1097 | 867 | # | ||
1098 | 868 | # The point "2" can be tuned by user. Specifically a replica will not perform | ||
1099 | 869 | # the failover if, since the last interaction with the master, the time | ||
1100 | 870 | # elapsed is greater than: | ||
1101 | 871 | # | ||
1102 | 872 | # (node-timeout * replica-validity-factor) + repl-ping-replica-period | ||
1103 | 873 | # | ||
1104 | 874 | # So for example if node-timeout is 30 seconds, and the replica-validity-factor | ||
1105 | 875 | # is 10, and assuming a default repl-ping-replica-period of 10 seconds, the | ||
1106 | 876 | # replica will not try to failover if it was not able to talk with the master | ||
1107 | 877 | # for longer than 310 seconds. | ||
1108 | 878 | # | ||
1109 | 879 | # A large replica-validity-factor may allow replicas with too old data to failover | ||
1110 | 880 | # a master, while a too small value may prevent the cluster from being able to | ||
1111 | 881 | # elect a replica at all. | ||
1112 | 882 | # | ||
1113 | 883 | # For maximum availability, it is possible to set the replica-validity-factor | ||
1114 | 884 | # to a value of 0, which means, that replicas will always try to failover the | ||
1115 | 885 | # master regardless of the last time they interacted with the master. | ||
1116 | 886 | # (However they'll always try to apply a delay proportional to their | ||
1117 | 887 | # offset rank). | ||
1118 | 888 | # | ||
1119 | 889 | # Zero is the only value able to guarantee that when all the partitions heal | ||
1120 | 890 | # the cluster will always be able to continue. | ||
1121 | 891 | # | ||
1122 | 892 | # cluster-replica-validity-factor 10 | ||
1123 | 893 | |||
1124 | 894 | # Cluster replicas are able to migrate to orphaned masters, that are masters | ||
1125 | 895 | # that are left without working replicas. This improves the cluster ability | ||
1126 | 896 | # to resist to failures as otherwise an orphaned master can't be failed over | ||
1127 | 897 | # in case of failure if it has no working replicas. | ||
1128 | 898 | # | ||
1129 | 899 | # Replicas migrate to orphaned masters only if there are still at least a | ||
1130 | 900 | # given number of other working replicas for their old master. This number | ||
1131 | 901 | # is the "migration barrier". A migration barrier of 1 means that a replica | ||
1132 | 902 | # will migrate only if there is at least 1 other working replica for its master | ||
1133 | 903 | # and so forth. It usually reflects the number of replicas you want for every | ||
1134 | 904 | # master in your cluster. | ||
1135 | 905 | # | ||
1136 | 906 | # Default is 1 (replicas migrate only if their masters remain with at least | ||
1137 | 907 | # one replica). To disable migration just set it to a very large value. | ||
1138 | 908 | # A value of 0 can be set but is useful only for debugging and dangerous | ||
1139 | 909 | # in production. | ||
1140 | 910 | # | ||
1141 | 911 | # cluster-migration-barrier 1 | ||
1142 | 912 | |||
1143 | 913 | # By default Redis Cluster nodes stop accepting queries if they detect there | ||
1144 | 914 | # is at least an hash slot uncovered (no available node is serving it). | ||
1145 | 915 | # This way if the cluster is partially down (for example a range of hash slots | ||
1146 | 916 | # are no longer covered) all the cluster becomes, eventually, unavailable. | ||
1147 | 917 | # It automatically returns available as soon as all the slots are covered again. | ||
1148 | 918 | # | ||
1149 | 919 | # However sometimes you want the subset of the cluster which is working, | ||
1150 | 920 | # to continue to accept queries for the part of the key space that is still | ||
1151 | 921 | # covered. In order to do so, just set the cluster-require-full-coverage | ||
1152 | 922 | # option to no. | ||
1153 | 923 | # | ||
1154 | 924 | # cluster-require-full-coverage yes | ||
1155 | 925 | |||
1156 | 926 | # This option, when set to yes, prevents replicas from trying to failover its | ||
1157 | 927 | # master during master failures. However the master can still perform a | ||
1158 | 928 | # manual failover, if forced to do so. | ||
1159 | 929 | # | ||
1160 | 930 | # This is useful in different scenarios, especially in the case of multiple | ||
1161 | 931 | # data center operations, where we want one side to never be promoted if not | ||
1162 | 932 | # in the case of a total DC failure. | ||
1163 | 933 | # | ||
1164 | 934 | # cluster-replica-no-failover no | ||
1165 | 935 | |||
1166 | 936 | # In order to setup your cluster make sure to read the documentation | ||
1167 | 937 | # available at http://redis.io web site. | ||
1168 | 938 | |||
1169 | 939 | ########################## CLUSTER DOCKER/NAT support ######################## | ||
1170 | 940 | |||
1171 | 941 | # In certain deployments, Redis Cluster nodes address discovery fails, because | ||
1172 | 942 | # addresses are NAT-ted or because ports are forwarded (the typical case is | ||
1173 | 943 | # Docker and other containers). | ||
1174 | 944 | # | ||
1175 | 945 | # In order to make Redis Cluster working in such environments, a static | ||
1176 | 946 | # configuration where each node knows its public address is needed. The | ||
1177 | 947 | # following two options are used for this scope, and are: | ||
1178 | 948 | # | ||
1179 | 949 | # * cluster-announce-ip | ||
1180 | 950 | # * cluster-announce-port | ||
1181 | 951 | # * cluster-announce-bus-port | ||
1182 | 952 | # | ||
1183 | 953 | # Each instruct the node about its address, client port, and cluster message | ||
1184 | 954 | # bus port. The information is then published in the header of the bus packets | ||
1185 | 955 | # so that other nodes will be able to correctly map the address of the node | ||
1186 | 956 | # publishing the information. | ||
1187 | 957 | # | ||
1188 | 958 | # If the above options are not used, the normal Redis Cluster auto-detection | ||
1189 | 959 | # will be used instead. | ||
1190 | 960 | # | ||
1191 | 961 | # Note that when remapped, the bus port may not be at the fixed offset of | ||
1192 | 962 | # clients port + 10000, so you can specify any port and bus-port depending | ||
1193 | 963 | # on how they get remapped. If the bus-port is not set, a fixed offset of | ||
1194 | 964 | # 10000 will be used as usually. | ||
1195 | 965 | # | ||
1196 | 966 | # Example: | ||
1197 | 967 | # | ||
1198 | 968 | # cluster-announce-ip 10.1.1.5 | ||
1199 | 969 | # cluster-announce-port 6379 | ||
1200 | 970 | # cluster-announce-bus-port 6380 | ||
1201 | 971 | |||
1202 | 972 | ################################## SLOW LOG ################################### | ||
1203 | 973 | |||
1204 | 974 | # The Redis Slow Log is a system to log queries that exceeded a specified | ||
1205 | 975 | # execution time. The execution time does not include the I/O operations | ||
1206 | 976 | # like talking with the client, sending the reply and so forth, | ||
1207 | 977 | # but just the time needed to actually execute the command (this is the only | ||
1208 | 978 | # stage of command execution where the thread is blocked and can not serve | ||
1209 | 979 | # other requests in the meantime). | ||
1210 | 980 | # | ||
1211 | 981 | # You can configure the slow log with two parameters: one tells Redis | ||
1212 | 982 | # what is the execution time, in microseconds, to exceed in order for the | ||
1213 | 983 | # command to get logged, and the other parameter is the length of the | ||
1214 | 984 | # slow log. When a new command is logged the oldest one is removed from the | ||
1215 | 985 | # queue of logged commands. | ||
1216 | 986 | |||
1217 | 987 | # The following time is expressed in microseconds, so 1000000 is equivalent | ||
1218 | 988 | # to one second. Note that a negative number disables the slow log, while | ||
1219 | 989 | # a value of zero forces the logging of every command. | ||
1220 | 990 | slowlog-log-slower-than 10000 | ||
1221 | 991 | |||
1222 | 992 | # There is no limit to this length. Just be aware that it will consume memory. | ||
1223 | 993 | # You can reclaim memory used by the slow log with SLOWLOG RESET. | ||
1224 | 994 | slowlog-max-len 128 | ||
1225 | 995 | |||
1226 | 996 | ################################ LATENCY MONITOR ############################## | ||
1227 | 997 | |||
1228 | 998 | # The Redis latency monitoring subsystem samples different operations | ||
1229 | 999 | # at runtime in order to collect data related to possible sources of | ||
1230 | 1000 | # latency of a Redis instance. | ||
1231 | 1001 | # | ||
1232 | 1002 | # Via the LATENCY command this information is available to the user that can | ||
1233 | 1003 | # print graphs and obtain reports. | ||
1234 | 1004 | # | ||
1235 | 1005 | # The system only logs operations that were performed in a time equal or | ||
1236 | 1006 | # greater than the amount of milliseconds specified via the | ||
1237 | 1007 | # latency-monitor-threshold configuration directive. When its value is set | ||
1238 | 1008 | # to zero, the latency monitor is turned off. | ||
1239 | 1009 | # | ||
1240 | 1010 | # By default latency monitoring is disabled since it is mostly not needed | ||
1241 | 1011 | # if you don't have latency issues, and collecting data has a performance | ||
1242 | 1012 | # impact, that while very small, can be measured under big load. Latency | ||
1243 | 1013 | # monitoring can easily be enabled at runtime using the command | ||
1244 | 1014 | # "CONFIG SET latency-monitor-threshold <milliseconds>" if needed. | ||
1245 | 1015 | latency-monitor-threshold 0 | ||
1246 | 1016 | |||
1247 | 1017 | ############################# EVENT NOTIFICATION ############################## | ||
1248 | 1018 | |||
1249 | 1019 | # Redis can notify Pub/Sub clients about events happening in the key space. | ||
1250 | 1020 | # This feature is documented at http://redis.io/topics/notifications | ||
1251 | 1021 | # | ||
1252 | 1022 | # For instance if keyspace events notification is enabled, and a client | ||
1253 | 1023 | # performs a DEL operation on key "foo" stored in the Database 0, two | ||
1254 | 1024 | # messages will be published via Pub/Sub: | ||
1255 | 1025 | # | ||
1256 | 1026 | # PUBLISH __keyspace@0__:foo del | ||
1257 | 1027 | # PUBLISH __keyevent@0__:del foo | ||
1258 | 1028 | # | ||
1259 | 1029 | # It is possible to select the events that Redis will notify among a set | ||
1260 | 1030 | # of classes. Every class is identified by a single character: | ||
1261 | 1031 | # | ||
1262 | 1032 | # K Keyspace events, published with __keyspace@<db>__ prefix. | ||
1263 | 1033 | # E Keyevent events, published with __keyevent@<db>__ prefix. | ||
1264 | 1034 | # g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ... | ||
1265 | 1035 | # $ String commands | ||
1266 | 1036 | # l List commands | ||
1267 | 1037 | # s Set commands | ||
1268 | 1038 | # h Hash commands | ||
1269 | 1039 | # z Sorted set commands | ||
1270 | 1040 | # x Expired events (events generated every time a key expires) | ||
1271 | 1041 | # e Evicted events (events generated when a key is evicted for maxmemory) | ||
1272 | 1042 | # A Alias for g$lshzxe, so that the "AKE" string means all the events. | ||
1273 | 1043 | # | ||
1274 | 1044 | # The "notify-keyspace-events" takes as argument a string that is composed | ||
1275 | 1045 | # of zero or multiple characters. The empty string means that notifications | ||
1276 | 1046 | # are disabled. | ||
1277 | 1047 | # | ||
1278 | 1048 | # Example: to enable list and generic events, from the point of view of the | ||
1279 | 1049 | # event name, use: | ||
1280 | 1050 | # | ||
1281 | 1051 | # notify-keyspace-events Elg | ||
1282 | 1052 | # | ||
1283 | 1053 | # Example 2: to get the stream of the expired keys subscribing to channel | ||
1284 | 1054 | # name __keyevent@0__:expired use: | ||
1285 | 1055 | # | ||
1286 | 1056 | # notify-keyspace-events Ex | ||
1287 | 1057 | # | ||
1288 | 1058 | # By default all notifications are disabled because most users don't need | ||
1289 | 1059 | # this feature and the feature has some overhead. Note that if you don't | ||
1290 | 1060 | # specify at least one of K or E, no events will be delivered. | ||
1291 | 1061 | notify-keyspace-events "" | ||
1292 | 1062 | |||
1293 | 1063 | ############################### ADVANCED CONFIG ############################### | ||
1294 | 1064 | |||
1295 | 1065 | # Hashes are encoded using a memory efficient data structure when they have a | ||
1296 | 1066 | # small number of entries, and the biggest entry does not exceed a given | ||
1297 | 1067 | # threshold. These thresholds can be configured using the following directives. | ||
1298 | 1068 | hash-max-ziplist-entries 512 | ||
1299 | 1069 | hash-max-ziplist-value 64 | ||
1300 | 1070 | |||
1301 | 1071 | # Lists are also encoded in a special way to save a lot of space. | ||
1302 | 1072 | # The number of entries allowed per internal list node can be specified | ||
1303 | 1073 | # as a fixed maximum size or a maximum number of elements. | ||
1304 | 1074 | # For a fixed maximum size, use -5 through -1, meaning: | ||
1305 | 1075 | # -5: max size: 64 Kb <-- not recommended for normal workloads | ||
1306 | 1076 | # -4: max size: 32 Kb <-- not recommended | ||
1307 | 1077 | # -3: max size: 16 Kb <-- probably not recommended | ||
1308 | 1078 | # -2: max size: 8 Kb <-- good | ||
1309 | 1079 | # -1: max size: 4 Kb <-- good | ||
1310 | 1080 | # Positive numbers mean store up to _exactly_ that number of elements | ||
1311 | 1081 | # per list node. | ||
1312 | 1082 | # The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size), | ||
1313 | 1083 | # but if your use case is unique, adjust the settings as necessary. | ||
1314 | 1084 | list-max-ziplist-size -2 | ||
1315 | 1085 | |||
1316 | 1086 | # Lists may also be compressed. | ||
1317 | 1087 | # Compress depth is the number of quicklist ziplist nodes from *each* side of | ||
1318 | 1088 | # the list to *exclude* from compression. The head and tail of the list | ||
1319 | 1089 | # are always uncompressed for fast push/pop operations. Settings are: | ||
1320 | 1090 | # 0: disable all list compression | ||
1321 | 1091 | # 1: depth 1 means "don't start compressing until after 1 node into the list, | ||
1322 | 1092 | # going from either the head or tail" | ||
1323 | 1093 | # So: [head]->node->node->...->node->[tail] | ||
1324 | 1094 | # [head], [tail] will always be uncompressed; inner nodes will compress. | ||
1325 | 1095 | # 2: [head]->[next]->node->node->...->node->[prev]->[tail] | ||
1326 | 1096 | # 2 here means: don't compress head or head->next or tail->prev or tail, | ||
1327 | 1097 | # but compress all nodes between them. | ||
1328 | 1098 | # 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail] | ||
1329 | 1099 | # etc. | ||
1330 | 1100 | list-compress-depth 0 | ||
1331 | 1101 | |||
1332 | 1102 | # Sets have a special encoding in just one case: when a set is composed | ||
1333 | 1103 | # of just strings that happen to be integers in radix 10 in the range | ||
1334 | 1104 | # of 64 bit signed integers. | ||
1335 | 1105 | # The following configuration setting sets the limit in the size of the | ||
1336 | 1106 | # set in order to use this special memory saving encoding. | ||
1337 | 1107 | set-max-intset-entries 512 | ||
1338 | 1108 | |||
1339 | 1109 | # Similarly to hashes and lists, sorted sets are also specially encoded in | ||
1340 | 1110 | # order to save a lot of space. This encoding is only used when the length and | ||
1341 | 1111 | # elements of a sorted set are below the following limits: | ||
1342 | 1112 | zset-max-ziplist-entries 128 | ||
1343 | 1113 | zset-max-ziplist-value 64 | ||
1344 | 1114 | |||
1345 | 1115 | # HyperLogLog sparse representation bytes limit. The limit includes the | ||
1346 | 1116 | # 16 bytes header. When an HyperLogLog using the sparse representation crosses | ||
1347 | 1117 | # this limit, it is converted into the dense representation. | ||
1348 | 1118 | # | ||
1349 | 1119 | # A value greater than 16000 is totally useless, since at that point the | ||
1350 | 1120 | # dense representation is more memory efficient. | ||
1351 | 1121 | # | ||
1352 | 1122 | # The suggested value is ~ 3000 in order to have the benefits of | ||
1353 | 1123 | # the space efficient encoding without slowing down too much PFADD, | ||
1354 | 1124 | # which is O(N) with the sparse encoding. The value can be raised to | ||
1355 | 1125 | # ~ 10000 when CPU is not a concern, but space is, and the data set is | ||
1356 | 1126 | # composed of many HyperLogLogs with cardinality in the 0 - 15000 range. | ||
1357 | 1127 | hll-sparse-max-bytes 3000 | ||
1358 | 1128 | |||
1359 | 1129 | # Streams macro node max size / items. The stream data structure is a radix | ||
1360 | 1130 | # tree of big nodes that encode multiple items inside. Using this configuration | ||
1361 | 1131 | # it is possible to configure how big a single node can be in bytes, and the | ||
1362 | 1132 | # maximum number of items it may contain before switching to a new node when | ||
1363 | 1133 | # appending new stream entries. If any of the following settings are set to | ||
1364 | 1134 | # zero, the limit is ignored, so for instance it is possible to set just a | ||
1365 | 1135 | # max entires limit by setting max-bytes to 0 and max-entries to the desired | ||
1366 | 1136 | # value. | ||
1367 | 1137 | stream-node-max-bytes 4096 | ||
1368 | 1138 | stream-node-max-entries 100 | ||
1369 | 1139 | |||
1370 | 1140 | # Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in | ||
1371 | 1141 | # order to help rehashing the main Redis hash table (the one mapping top-level | ||
1372 | 1142 | # keys to values). The hash table implementation Redis uses (see dict.c) | ||
1373 | 1143 | # performs a lazy rehashing: the more operation you run into a hash table | ||
1374 | 1144 | # that is rehashing, the more rehashing "steps" are performed, so if the | ||
1375 | 1145 | # server is idle the rehashing is never complete and some more memory is used | ||
1376 | 1146 | # by the hash table. | ||
1377 | 1147 | # | ||
1378 | 1148 | # The default is to use this millisecond 10 times every second in order to | ||
1379 | 1149 | # actively rehash the main dictionaries, freeing memory when possible. | ||
1380 | 1150 | # | ||
1381 | 1151 | # If unsure: | ||
1382 | 1152 | # use "activerehashing no" if you have hard latency requirements and it is | ||
1383 | 1153 | # not a good thing in your environment that Redis can reply from time to time | ||
1384 | 1154 | # to queries with 2 milliseconds delay. | ||
1385 | 1155 | # | ||
1386 | 1156 | # use "activerehashing yes" if you don't have such hard requirements but | ||
1387 | 1157 | # want to free memory asap when possible. | ||
1388 | 1158 | activerehashing yes | ||
1389 | 1159 | |||
1390 | 1160 | # The client output buffer limits can be used to force disconnection of clients | ||
1391 | 1161 | # that are not reading data from the server fast enough for some reason (a | ||
1392 | 1162 | # common reason is that a Pub/Sub client can't consume messages as fast as the | ||
1393 | 1163 | # publisher can produce them). | ||
1394 | 1164 | # | ||
1395 | 1165 | # The limit can be set differently for the three different classes of clients: | ||
1396 | 1166 | # | ||
1397 | 1167 | # normal -> normal clients including MONITOR clients | ||
1398 | 1168 | # replica -> replica clients | ||
1399 | 1169 | # pubsub -> clients subscribed to at least one pubsub channel or pattern | ||
1400 | 1170 | # | ||
1401 | 1171 | # The syntax of every client-output-buffer-limit directive is the following: | ||
1402 | 1172 | # | ||
1403 | 1173 | # client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds> | ||
1404 | 1174 | # | ||
1405 | 1175 | # A client is immediately disconnected once the hard limit is reached, or if | ||
1406 | 1176 | # the soft limit is reached and remains reached for the specified number of | ||
1407 | 1177 | # seconds (continuously). | ||
1408 | 1178 | # So for instance if the hard limit is 32 megabytes and the soft limit is | ||
1409 | 1179 | # 16 megabytes / 10 seconds, the client will get disconnected immediately | ||
1410 | 1180 | # if the size of the output buffers reach 32 megabytes, but will also get | ||
1411 | 1181 | # disconnected if the client reaches 16 megabytes and continuously overcomes | ||
1412 | 1182 | # the limit for 10 seconds. | ||
1413 | 1183 | # | ||
1414 | 1184 | # By default normal clients are not limited because they don't receive data | ||
1415 | 1185 | # without asking (in a push way), but just after a request, so only | ||
1416 | 1186 | # asynchronous clients may create a scenario where data is requested faster | ||
1417 | 1187 | # than it can read. | ||
1418 | 1188 | # | ||
1419 | 1189 | # Instead there is a default limit for pubsub and replica clients, since | ||
1420 | 1190 | # subscribers and replicas receive data in a push fashion. | ||
1421 | 1191 | # | ||
1422 | 1192 | # Both the hard or the soft limit can be disabled by setting them to zero. | ||
1423 | 1193 | client-output-buffer-limit normal 0 0 0 | ||
1424 | 1194 | client-output-buffer-limit replica 256mb 64mb 60 | ||
1425 | 1195 | client-output-buffer-limit pubsub 32mb 8mb 60 | ||
1426 | 1196 | |||
1427 | 1197 | # Client query buffers accumulate new commands. They are limited to a fixed | ||
1428 | 1198 | # amount by default in order to avoid that a protocol desynchronization (for | ||
1429 | 1199 | # instance due to a bug in the client) will lead to unbound memory usage in | ||
1430 | 1200 | # the query buffer. However you can configure it here if you have very special | ||
1431 | 1201 | # needs, such us huge multi/exec requests or alike. | ||
1432 | 1202 | # | ||
1433 | 1203 | # client-query-buffer-limit 1gb | ||
1434 | 1204 | |||
1435 | 1205 | # In the Redis protocol, bulk requests, that are, elements representing single | ||
1436 | 1206 | # strings, are normally limited ot 512 mb. However you can change this limit | ||
1437 | 1207 | # here. | ||
1438 | 1208 | # | ||
1439 | 1209 | # proto-max-bulk-len 512mb | ||
1440 | 1210 | |||
1441 | 1211 | # Redis calls an internal function to perform many background tasks, like | ||
1442 | 1212 | # closing connections of clients in timeout, purging expired keys that are | ||
1443 | 1213 | # never requested, and so forth. | ||
1444 | 1214 | # | ||
1445 | 1215 | # Not all tasks are performed with the same frequency, but Redis checks for | ||
1446 | 1216 | # tasks to perform according to the specified "hz" value. | ||
1447 | 1217 | # | ||
1448 | 1218 | # By default "hz" is set to 10. Raising the value will use more CPU when | ||
1449 | 1219 | # Redis is idle, but at the same time will make Redis more responsive when | ||
1450 | 1220 | # there are many keys expiring at the same time, and timeouts may be | ||
1451 | 1221 | # handled with more precision. | ||
1452 | 1222 | # | ||
1453 | 1223 | # The range is between 1 and 500, however a value over 100 is usually not | ||
1454 | 1224 | # a good idea. Most users should use the default of 10 and raise this up to | ||
1455 | 1225 | # 100 only in environments where very low latency is required. | ||
1456 | 1226 | hz 10 | ||
1457 | 1227 | |||
1458 | 1228 | # Normally it is useful to have an HZ value which is proportional to the | ||
1459 | 1229 | # number of clients connected. This is useful in order, for instance, to | ||
1460 | 1230 | # avoid too many clients are processed for each background task invocation | ||
1461 | 1231 | # in order to avoid latency spikes. | ||
1462 | 1232 | # | ||
1463 | 1233 | # Since the default HZ value by default is conservatively set to 10, Redis | ||
1464 | 1234 | # offers, and enables by default, the ability to use an adaptive HZ value | ||
1465 | 1235 | # which will temporary raise when there are many connected clients. | ||
1466 | 1236 | # | ||
1467 | 1237 | # When dynamic HZ is enabled, the actual configured HZ will be used as | ||
1468 | 1238 | # as a baseline, but multiples of the configured HZ value will be actually | ||
1469 | 1239 | # used as needed once more clients are connected. In this way an idle | ||
1470 | 1240 | # instance will use very little CPU time while a busy instance will be | ||
1471 | 1241 | # more responsive. | ||
1472 | 1242 | dynamic-hz yes | ||
1473 | 1243 | |||
1474 | 1244 | # When a child rewrites the AOF file, if the following option is enabled | ||
1475 | 1245 | # the file will be fsync-ed every 32 MB of data generated. This is useful | ||
1476 | 1246 | # in order to commit the file to the disk more incrementally and avoid | ||
1477 | 1247 | # big latency spikes. | ||
1478 | 1248 | aof-rewrite-incremental-fsync yes | ||
1479 | 1249 | |||
1480 | 1250 | # When redis saves RDB file, if the following option is enabled | ||
1481 | 1251 | # the file will be fsync-ed every 32 MB of data generated. This is useful | ||
1482 | 1252 | # in order to commit the file to the disk more incrementally and avoid | ||
1483 | 1253 | # big latency spikes. | ||
1484 | 1254 | rdb-save-incremental-fsync yes | ||
1485 | 1255 | |||
1486 | 1256 | # Redis LFU eviction (see maxmemory setting) can be tuned. However it is a good | ||
1487 | 1257 | # idea to start with the default settings and only change them after investigating | ||
1488 | 1258 | # how to improve the performances and how the keys LFU change over time, which | ||
1489 | 1259 | # is possible to inspect via the OBJECT FREQ command. | ||
1490 | 1260 | # | ||
1491 | 1261 | # There are two tunable parameters in the Redis LFU implementation: the | ||
1492 | 1262 | # counter logarithm factor and the counter decay time. It is important to | ||
1493 | 1263 | # understand what the two parameters mean before changing them. | ||
1494 | 1264 | # | ||
1495 | 1265 | # The LFU counter is just 8 bits per key, it's maximum value is 255, so Redis | ||
1496 | 1266 | # uses a probabilistic increment with logarithmic behavior. Given the value | ||
1497 | 1267 | # of the old counter, when a key is accessed, the counter is incremented in | ||
1498 | 1268 | # this way: | ||
1499 | 1269 | # | ||
1500 | 1270 | # 1. A random number R between 0 and 1 is extracted. | ||
1501 | 1271 | # 2. A probability P is calculated as 1/(old_value*lfu_log_factor+1). | ||
1502 | 1272 | # 3. The counter is incremented only if R < P. | ||
1503 | 1273 | # | ||
1504 | 1274 | # The default lfu-log-factor is 10. This is a table of how the frequency | ||
1505 | 1275 | # counter changes with a different number of accesses with different | ||
1506 | 1276 | # logarithmic factors: | ||
1507 | 1277 | # | ||
1508 | 1278 | # +--------+------------+------------+------------+------------+------------+ | ||
1509 | 1279 | # | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits | | ||
1510 | 1280 | # +--------+------------+------------+------------+------------+------------+ | ||
1511 | 1281 | # | 0 | 104 | 255 | 255 | 255 | 255 | | ||
1512 | 1282 | # +--------+------------+------------+------------+------------+------------+ | ||
1513 | 1283 | # | 1 | 18 | 49 | 255 | 255 | 255 | | ||
1514 | 1284 | # +--------+------------+------------+------------+------------+------------+ | ||
1515 | 1285 | # | 10 | 10 | 18 | 142 | 255 | 255 | | ||
1516 | 1286 | # +--------+------------+------------+------------+------------+------------+ | ||
1517 | 1287 | # | 100 | 8 | 11 | 49 | 143 | 255 | | ||
1518 | 1288 | # +--------+------------+------------+------------+------------+------------+ | ||
1519 | 1289 | # | ||
1520 | 1290 | # NOTE: The above table was obtained by running the following commands: | ||
1521 | 1291 | # | ||
1522 | 1292 | # redis-benchmark -n 1000000 incr foo | ||
1523 | 1293 | # redis-cli object freq foo | ||
1524 | 1294 | # | ||
1525 | 1295 | # NOTE 2: The counter initial value is 5 in order to give new objects a chance | ||
1526 | 1296 | # to accumulate hits. | ||
1527 | 1297 | # | ||
1528 | 1298 | # The counter decay time is the time, in minutes, that must elapse in order | ||
1529 | 1299 | # for the key counter to be divided by two (or decremented if it has a value | ||
1530 | 1300 | # less <= 10). | ||
1531 | 1301 | # | ||
1532 | 1302 | # The default value for the lfu-decay-time is 1. A Special value of 0 means to | ||
1533 | 1303 | # decay the counter every time it happens to be scanned. | ||
1534 | 1304 | # | ||
1535 | 1305 | # lfu-log-factor 10 | ||
1536 | 1306 | # lfu-decay-time 1 | ||
1537 | 1307 | |||
1538 | 1308 | ########################### ACTIVE DEFRAGMENTATION ####################### | ||
1539 | 1309 | # | ||
1540 | 1310 | # WARNING THIS FEATURE IS EXPERIMENTAL. However it was stress tested | ||
1541 | 1311 | # even in production and manually tested by multiple engineers for some | ||
1542 | 1312 | # time. | ||
1543 | 1313 | # | ||
1544 | 1314 | # What is active defragmentation? | ||
1545 | 1315 | # ------------------------------- | ||
1546 | 1316 | # | ||
1547 | 1317 | # Active (online) defragmentation allows a Redis server to compact the | ||
1548 | 1318 | # spaces left between small allocations and deallocations of data in memory, | ||
1549 | 1319 | # thus allowing to reclaim back memory. | ||
1550 | 1320 | # | ||
1551 | 1321 | # Fragmentation is a natural process that happens with every allocator (but | ||
1552 | 1322 | # less so with Jemalloc, fortunately) and certain workloads. Normally a server | ||
1553 | 1323 | # restart is needed in order to lower the fragmentation, or at least to flush | ||
1554 | 1324 | # away all the data and create it again. However thanks to this feature | ||
1555 | 1325 | # implemented by Oran Agra for Redis 4.0 this process can happen at runtime | ||
1556 | 1326 | # in an "hot" way, while the server is running. | ||
1557 | 1327 | # | ||
1558 | 1328 | # Basically when the fragmentation is over a certain level (see the | ||
1559 | 1329 | # configuration options below) Redis will start to create new copies of the | ||
1560 | 1330 | # values in contiguous memory regions by exploiting certain specific Jemalloc | ||
1561 | 1331 | # features (in order to understand if an allocation is causing fragmentation | ||
1562 | 1332 | # and to allocate it in a better place), and at the same time, will release the | ||
1563 | 1333 | # old copies of the data. This process, repeated incrementally for all the keys | ||
1564 | 1334 | # will cause the fragmentation to drop back to normal values. | ||
1565 | 1335 | # | ||
1566 | 1336 | # Important things to understand: | ||
1567 | 1337 | # | ||
1568 | 1338 | # 1. This feature is disabled by default, and only works if you compiled Redis | ||
1569 | 1339 | # to use the copy of Jemalloc we ship with the source code of Redis. | ||
1570 | 1340 | # This is the default with Linux builds. | ||
1571 | 1341 | # | ||
1572 | 1342 | # 2. You never need to enable this feature if you don't have fragmentation | ||
1573 | 1343 | # issues. | ||
1574 | 1344 | # | ||
1575 | 1345 | # 3. Once you experience fragmentation, you can enable this feature when | ||
1576 | 1346 | # needed with the command "CONFIG SET activedefrag yes". | ||
1577 | 1347 | # | ||
1578 | 1348 | # The configuration parameters are able to fine tune the behavior of the | ||
1579 | 1349 | # defragmentation process. If you are not sure about what they mean it is | ||
1580 | 1350 | # a good idea to leave the defaults untouched. | ||
1581 | 1351 | |||
1582 | 1352 | # Enabled active defragmentation | ||
1583 | 1353 | # activedefrag yes | ||
1584 | 1354 | |||
1585 | 1355 | # Minimum amount of fragmentation waste to start active defrag | ||
1586 | 1356 | # active-defrag-ignore-bytes 100mb | ||
1587 | 1357 | |||
1588 | 1358 | # Minimum percentage of fragmentation to start active defrag | ||
1589 | 1359 | # active-defrag-threshold-lower 10 | ||
1590 | 1360 | |||
1591 | 1361 | # Maximum percentage of fragmentation at which we use maximum effort | ||
1592 | 1362 | # active-defrag-threshold-upper 100 | ||
1593 | 1363 | |||
1594 | 1364 | # Minimal effort for defrag in CPU percentage | ||
1595 | 1365 | # active-defrag-cycle-min 5 | ||
1596 | 1366 | |||
1597 | 1367 | # Maximal effort for defrag in CPU percentage | ||
1598 | 1368 | # active-defrag-cycle-max 75 | ||
1599 | 1369 | |||
1600 | 1370 | # Maximum number of set/hash/zset/list fields that will be processed from | ||
1601 | 1371 | # the main dictionary scan | ||
1602 | 1372 | # active-defrag-max-scan-fields 1000 | ||
1603 | 1373 | |||
1604 | diff --git a/examples/docker-compose.yml b/examples/docker-compose.yml | |||
1605 | 0 | new file mode 100644 | 1374 | new file mode 100644 |
1606 | index 0000000..0b97104 | |||
1607 | --- /dev/null | |||
1608 | +++ b/examples/docker-compose.yml | |||
1609 | @@ -0,0 +1,10 @@ | |||
1610 | 1 | version: '2' | ||
1611 | 2 | |||
1612 | 3 | services: | ||
1613 | 4 | redis: | ||
1614 | 5 | image: squeakywheel/redis:edge | ||
1615 | 6 | network_mode: "host" | ||
1616 | 7 | ports: | ||
1617 | 8 | - 6273:6273 | ||
1618 | 9 | environment: | ||
1619 | 10 | - REDIS_PASSWORD=mypassword | ||
1620 | diff --git a/examples/microk8s-deployments.yml b/examples/microk8s-deployments.yml | |||
1621 | 0 | new file mode 100644 | 11 | new file mode 100644 |
1622 | index 0000000..1e481eb | |||
1623 | --- /dev/null | |||
1624 | +++ b/examples/microk8s-deployments.yml | |||
1625 | @@ -0,0 +1,48 @@ | |||
1626 | 1 | --- | ||
1627 | 2 | apiVersion: apps/v1 | ||
1628 | 3 | kind: Deployment | ||
1629 | 4 | metadata: | ||
1630 | 5 | name: redis-deployment | ||
1631 | 6 | spec: | ||
1632 | 7 | replicas: 1 | ||
1633 | 8 | selector: | ||
1634 | 9 | matchLabels: | ||
1635 | 10 | app: redis | ||
1636 | 11 | template: | ||
1637 | 12 | metadata: | ||
1638 | 13 | labels: | ||
1639 | 14 | app: redis | ||
1640 | 15 | spec: | ||
1641 | 16 | containers: | ||
1642 | 17 | - name: redis | ||
1643 | 18 | image: squeakywheel/redis:edge | ||
1644 | 19 | volumeMounts: | ||
1645 | 20 | - name: redis-config-volume | ||
1646 | 21 | mountPath: /etc/redis/redis.conf | ||
1647 | 22 | subPath: redis.conf | ||
1648 | 23 | ports: | ||
1649 | 24 | - containerPort: 6379 | ||
1650 | 25 | name: redis | ||
1651 | 26 | protocol: TCP | ||
1652 | 27 | volumes: | ||
1653 | 28 | - name: redis-config-volume | ||
1654 | 29 | configMap: | ||
1655 | 30 | name: redis-config | ||
1656 | 31 | items: | ||
1657 | 32 | - key: redis | ||
1658 | 33 | path: redis.conf | ||
1659 | 34 | --- | ||
1660 | 35 | apiVersion: v1 | ||
1661 | 36 | kind: Service | ||
1662 | 37 | metadata: | ||
1663 | 38 | name: redis-service | ||
1664 | 39 | spec: | ||
1665 | 40 | type: NodePort | ||
1666 | 41 | selector: | ||
1667 | 42 | app: redis | ||
1668 | 43 | ports: | ||
1669 | 44 | - protocol: TCP | ||
1670 | 45 | port: 6379 | ||
1671 | 46 | targetPort: 6379 | ||
1672 | 47 | nodePort: 30073 | ||
1673 | 48 | name: redis |
Awesome, ty. A couple of clean up please, but with those this looks like a great start.