- 27 7月, 2015 1 次提交
-
-
由 antirez 提交于
-
- 26 7月, 2015 5 次提交
- 11 6月, 2015 1 次提交
-
-
由 antirez 提交于
We usually want to reach the master using the address of the interface Redis is bound to (via the "bind" config option). That's useful since the master will get (and publish) the slave address getting the peer name of the incoming socket connection from the slave. However, when this is not possible, for example because the slave is bound to the loopback interface but repliaces from a master accessed via an external interface, we want to still connect with the master even from a different interface: in this case it is not really important that the master will provide any other address, while it is vital to be able to replicate correctly. Related to issues #2609 and #2612.
-
- 01 4月, 2015 2 次提交
-
-
由 antirez 提交于
When we fail to setup the write handler it does not make sense to take the client around, it is missing writes: whatever is a client or a slave anyway the connection should terminated ASAP. Moreover what the function does exactly with its return value, and in which case the write handler is installed on the socket, was not clear, so the functions comment are improved to make the goals of the function more obvious. Also related to #2485.
-
由 Oran Agra 提交于
master was closing the connection if the RDB transfer took long time. and also sent PINGs to the slave before it got the initial ACK, in which case the slave wouldn't be able to find the EOF marker.
-
- 24 3月, 2015 1 次提交
-
-
由 antirez 提交于
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.
-
- 04 2月, 2015 1 次提交
-
-
由 antirez 提交于
-
- 12 12月, 2014 1 次提交
-
-
由 antirez 提交于
A few code style changes + consistent format: not nice for humans but better for parsers.
-
- 11 12月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
Instead of manually checking for strchr(n,':') everywhere, we can use our new centralized IP formatting functions.
-
- 03 12月, 2014 1 次提交
-
-
由 antirez 提交于
Track bandwidth used by clients and replication (but diskless replication is not tracked since the actual transfer happens in the child process). This includes a refactoring that makes tracking new instantaneous metrics simpler.
-
- 12 11月, 2014 1 次提交
-
-
由 antirez 提交于
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.
-
- 11 11月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 30 10月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
Same as the original bind fixes (we just missed these the first time around). This helps Redis not automatically send connections from the first IP on an interface if we are bound to a specific IP address (e.g. with multiple IP aliases on one interface, you want to send from _your_ IP, not from the first IP on the interface).
-
- 29 10月, 2014 1 次提交
-
-
由 antirez 提交于
This caused BGSAVE to be triggered a second time without any need when we switch from socket to disk target via the command CONFIG SET repl-diskless-sync no and there is already a slave waiting for the BGSAVE to start. Also comments clarified about what is happening.
-
- 27 10月, 2014 4 次提交
- 24 10月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 17 10月, 2014 6 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
While the socket is set in blocking mode, we still can get short writes writing to a socket.
-
由 antirez 提交于
This is useful for normal replication in order to refresh the slave when we are persisting on disk, but for diskless replication the child is already receiving data while in WAIT_BGSAVE_END state.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
- 16 10月, 2014 5 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
If we turn from diskless to disk-based replication via CONFIG SET, we need a way to start a BGSAVE if there are slaves alerady waiting for a BGSAVE to start. Normally with disk-based replication we do it as soon as the previous child exits, but when there is a configuration change via CONFIG SET, we may have slaves in WAIT_BGSAVE_START state without an RDB background process currently active.
-
由 antirez 提交于
-
由 antirez 提交于
-
- 15 10月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 14 10月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 10 10月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 29 9月, 2014 2 次提交
-
-
由 Aaron Rutkovsky 提交于
Closes #1513
-
由 Jan-Erik Rediger 提交于
Closes #1537
-
- 27 6月, 2014 1 次提交
-
-
由 antirez 提交于
-