# Diskless replication: a few design notes.

DevFeed: [Diskless replication: a few design notes.](<https://devfeed.tech/articles/diskless-replication-a-few-design-notes-20672.md>)

Original publisher: [Read original article](<http://antirez.com/news/81>)

Published: 2014-10-27T16:34:15Z

Content type: tutorial

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [cache](<https://devfeed.tech/tags/cache.md>), [ec2](<https://devfeed.tech/tags/ec2.md>), [internals](<https://devfeed.tech/tags/internals.md>), [redis](<https://devfeed.tech/tags/redis.md>), [replication](<https://devfeed.tech/tags/replication.md>)

## AI overview

The article documents the design and implementation challenges of diskless replication in Redis. It explains why Redis users, especially those using Redis as a cache or on EC2, may want replication without relying on disk durability, and begins describing how replication previously worked.

## Source excerpt

Almost a month ago a number of people interested in Redis development met in London for the first Redis developers meeting. We identified together a number of features that are urgent (and are now listed in a Github issue here: https://github.com/antirez/redis/issues/2045), and among the identified issues, there was one that was mentioned multiple times in the course of the day: diskless replication. The feature is not exactly a new idea, it was proposed several times, especially by EC2 users that know that sometimes it is not trivial for a master to provide good performances during slaves synchronization. However there are a number of use cases where you don't want to touch disks, even running on physical servers, and especially when Redis is used as a cache. Redis replication was, in short, forcing users to use disk even when they don't need or want disk durability. When I returned back home I wanted to provide a quick feedback to the developers that attended the meeting, so the first thing I did was to focus on implementing the feature that seemed the most important and non-trivial among the list of identified issues. In the next weeks the attention will be moved to the Redis development process as well: the way issues are handled, how new ideas can be proposed to the Redis project, and so forth. Sorry for the delay about these other important things, for now what you can get is, some code at least ;-) Diskless replication provided a few design challenges. It looks trivial but it is not, so since I want to blog more, I thought about documenting how the internals of this feature work. I'm sure that a blog post may make the understanding and adoption of the new feature simpler. How replication used to work === Newer versions of Redis are able, when the connection with the master is lost, to reconnect with the master, and continue the replication process in an incremental way just fetching the differences accumulated so far. However when a slave is disconnected for