Hands-On with REDIS | Part 1

  • Installation of Redis-version-7 at local system.
  • Launching Redis-Server.
  • Simple Demonstration of Redis as Cache.
  • Overview of Data Persistence Options with Redis.
  • Setting up RDB configurations and Snapshotting.
  • Setting up AOF using ZSYNC.
  • Launch the Redis-Client as shown below.
  • We have set-up a Key-Value pair into the Redis.
  • The Key here is “userName” and value here is “adityagoel786”. Also, we are fetching the value, based upon Key.
  • Snapshotting / RDB file → Default mode.
  • Append-only file, or AOF → Needs to be turned-on explicitly.
  • It creates point-in-time copies of your data, that you can retrieve in case of a disaster. It’s as simple as that.
  • When conditions are met, for example, a certain number of new items in data or time base, Redis makes a snapshot of the data and writes it into an RDB file, which you can retrieve whenever needed.
  • RDB is already preconfigured, out of the box, when you first install Redis.
  • We can set up recurring backups, for example, every one, 12, or 24 hours, and use these backups to easily restore different versions of the data set in case of disasters.
  • We can also use these snapshots to create a clone of the server or simply leave them in place for a future restart.
  • If performed in the main Redis process, this would reduce the server’s performance. That’s why this work is done by a forked child process.
  • But even forking can be time consuming if the data set is large. This may result in decreased performance or in Redis failing to serve clients for a few milliseconds or even up to a second for very large data sets.
  • We can configure the name and location of the RDB file with the dbfilename and dir configuration directives either through the redis.conf file or through the Redis CLI.
  • We can configure how often we want to create a snapshot. Here’s an excerpt from the redis.conf file showing the default values :-
  • After 3600 seconds (an hour) if at least 1 change was performed.
  • After 300 seconds (5 minutes) if at least 100 changes were performed.
  • After 60 seconds if at least 10,000 changes were performed.
  • This configuration is for large, large database when there’s a lot of changes.
  • So, if you have a lot of transactions, then maybe you should use some configuration like it.
save “”
  • These commands can then be replayed to server startup to reconstruct the original data set.
  • Commands are logged using the same format as the Redis protocol itself in an append only fashion.
  • You can turn on an option called append-only file, or AOF, which logs every operation in the system file.
  • What it’ll do is basically take all the transactions that happened and then create a log file with all those transactions inside of this particular file.
  • So, when the Redis server is restarted, it rebuilds a database from this file.
  • By default, this option is off. All we need to do is say, yes, and you have AOF set. The only thing we need to do is restart our server with the configuration file.
  • And then, to check if AOF is officially started, go back into our directory here, and you should see a file that’s called appendonly.aof. So, that’s basically the file that’s been built when you start your server and you have append-only as, yes.
  • The AOF approach provides greater durability than snapshotting and allows you to configure how often the syncs happen.
  • FYSNC every write, the safest policy → The write is acknowledged to the client only after it has been written to the AOF file and flushed to disk. Since in this approach, we are writing to disk synchronously, we can expect a much higher latency than usual.
  • FYSNC every second, the default policy → FYSNC is performed asynchronously in a background thread. So, write performance is still high. Choose this option if you need high performance and can afford to lose up to one second worth of writes.
  • No FYSNC → In this case, Redis will log the command to the file descriptor but will not force the OS to flush the data to disk. If the OS crashes, we can lose a few seconds of data. Normally, Linux will flush data every 30 seconds with this configuration. But it’s up to the kernel’s exact tuning.
  • RDB for its disaster-recovery features i.e. Snapshotting.
  • AOF for its speed and availability.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
aditya goel

aditya goel

Software Engineer for Big Data distributed systems