- 09 May, 2017 1 commit
-
-
antirez authored
More work to do with server.unixtime and similar. Need to write Helgrind suppression file in order to suppress the valse positives.
-
- 19 Apr, 2017 1 commit
-
-
antirez authored
This bug was discovered by @kevinmcgehee and constituted a major hidden bug in the PSYNC2 implementation, caused by the propagation from the master of incomplete commands to slaves. The bug had several results: 1. Borrowing from Kevin text in the issue: "Given that slaves blindly copy over their master's input into their own replication backlog over successive read syscalls, it's possible that with large commands or small TCP buffers, partial commands are present in this buffer. If the master were to fail before successfully propagating the entire command to a slave, the slaves will never execute the partial command (since the client is invalidated) but will copy it to replication backlog which may relay those invalid bytes to its slaves on PSYNC2, corrupting the backlog and possibly other valid commands that follow the failover. Simple command boundaries aren't sufficient to capture this, either, because in the case of a MULTI/EXEC block, if the master successfully propagates a subset of the commands but not the EXEC, then the transaction in the backlog becomes corrupt and could corrupt other slaves that consume this data." 2. As identified by @yangsiran later, there is another effect of the bug. For the same mechanism of the first problem, a slave having another slave, could receive a full resynchronization request with an already half-applied command in the backlog. Once the RDB is ready, it will be sent to the slave, and the replication will continue sending to the sub-slave the other half of the command, which is not valid. The fix, designed by @yangsiran and @antirez, and implemented by @antirez, uses a secondary buffer in order to feed the sub-masters and update the replication backlog and offsets, only when a given part of the query buffer is actually *applied* to the state of the instance, that is, when the command gets processed and the command is not pending in the Redis transaction buffer because of CLIENT_MULTI state. Given that now the backlog and offsets representation are in agreement with the actual processed commands, both issue 1 and 2 should no longer be possible. Thanks to @kevinmcgehee, @yangsiran and @oranagra for their work in identifying and designing a fix for this problem.
-
- 12 Apr, 2017 1 commit
-
-
antirez authored
-
- 10 Feb, 2017 1 commit
-
-
minghang.zmh authored
-
- 28 Nov, 2016 1 commit
-
-
antirez authored
This actually includes two changes: 1) No newlines to take the master-slave link up when the upstream master is down. Doing this is dangerous because the sub-slave often is received replication protocol for an half-command, so can't receive newlines without desyncing the replication link, even with the code in order to cancel out the bytes that PSYNC2 was using. Moreover this is probably also not needed/sane, because anyway the slave can keep serving requests, and because if it's configured to don't serve stale data, it's a good idea, actually, to break the link. 2) When a +CONTINUE with a different ID is received, we now break connection with the sub-slaves: they need to be notified as well. This was part of the original specification but for some reason it was not implemented in the code, and was alter found as a PSYNC2 bug in the integration testing.
-
- 25 Nov, 2016 1 commit
-
-
antirez authored
-
- 09 Nov, 2016 1 commit
-
-
antirez authored
The gist of the changes is that now, partial resynchronizations between slaves and masters (without the need of a full resync with RDB transfer and so forth), work in a number of cases when it was impossible in the past. For instance: 1. When a slave is promoted to mastrer, the slaves of the old master can partially resynchronize with the new master. 2. Chained slalves (slaves of slaves) can be moved to replicate to other slaves or the master itsef, without requiring a full resync. 3. The master itself, after being turned into a slave, is able to partially resynchronize with the new master, when it joins replication again. In order to obtain this, the following main changes were operated: * Slaves also take a replication backlog, not just masters. * Same stream replication for all the slaves and sub slaves. The replication stream is identical from the top level master to its slaves and is also the same from the slaves to their sub-slaves and so forth. This means that if a slave is later promoted to master, it has the same replication backlong, and can partially resynchronize with its slaves (that were previously slaves of the old master). * A given replication history is no longer identified by the `runid` of a Redis node. There is instead a `replication ID` which changes every time the instance has a new history no longer coherent with the past one. So, for example, slaves publish the same replication history of their master, however when they are turned into masters, they publish a new replication ID, but still remember the old ID, so that they are able to partially resynchronize with slaves of the old master (up to a given offset). * The replication protocol was slightly modified so that a new extended +CONTINUE reply from the master is able to inform the slave of a replication ID change. * REPLCONF CAPA is used in order to notify masters that a slave is able to understand the new +CONTINUE reply. * The RDB file was extended with an auxiliary field that is able to select a given DB after loading in the slave, so that the slave can continue receiving the replication stream from the point it was disconnected without requiring the master to insert "SELECT" statements. This is useful in order to guarantee the "same stream" property, because the slave must be able to accumulate an identical backlog. * Slave pings to sub-slaves are now sent in a special form, when the top-level master is disconnected, in order to don't interfer with the replication stream. We just use out of band "\n" bytes as in other parts of the Redis protocol. An old design document is available here: https://gist.github.com/antirez/ae068f95c0d084891305 However the implementation is not identical to the description because during the work to implement it, different changes were needed in order to make things working well.
-
- 03 Aug, 2016 1 commit
-
-
antirez authored
This is an attempt at mitigating problems due to cross protocol scripting, an attack targeting services using line oriented protocols like Redis that can accept HTTP requests as valid protocol, by discarding the invalid parts and accepting the payloads sent, for example, via a POST request. For this to be effective, when we detect POST and Host: and terminate the connection asynchronously, the networking code was modified in order to never process further input. It was later verified that in a pipelined request containing a POST command, the successive commands are not executed.
-
- 27 Jul, 2016 1 commit
-
-
antirez authored
This feature is useful, especially in deployments using Sentinel in order to setup Redis HA, where the slave is executed with NAT or port forwarding, so that the auto-detected port/ip addresses, as listed in the "INFO replication" output of the master, or as provided by the "ROLE" command, don't match the real addresses at which the slave is reachable for connections.
-
- 23 May, 2016 1 commit
-
-
oranagra authored
-
- 10 May, 2016 1 commit
-
-
antirez authored
-
- 25 Apr, 2016 2 commits
- 18 Feb, 2016 1 commit
-
-
antirez authored
Send a long double or double as a bulk reply, in a human friendly format.
-
- 20 Jan, 2016 1 commit
-
-
Itamar Haber authored
-
- 07 Jan, 2016 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
An exposed Redis instance on the internet can be cause of serious issues. Since Redis, by default, binds to all the interfaces, it is easy to forget an instance without any protection layer, for error. Protected mode try to address this feature in a soft way, providing a layer of protection, but giving clues to Redis users about why the server is not accepting connections. When protected mode is enabeld (the default), and if there are no minumum hints about the fact the server is properly configured (no "bind" directive is used in order to restrict the server to certain interfaces, nor a password is set), clients connecting from external intefaces are refused with an error explaining what to do in order to fix the issue. Clients connecting from the IPv4 and IPv6 lookback interfaces are still accepted normally, similarly Unix domain socket connections are not restricted in any way.
-
- 11 Dec, 2015 2 commits
- 09 Dec, 2015 1 commit
-
-
antirez authored
-
- 27 Nov, 2015 1 commit
-
-
antirez authored
-
- 09 Nov, 2015 2 commits
-
-
antirez authored
-
antirez authored
The old version only flushed data to slaves if there were strings pending in the client->reply list. Now also static buffers are flushed. Does not help to free memory (which is the only use we have right now in the fuction), but is more correct conceptually, and may be used in other contexts.
-
- 21 Oct, 2015 1 commit
-
-
antirez authored
Sometimes it can be useful for clients to completely disable replies from the Redis server. For example when the client sends fire and forget commands or performs a mass loading of data, or in caching contexts where new data is streamed constantly. In such contexts to use server time and bandwidth in order to send back replies to clients, which are going to be ignored, is a shame. Multiple mechanisms are possible to implement such a feature. For example it could be a feature of MULTI/EXEC, or a command prefix such as "NOREPLY SADD myset foo", or a different mechanism that allows to switch on/off requests using the CLIENT command. The MULTI/EXEC approach has the problem that transactions are not strictly part of the no-reply semantics, and if we want to insert a lot of data in a bulk way, creating a huge MULTI/EXEC transaction in the server memory is bad. The prefix is the best in this specific use case since it does not allow desynchronizations, and is pretty clear semantically. However Redis internals and client libraries are not prepared to handle this currently. So the implementation uses the CLIENT command, providing a new REPLY subcommand with three options: CLIENT REPLY OFF disables the replies, and does not reply itself. CLIENT REPLY ON re-enables the replies, replying +OK. CLIENT REPLY SKIP only discards the reply of the next command, and like OFF does not reply anything itself. The reason to add the SKIP command is that it allows to have an easy way to send conceptually "single" commands that don't need a reply as the sum of two pipelined commands: CLIENT REPLY SKIP SET key value Note that CLIENT REPLY ON replies with +OK so it should be used when sending multiple commands that don't need a reply. However since it replies with +OK the client can check that the connection is still active and all the previous commands were received. This is currently just into Redis "unstable" so the proposal can be modified or abandoned based on users inputs.
-
- 01 Oct, 2015 2 commits
- 30 Sep, 2015 9 commits
-
-
antirez authored
-
antirez authored
After the introduction of the list with clients with pending writes, to process clients incrementally outside of the event loop we also need to process the pending writes list.
-
antirez authored
-
antirez authored
-
antirez authored
May potentially improve locality... not exactly clear if this makes a difference or not. But for sure is harmless.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 06 Aug, 2015 2 commits
-
-
antirez authored
Talking with @oranagra we had to reason a little bit to understand if this function could ever flush the output buffers of the wrong slaves, having online state but actually not being ready to receive writes before the first ACK is received from them (this happens with diskless replication). Next time we'll just read this comment.
-
antirez authored
Add the concept of slaves capabilities to Redis, the slave now presents to the Redis master with a set of capabilities in the form: REPLCONF capa SOMECAPA capa OTHERCAPA ... This has the effect of setting slave->slave_capa with the corresponding SLAVE_CAPA macros that the master can test later to understand if it the slave will understand certain formats and protocols of the replication process. This makes it much simpler to introduce new replication capabilities in the future in a way that don't break old slaves or masters. This patch was designed and implemented together with Oran Agra (@oranagra).
-
- 28 Jul, 2015 2 commits