- 28 May, 2020 5 commits
-
-
Salvatore Sanfilippo authored
tests: each test client work on a distinct port range
-
Salvatore Sanfilippo authored
32bit CI needs to build modules correctly
-
Salvatore Sanfilippo authored
Revive and adjust meaningful offset tests
-
Oran Agra authored
these tests create several edge cases that are otherwise uncovered (at least not consistently) by the test suite, so although they're no longer testing what they were meant to test, it's still a good idea to keep them in hope that they'll expose some issue in the future.
-
Oran Agra authored
-
- 27 May, 2020 7 commits
-
-
Oran Agra authored
-
antirez authored
-
Oran Agra authored
i.e. don't start the search from scratch hitting the used ones again. this will also reduce the likelihood of collisions (if there are any left) by increasing the time until we re-use a port we did use in the past.
-
antirez authored
-
antirez authored
-
antirez authored
After a closer look, the Redis core devleopers all believe that this was too fragile, caused many bugs that we didn't expect and that were very hard to track. Better to find an alternative solution that is simpler.
-
antirez authored
We want to react a bit more aggressively if we sense that the master is sending us some corrupted stream. By setting the protocol error we both ensure that the replica will disconnect, and avoid caching the master so that a full SYNC will be required. This is protective against replication bugs.
-
- 26 May, 2020 6 commits
-
-
antirez authored
-
antirez authored
-
Salvatore Sanfilippo authored
avoid using sendfile if tls-replication is enabled
-
Oran Agra authored
-
Oran Agra authored
this obviously broke the tests, but went unnoticed so far since tls wasn't often tested.
-
Oran Agra authored
apparently when running tests in parallel (the default of --clients 16), there's a chance for two tests to use the same port. specifically, one test might shutdown a master and still have the replica up, and then another test will re-use the port number of master for another master, and then that replica will connect to the master of the other test. this can cause a master to count too many full syncs and fail a test if we run the tests with --single integration/psync2 --loop --stop see Probmem 2 in #7314
-
- 25 May, 2020 4 commits
-
-
antirez authored
-
antirez authored
-
Salvatore Sanfilippo authored
PSYNC2: second_replid_offset should be real meaningful offset
-
zhaozhao.zz authored
After adjustMeaningfulReplOffset(), all the other related variable should be updated, including server.second_replid_offset. Or the old version redis like 5.0 may receive wrong data from replication stream, cause redis 5.0 can sync with redis 6.0, but doesn't know meaningful offset.
-
- 24 May, 2020 2 commits
-
-
Salvatore Sanfilippo authored
add CI for 32bit build
-
Oran Agra authored
-
- 22 May, 2020 7 commits
-
-
antirez authored
Otherwise we run into that: Backtrace: src/redis-server 127.0.0.1:21322(logStackTrace+0x45)[0x479035] src/redis-server 127.0.0.1:21322(sigsegvHandler+0xb9)[0x4797f9] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fd373c5e390] src/redis-server 127.0.0.1:21322(_serverAssert+0x6a)[0x47660a] src/redis-server 127.0.0.1:21322(freeReplicationBacklog+0x42)[0x451282] src/redis-server 127.0.0.1:21322[0x4552d4] src/redis-server 127.0.0.1:21322[0x4c5593] src/redis-server 127.0.0.1:21322(aeProcessEvents+0x2e6)[0x42e786] src/redis-server 127.0.0.1:21322(aeMain+0x1d)[0x42eb0d] src/redis-server 127.0.0.1:21322(main+0x4c5)[0x42b145] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fd3738a3830] src/redis-server 127.0.0.1:21322(_start+0x29)[0x42b409] Since we disconnect all the replicas and free the replication backlog in certain replication paths, and the code that will free the replication backlog expects that no replica is connected. However we still need to free the replicas asynchronously in certain cases, as documented in the top comment of disconnectSlaves().
-
antirez authored
-
antirez authored
Citing from the issue: btw I suggest we change this fix to something else: * We revert the fix. * We add a call that disconnects chained replicas in the place where we trim the replica (that is a master i this case) offset. This way we can avoid disconnections when there is no trimming of the backlog. Note that we now want to disconnect replicas asynchronously in disconnectSlaves(), because it's in general safer now that we can call it from freeClient(). Otherwise for instance the command: CLIENT KILL TYPE master May crash: clientCommand() starts running the linked of of clients, looking for clients to kill. However it finds the master, kills it calling freeClient(), but this in turn calls replicationCacheMaster() that may also call disconnectSlaves() now. So the linked list iterator of the clientCommand() will no longer be valid.
-
Salvatore Sanfilippo authored
Implements sendfile for redis.
-
Salvatore Sanfilippo authored
EAGAIN not handled for TLS during diskless load
-
Salvatore Sanfilippo authored
Disconnect chained replicas when the replica performs PSYNC with the master always to avoid replication offset mismatch between master and chained replicas
-
Qu Chen authored
Disconnect chained replicas when the replica performs PSYNC with the master always to avoid replication offset mismatch between master and chained replicas.
-
- 21 May, 2020 9 commits
-
-
Madelyn Olson authored
-
Salvatore Sanfilippo authored
fix server crash for STRALGO command
-
hwware authored
-
hwware authored
-
Salvatore Sanfilippo authored
Replace 'addDeferredMultiBulkLength' with 'addReplyDeferredLen' in comment
-
Salvatore Sanfilippo authored
TLS: Improve tls-protocols clarity in redis.conf.
-
Salvatore Sanfilippo authored
Fix reply bytes calculation error on 32bit platform
-
ShooterIT authored
-
ShooterIT authored
Fix #7275.
-