# Redis PSYNC2 bug post mortem

DevFeed: [Redis PSYNC2 bug post mortem](<https://devfeed.tech/articles/redis-psync2-bug-post-mortem-20606.md>)

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

Published: 2017-12-02T14:44:32Z

Content type: article

Language: en

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

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Post Mortem](<https://devfeed.tech/topics/post-mortem.md>), [bug](<https://devfeed.tech/topics/bug.md>), [Replication](<https://devfeed.tech/topics/replication.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [failover](<https://devfeed.tech/tags/failover.md>), [issue](<https://devfeed.tech/tags/issue.md>), [post-mortem](<https://devfeed.tech/tags/post-mortem.md>), [redis](<https://devfeed.tech/tags/redis.md>), [replication](<https://devfeed.tech/tags/replication.md>), [state](<https://devfeed.tech/tags/state.md>)

## AI overview

A post mortem examines a critical Redis 4.0 PSYNC2 replication bug affecting the restart-and-resynchronize behavior of slave instances. The article attributes the issue to the feature's late addition and the difficulty of restoring all replication state after a restart.

## Source excerpt

Four days ago a user posted a critical issue in the Redis Github repository. The problem was related to the new Redis 4.0 PSYNC2 replication protocol, and was very critical. PSYNC2 brings a number of good things to Redis replication, including the ability to resynchronize just exchanging the differences, and not the whole data set, after a failover, and even after a slave controlled restart. The problem was about this latter feature: with PSYNC2 the RDB file is augmented with replication information. After a slave is restarted, the replication metadata is loaded back, and the slave is able to perform a PSYNC attempt, trying to handshake with the master and receive the differences since the last disconnection. All this is good news from the point of view of Redis operations, however while PSYNC2 was pretty solid since the introduction in Redis 4.0.0 stable, the feature involving a restarting slave was definitely lacking reliability. There were two problems with this feature: the first being that it was a last-minute addition to PSYNC2, and was not part of the original design document. It was more like an obvious extension of the work we did in PSYNC2, but was not scrutinized at the same level of the rest of the specification for potential bugs and issues. The second problem was due to the fact that the feature is more complex than it looks like initially, for the fact that it's tricky to really restore *all* the state the replication has in the slave side after a restart. Moreover, failing to restore certain bits of the state, does not result in evident bugs most of the times, so they are hard to spot via integration testings. Only once specific conditions happen the lack of some state will result in problems. For instance failing to correctly reconstruct the currently selected DB in the slave replication state, will create problems only when there are writes happening in different Redis DBs, and such bug would not store correctly the currently selected DB only under