3.0 #4295
Closed
3.0 #4295
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Chris Lamb <chris@chris-lamb.co.uk>
Related to PR #2357.
Related to PR #2357.
Avoid redundant SELECT calls when continuously migrating keys to the same dbid within a target Redis instance.
Add last_dbid to migrateCachedSocket to avoid redundant SELECT
1. Remove useless "cs" initialization. 2. Add a "select" var to capture a condition checked multiple times. 3. Avoid duplication of the same if (!copy) conditional. 4. Don't increment dirty if copy is given (no deletion is performed), otherwise we propagate MIGRATE when not needed.
Itereator misuse due to analyzeLatencyForEvent() accessing the dictionary during the iteration, without the iterator being reclared as safe.
When trying to debug sentinel connections or max connections errors it would be very useful to have the ability to see the list of connected clients to a running sentinel. At the same time it would be very helpful to be able to name each sentinel connection or kill offending clients. This commits adds the already defined CLIENT commands back to Redis Sentinel.
Less grays: more readable palette since usually we have a non linear distribution of percentages and very near gray tones are hard to take apart. Final part of the palette is gradient from yellow to red. The red part is hardly reached because of usual distribution of latencies, but shows up mainly when latencies are very high because of the logarithmic scale, this is coherent to what people expect: red = bad.
Backtrace is a glibc extension, while setproctitle() implementation depends on the memory layout and is partially libc dependent.
Related to issue #2372.
There are rare conditions where node->slaveof may be NULL even if the node is a slave. To check by flag is much more robust.
…essing. Related to issue #2288.
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.
When the list of unblocked clients were processed, btype was set to blocking type none, but the client remained flagged with REDIS_BLOCKED. When timeout is reached (or when the client disconnects), unblocking it will trigger an assertion. There is no need to process pending requests from blocked clients, so now clientsArePaused() just avoid touching blocked clients. Close #2467.
This commit moves the process of generating a new config epoch without consensus out of the clusterCommand() implementation, in order to make it reusable for other reasons (current target is to have a CLUSTER FAILOVER option forcing the failover when no master majority is reachable). Moreover the commit moves other functions which are similarly related to config epochs in a new logical section of the cluster.c file, just for clarity.
Certain things were only applicable to 3.2.0 RC2 and RC3.
CLUSTER SLOTS now includes IDs in the nodes description associated with a given slot range. Certain client libraries implementations need a way to reference a node in an unique way, so they were relying on CLUSTER NODES, that is not a stable API and may change frequently depending on Redis Cluster future requirements.
Removes more spuriousness from 3.0.7
…buf free space in cmsgpack
Ensure slots are rechecked on EXEC.
Thanks to @tushar2708 for the PR. I applied a slightly different fix. Thanks to @cespare for reporting. Close #3024 Close #3020
Fix issue in case the redirect address is in ipv6 format. Parse from behind to extract last part of the response which represents actual port.
This fixes a bug introduced by d827dbf, and makes the code consistent with the logic of always allowing, while the cluster is down, commands that don't target any key. As a side effect the code is also simpler now.
This fixes issue #3043. Before this fix, after a complete resharding of a master slots to other nodes, the master remains empty and the slaves migrate away to other masters with non-zero nodes. However the old master now empty, is no longer considered a target for migration, because the system has no way to tell it had slaves in the past. This fix leaves the algorithm used in the past untouched, but adds a new rule. When a new or old master which is empty and without slaves, are assigend with their first slot, if other masters in the cluster have slaves, they are automatically considered to be targets for replicas migration.
1 microsecond = 1000 nanoseconds 1e3 = 1000 10e3 = 10000
fix comment "b > a" to "a > b"
Ziplists had a bug that was discovered while investigating a different issue, resulting in a corrupted ziplist representation, and a likely segmentation foult and/or data corruption of the last element of the ziplist, once the ziplist is accessed again. The bug happens when a specific set of insertions / deletions is performed so that an entry is encoded to have a "prevlen" field (the length of the previous entry) of 5 bytes but with a count that could be encoded in a "prevlen" field of a since byte. This could happen when the "cascading update" process called by ziplistInsert()/ziplistDelete() in certain contitious forces the prevlen to be bigger than necessary in order to avoid too much data moving around. Once such an entry is generated, inserting a very small entry immediately before it will result in a resizing of the ziplist for a count smaller than the current ziplist length (which is a violation, inserting code expects the ziplist to get bigger actually). So an FF byte is inserted in a misplaced position. Moreover a realloc() is performed with a count smaller than the ziplist current length so the final bytes could be trashed as well. SECURITY IMPLICATIONS: Currently it looks like an attacker can only crash a Redis server by providing specifically choosen commands. However a FF byte is written and there are other memory operations that depend on a wrong count, so even if it is not immediately apparent how to mount an attack in order to execute code remotely, it is not impossible at all that this could be done. Attacks always get better... and we did not spent enough time in order to think how to exploit this issue, but security researchers or malicious attackers could.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.