summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authoradam <adam@pkgsrc.org>2020-05-28 12:02:44 +0000
committeradam <adam@pkgsrc.org>2020-05-28 12:02:44 +0000
commit65a465f4452662146590c308ff0e93db53603a5a (patch)
tree3c1cf00fd6893360e5339d3dd77f1c83b17f53a2
parent0a950f02a11535911e4efb09020ecd9f60c5b727 (diff)
downloadpkgsrc-65a465f4452662146590c308ff0e93db53603a5a.tar.gz
redis: updated to 6.0.4
Redis 6.0.4 =========== Upgrade urgency CRITICAL: this release fixes a severe replication bug. Redis 6.0.4 fixes a critical replication bug caused by a new feature introduced in Redis 6. The feature, called "meaningful offset" and strongly wanted by myself (antirez) was an improvement that avoided that masters were no longer able, during a failover where they were demoted to replicas, to partially synchronize with the new master. In short the feature was able to avoid full synchronizations with RDB. How did it work? By trimming the replication backlog of the final "PING" commands the master was sending in the replication channel: this way the replication offset would no longer go "after" the one of the promoted replica, allowing the master to just continue in the same replication history, receiving only a small data difference. However after the introduction of the feature we (the Redis core team) quickly understood there was something wrong: the apparently harmless feature had many bugs, and the last bug we discovered, after a joined effort of multiple people, we were not even able to fully understand after fixing it. Enough was enough, we decided that the complexity cost of this feature was too high. So Redis 6.0.4 removes the feature entirely, and fixes the data corruption that it was able to cause. However there are two facts to take in mind. Fact 1: Setups using chained replication, that means that certain replicas are replicating from other replicas, up to Redis 6.0.3 can experience data corruption. For chained replication we mean that: +--------+ +---------+ +-------------+ | master |--------->| replica |-------->| sub-replica | +--------+ +---------+ +-------------+ People using chained replication SHOULD UPGRADE ASAP away from Redis 6.0.0, 6.0.1, 6.0.2 or 6.0.3 to Redis 6.0.4. To be clear, people NOT using this setup, but having just replicas attached directly to the master, SHOUDL NOT BE in danger of any problem. But we are no longer confident on 6.0.x replication implementation complexities so we suggest to upgrade to 6.0.4 to everybody using an older 6.0.3 release. We just so far didn't find any bug that affects Redis 6.0.3 that does not involve chained replication. People starting with Redis 6.0.4 are fine. People with Redis 5 are fine. People upgrading from Redis 5 to Redis 6.0.4 are fine. TLDR: The problem is with users of 6.0.0, 6.0.1, 6.0.2, 6.0.3. Fact 2: Upgrading from Redis 6.0.x to Redis 6.0.4, IF AND ONLY IF you use chained replication, requires some extra care: 1. Once you attach your new Redis 6.0.4 instance as a replica of the current Redis 6.0.x master, you should wait for the first full synchronization, then you should promote it right away, if your setup involves chained replication. Don't give it the time to do a new partial synchronization in the case the link between the master and the replica will break in the mean time. 2. As an additional care, you may want to set the replication ping period to a very large value (for instance 1000000) using the following command: CONFIG SET repl-ping-replica-period 1000000 Note that if you do "1" with care, "2" is not needed. However if you do it, make sure to later restore it to its default: CONFIG SET repl-ping-replica-period 10 So this is the main change in Redis 6. Later we'll find a different way in order to achieve what we wanted to achieve with the Meaningful Offset feature, but without the same complexity. Other changes in this release: * PSYNC2 tests improved. * Fix a rare active defrag edge case bug leading to stagnation * Fix Redis 6 asserting at startup in 32 bit systems. * Redis 6 32 bit is now added back to our testing environments. * Fix server crash for STRALGO command, * Implement sendfile for RDB transfer. * TLS fixes. * Make replication more resistant by disconnecting the master if we detect a protocol error. Basically we no longer accept inline protocol from the master. * Other improvements in the tests.
-rw-r--r--databases/redis/Makefile8
-rw-r--r--databases/redis/distinfo10
2 files changed, 9 insertions, 9 deletions
diff --git a/databases/redis/Makefile b/databases/redis/Makefile
index 843b7b9782b..7915888f069 100644
--- a/databases/redis/Makefile
+++ b/databases/redis/Makefile
@@ -1,6 +1,6 @@
-# $NetBSD: Makefile,v 1.52 2020/05/27 19:37:38 wiz Exp $
+# $NetBSD: Makefile,v 1.53 2020/05/28 12:02:44 adam Exp $
-DISTNAME= redis-6.0.3
+DISTNAME= redis-6.0.4
CATEGORIES= databases
MASTER_SITES= http://download.redis.io/releases/
@@ -11,8 +11,8 @@ LICENSE= modified-bsd
TEST_DEPENDS+= tcl>=8.5:../../lang/tcl
-USE_LANGUAGES= c99
-USE_TOOLS+= gmake
+USE_LANGUAGES= c99
+USE_TOOLS+= gmake
.include "../../mk/bsd.prefs.mk"
diff --git a/databases/redis/distinfo b/databases/redis/distinfo
index c773bddbf69..0619eb847e7 100644
--- a/databases/redis/distinfo
+++ b/databases/redis/distinfo
@@ -1,9 +1,9 @@
-$NetBSD: distinfo,v 1.49 2020/05/19 09:20:15 adam Exp $
+$NetBSD: distinfo,v 1.50 2020/05/28 12:02:44 adam Exp $
-SHA1 (redis-6.0.3.tar.gz) = f1feadfc75d56abfc2eb9358bc51b3afd4eb6e78
-RMD160 (redis-6.0.3.tar.gz) = ee6b2b44b28fdf9ed35ab28698007bd238d5c046
-SHA512 (redis-6.0.3.tar.gz) = 88978285db62cb8aa6e27fcd2075bbdb13f2606eaa702491047080bd6396d79d59336f0310d049d88a57e8e7b7096d716f9408b41cc658788a3902627770a807
-Size (redis-6.0.3.tar.gz) = 2210882 bytes
+SHA1 (redis-6.0.4.tar.gz) = aef1ef2006e3b250d222acfebd5da68dd2e66e3e
+RMD160 (redis-6.0.4.tar.gz) = 1f4a8839a6510f1e6d8fa1e2082ac7024372875d
+SHA512 (redis-6.0.4.tar.gz) = 8b0922fd7a9d03d4c21d4822da2c7b16a79c65151d3084b03bbacb35dfc2213a0847115c36ffbe8cc1e7b8664ed142e1e05e9f3f262a5e8a043849b398c7547d
+Size (redis-6.0.4.tar.gz) = 2217173 bytes
SHA1 (patch-redis.conf) = 528c28e2b7483eb20ccab8f2ab9543822792f016
SHA1 (patch-src_Makefile) = 17043eeff933b5eb2ffb37d2c27263939b39bf6d
SHA1 (patch-src_hyperloglog.c) = 65a4a220ccd4282162c50293f4fe278a43b84239