- 05 Aug, 2015 2 commits
-
-
antirez authored
In previous commits we moved the FULLRESYNC to the moment we start the BGSAVE, so that the offset we provide is the right one. However this also means that we need to re-emit the SELECT statement every time a new slave starts to accumulate the changes. To obtian this effect in a more clean way, the function that sends the FULLRESYNC reply was overloaded with a more important role of also doing this and chanigng the slave state. So it was renamed to replicationSetupSlaveForFullResync() to better reflect what it does now.
-
antirez authored
This commit attempts to fix a bug involving PSYNC and diskless replication (currently experimental) found by Yuval Inbar from Redis Labs and that was later found to have even more far reaching effects (the bug also exists when diskstore is off). The gist of the bug is that, a Redis master replies with +FULLRESYNC to a PSYNC attempt that fails and requires a full resynchronization. However, the baseline offset sent along with FULLRESYNC was always the current master replication offset. This is not ok, because there are many reasosn that may delay the RDB file creation. And... guess what, the master offset we communicate must be the one of the time the RDB was created. So for example: 1) When the BGSAVE for replication is delayed since there is one already but is not good for replication. 2) When the BGSAVE is not needed as we attach one currently ongoing. 3) When because of diskless replication the BGSAVE is delayed. In all the above cases the PSYNC reply is wrong and the slave may reconnect later claiming to need a wrong offset: this may cause data curruption later.
-
- 24 Mar, 2015 1 commit
-
-
antirez authored
Bug as old as Redis and blocking operations. It's hard to trigger since only happens on instance role switch, but the results are quite bad since an inconsistency between master and slave is created. How to trigger the bug is a good description of the bug itself. 1. Client does "BLPOP mylist 0" in master. 2. Master is turned into slave, that replicates from New-Master. 3. Client does "LPUSH mylist foo" in New-Master. 4. New-Master propagates write to slave. 5. Slave receives the LPUSH, the blocked client get served. Now Master "mylist" key has "foo", Slave "mylist" key is empty. Highlights: * At step "2" above, the client remains attached, basically escaping any check performed during command dispatch: read only slave, in that case. * At step "5" the slave (that was the master), serves the blocked client consuming a list element, which is not consumed on the master side. This scenario is technically likely to happen during failovers, however since Redis Sentinel already disconnects clients using the CLIENT command when changing the role of the instance, the bug is avoided in Sentinel deployments. Closes #2473.
-
- 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.
-
- 09 Jan, 2015 1 commit
-
-
antirez authored
-
- 03 Dec, 2014 2 commits
- 12 Nov, 2014 1 commit
-
-
antirez authored
RDB EOF detection was relying on the final part of the RDB transfer to be a magic 40 bytes EOF marker. However as the slave is put online immediately, and because of sockets timeouts, the replication stream is actually contiguous with the RDB file. This means that to detect the EOF correctly we should either: 1) Scan all the stream searching for the mark. Sucks CPU-wise. 2) Start to send the replication stream only after an acknowledge. 3) Implement a proper chunked encoding. For now solution "2" was picked, so the master does not start to send ASAP the stream of commands in the case of diskless replication. We wait for the first REPLCONF ACK command from the slave, that certifies us that the slave correctly loaded the RDB file and is ready to get more data.
-
- 29 Oct, 2014 8 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
We need to remember what is the saving strategy of the current RDB child process, since the configuration may be modified at runtime via CONFIG SET and still we'll need to understand, when the child exists, what to do and for what goal the process was initiated: to create an RDB file on disk or to write stuff directly to slave's sockets.
-
- 06 Oct, 2014 1 commit
-
-
xuxiang authored
Closes #1386
-
- 19 Sep, 2014 1 commit
-
-
antirez authored
-
- 08 Sep, 2014 1 commit
-
-
antirez authored
-
- 26 Aug, 2014 5 commits
-
-
antirez authored
-
charsyam authored
Also moves acceptHandler() to be near the other accept...() functions. Closes #1105
-
cubicdaiya authored
According to the C standard, it is desirable to give the type 'void' to functions have no argument. Closes #1631
-
antirez authored
-
siahl authored
Closes #1900
-
- 18 Jul, 2014 8 commits
-
-
antirez authored
The code tested many times if a client had active Pub/Sub subscriptions by checking the length of a list and dictionary where the patterns and channels are stored. This was substituted with a client flag called REDIS_PUBSUB that is simpler to test for. Moreover in order to manage this flag some code was refactored. This commit is believed to have no effects in the behavior of the server.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
It is not a good idea to bloat the code with gettimeofday() calls if the instance is working well, and turning monitoring on at runtime is a joke.
-
antirez authored
-
antirez authored
We introduce the distinction between slow and fast commands since those are two different sources of latency. An O(1) or O(log N) command without side effects (can't trigger deletion of large objects as a side effect of its execution) if delayed is a symptom of inherent latency of the system. A non-fast command (commands that may run large O(N) computations) if delayed may just mean that the user is executing slow operations. The advices LATENCY should provide in this two different cases are different, so we log the two classes of commands in a separated way.
-
antirez authored
-
- 27 Jun, 2014 2 commits
-
-
antirez authored
-
Matt Stancliff authored
COMMANDS returns a nested multibulk reply for each command in the command table. The reply for each command contains: - command name - arity - array of command flags - start key position - end key position - key offset step - optional: if the keys are not deterministic and Redis uses an internal key evaluation function, the 6th field appears and is defined as a status reply of: REQUIRES ARGUMENT PARSING Cluster clients need to know where the keys are in each command to implement proper routing to cluster nodes. Redis commands can have multiple keys, keys at offset steps, or other issues where you can't always assume the first element after the command name is the cluster routing key. Using the information exposed by COMMANDS, client implementations can have live, accurate key extraction details for all commands. Also implements COMMANDS INFO [commands...] to return only a specific set of commands instead of all 160+ commands live in Redis.
-
- 26 Jun, 2014 1 commit
-
-
antirez authored
-
- 23 Jun, 2014 1 commit
-
-
Matt Stancliff authored
We need to access (bindaddr[0] || NULL) in a few places, so centralize access with a nice macro.
-
- 21 Jun, 2014 4 commits
-
-
antirez authored
-
antirez authored
This will be used by CLIENT KILL and is also a good way to ensure a given client is still the same across CLIENT LIST calls. The output of CLIENT LIST was modified to include the new ID, but this change is considered to be backward compatible as the API does not imply you can do positional parsing, since each filed as a different name.
-
antirez authored
Because of output buffer limits Redis internals had this idea of type of clients: normal, pubsub, slave. It is possible to set different output buffer limits for the three kinds of clients. However all the macros and API were named after output buffer limit classes, while the idea of a client type is a generic one that can be reused. This commit does two things: 1) Rename the API and defines with more general names. 2) Change the class of clients executing the MONITOR command from "slave" to "normal". "2" is a good idea because you want to have very special settings for slaves, that are not a good idea for MONITOR clients that are instead normal clients even if they are conceptually slave-alike (since it is a push protocol). The backward-compatibility breakage resulting from "2" is considered to be minimal to care, since MONITOR is a debugging command, and because anyway this change is not going to break the format or the behavior, but just when a connection is closed on big output buffer issues.
-
antirez authored
The new ROLE command is designed in order to provide a client with informations about the replication in a fast and easy to use way compared to the INFO command where the same information is also available.
-