- 09 May, 2020 1 commit
-
-
antirez authored
We want to send pings and pongs at specific intervals, since our packets also contain information about the configuration of the cluster and are used for gossip. However since our cluster bus is used in a mixed way for data (such as Pub/Sub or modules cluster messages) and metadata, sometimes a very busy channel may delay the reception of pong packets. So after discussing it in #7216, this commit introduces a new field that is not exposed in the cluster, is only an internal information about the last time we received any data from a given node: we use this field in order to avoid detecting failures, claiming data reception of new data from the node is a proof of liveness.
-
- 17 Dec, 2019 1 commit
-
-
Madelyn Olson authored
-
- 28 Nov, 2019 1 commit
-
-
Oran Agra authored
Changes in behavior: - Change server.stream_node_max_entries from int64_t to long long, so that it can be used by the generic infra - standard error reply instead of "repl-backlog-size must be 1 or greater" and such - tls-port and a few TLS booleans were readable (config get) even when USE_OPENSSL was off (now they aren't) - syslog-enabled, syslog-ident, cluster-enabled, appendfilename, and supervised didn't have a get (now they do) - pidfile was initialized to NULL in InitServerConfig but had CONFIG_DEFAULT_PID_FILE in rewriteConfig (so the real default was "", but rewrite would cause it to be set), fixed the rewrite. - TLS config in server.h was uninitialized (if no tls config args were provided) Adding test for sanity and coverage
-
- 07 Oct, 2019 1 commit
-
-
Yossi Gottlieb authored
* Introduce a connection abstraction layer for all socket operations and integrate it across the code base. * Provide an optional TLS connections implementation based on OpenSSL. * Pull a newer version of hiredis with TLS support. * Tests, redis-cli updates for TLS support.
-
- 19 Sep, 2018 2 commits
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 29 Mar, 2018 1 commit
-
-
antirez authored
-
- 14 Mar, 2018 1 commit
-
-
antirez authored
This commit, in some parts derived from PR #3041 which is no longer possible to merge (because the user deleted the original branch), implements the ability of slaves to have a special configuration preventing that they try to start a failover when the master is failing. There are multiple reasons for wanting this, and the feautre was requested in issue #3021 time ago. The differences between this patch and the original PR are the following: 1. The flag is saved/loaded on the nodes configuration. 2. The 'myself' node is now flag-aware, the flag is updated as needed when the configuration is changed via CONFIG SET. 3. The flag name uses NOFAILOVER instead of NO_FAILOVER to be consistent with existing NOADDR. 4. The redis.conf documentation was rewritten. Thanks to @deep011 for the original patch.
-
- 04 Jun, 2017 1 commit
-
-
Antonio Mallia authored
-
- 14 Apr, 2017 1 commit
-
-
antirez authored
To rely on the fact that nodes in PFAIL state will be shared around by randomly adding them in the gossip section is a weak assumption, especially after changes related to sending less ping/pong packets. We want to always include gossip entries for all the nodes that are in PFAIL state, so that the PFAIL -> FAIL state promotion can happen much faster and reliably. Related to #3929.
-
- 13 Apr, 2017 1 commit
-
-
antirez authored
First step in order to change Cluster in order to use less messages. Related to issue #3929.
-
- 27 Mar, 2017 1 commit
-
-
antirez authored
-
- 29 Jan, 2016 2 commits
- 14 Jan, 2016 1 commit
-
-
antirez authored
-
- 11 Dec, 2015 1 commit
-
-
antirez authored
We wait a fixed amount of time (5 seconds currently) much greater than the usual Cluster node to node communication latency, before migrating. This way when a failover occurs, before detecting the new master as a target for migration, we give the time to its natural slaves (the slaves of the failed over master) to announce they switched to the new master, preventing an useless migration operation.
-
- 09 Dec, 2015 1 commit
-
-
antirez authored
Some time ago I broken replicas migration (reported in #2924). The idea was to prevent masters without replicas from getting replicas because of replica migration, I remember it to create issues with tests, but there is no clue in the commit message about why it was so undesirable. However my patch as a side effect totally ruined the concept of replicas migration since we want it to work also for instances that, technically, never had slaves in the past: promoted slaves. So now instead the ability to be targeted by replicas migration, is a new flag "migrate-to". It only applies to masters, and is set in the following two cases: 1. When a master gets a slave, it is set. 2. When a slave turns into a master because of fail over, it is set. This way replicas migration targets are only masters that used to have slaves, and slaves of masters (that used to have slaves... obviously) and are promoted. The new flag is only internal, and is never exposed in the output nor persisted in the nodes configuration, since all the information to handle it are implicit in the cluster configuration we already have.
-
- 27 Jul, 2015 2 commits
- 26 Jul, 2015 1 commit
-
-
antirez authored
-
- 24 Mar, 2015 1 commit
-
-
antirez authored
There was a bug in Redis Cluster caused by clients blocked in a blocking list pop operation, for keys no longer handled by the instance, or in a condition where the cluster became down after the client blocked. A typical situation is: 1) BLPOP <somekey> 0 2) <somekey> hash slot is resharded to another master. The client will block forever int this case. A symmentrical non-cluster-specific bug happens when an instance is turned from master to slave. In that case it is more serious since this will desynchronize data between slaves and masters. This other bug was discovered as a side effect of thinking about the bug explained and fixed in this commit, but will be fixed in a separated commit.
-
- 20 Mar, 2015 1 commit
-
-
antirez authored
Before we relied on the global cluster state to make sure all the hash slots are linked to some node, when getNodeByQuery() is called. So finding the hash slot unbound was checked with an assertion. However this is fragile. The cluster state is often updated in the clusterBeforeSleep() function, and not ASAP on state change, so it may happen to process clients with a cluster state that is 'ok' but yet certain hash slots set to NULL. With this commit the condition is also checked in getNodeByQuery() and reported with a identical error code of -CLUSTERDOWN but slightly different error message so that we have more debugging clue in the future. Root cause of issue #2288.
-
- 13 Jan, 2015 1 commit
-
-
antirez authored
Also explicitly set version to 0, add a protocol version define, improve comments in the gossip structure. Note that the structure layout is the same after the change, we are just making the padding explicit with an additional not used 16 bits field. So this commit is still able to talk with the previous versions of cluster nodes.
-
- 28 Nov, 2014 1 commit
-
-
antirez authored
bulk_data field size was not removed from the count. It is not possible to declare it simply as 'char bulk_data[]' since the structure is nested into another structure.
-
- 07 Oct, 2014 1 commit
-
-
antirez authored
-
- 29 Sep, 2014 1 commit
-
-
Matt Stancliff authored
- Remove trailing newlines from redis.conf - Fix comment misspelling - Clarifies zipEncodeLength usage and a C API mention (#1243, #1242) - Fix cluster typos (inspired by @papanikge #1507) - Fix rewite -> rewrite in a few places (inspired by #682) Closes #1243, #1242, #1507
-
- 17 Sep, 2014 1 commit
-
-
antirez authored
-
- 25 Aug, 2014 1 commit
-
-
antirez authored
-
- 22 May, 2014 1 commit
-
-
antirez authored
Check the commit changes in the example redis.conf for more information.
-
- 27 Mar, 2014 1 commit
-
-
antirez authored
Use cammel case for epochs that are persisted on disk.
-
- 10 Mar, 2014 1 commit
-
-
antirez authored
When node-timeout is too small, in the order of a few milliseconds, there is no way the voting process can terminate during that time, so we set a lower limit for the failover timeout of two seconds. The retry time is set to two times the failover timeout time, so it is at least 4 seconds.
-
- 07 Mar, 2014 1 commit
-
-
antirez authored
-
- 06 Mar, 2014 1 commit
-
-
Matt Stancliff authored
REDIS_CLUSTER_IPLEN had the same value as REDIS_IP_STR_LEN. They were both #define'd to the same INET6_ADDRSTRLEN.
-
- 25 Feb, 2014 1 commit
-
-
Matt Stancliff authored
-
- 10 Feb, 2014 3 commits
- 05 Feb, 2014 2 commits