- 31 5月, 2020 3 次提交
-
-
由 Salvatore Sanfilippo 提交于
fix pingoff test race
-
由 Oran Agra 提交于
-
由 Salvatore Sanfilippo 提交于
Fix TLS certificate loading for chained certificates.
-
- 29 5月, 2020 3 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Now it is also possible for ACL SETUSER to accept empty strings as valid operations (doing nothing), so for instance ACL SETUSER myuser "" Will have just the effect of creating a user in the default state. This should fix #7329.
-
由 Salvatore Sanfilippo 提交于
fix clusters mixing accidentally by gossip
-
- 28 5月, 2020 9 次提交
-
-
由 antirez 提交于
This will likely avoid false positives due to trailing pings.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 Salvatore Sanfilippo 提交于
tests: each test client work on a distinct port range
-
由 Salvatore Sanfilippo 提交于
32bit CI needs to build modules correctly
-
由 Salvatore Sanfilippo 提交于
Revive and adjust meaningful offset tests
-
由 Oran Agra 提交于
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 提交于
-
- 27 5月, 2020 11 次提交
-
-
由 Oran Agra 提交于
-
由 antirez 提交于
-
由 Oran Agra 提交于
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.
-
由 Kevin Fwu 提交于
This impacts client verification for chained certificates (such as Lets Encrypt certificates). Client Verify requires the full chain in order to properly verify the certificate.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
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 提交于
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.
-
由 Liu Zhen 提交于
`clusterStartHandshake` will start hand handshake and eventually send CLUSTER MEET message, which is strictly prohibited in the REDIS CLUSTER SPEC. Only system administrator can initiate CLUSTER MEET message. Futher, according to the SPEC, rather than IP/PORT pairs, only nodeid can be trusted.
-
由 antirez 提交于
-
由 antirez 提交于
-
- 26 5月, 2020 5 次提交
-
-
由 Salvatore Sanfilippo 提交于
avoid using sendfile if tls-replication is enabled
-
由 Oran Agra 提交于
-
由 Oran Agra 提交于
this obviously broke the tests, but went unnoticed so far since tls wasn't often tested.
-
由 Oran Agra 提交于
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
-
由 antirez 提交于
-
- 25 5月, 2020 3 次提交
-
-
由 antirez 提交于
-
由 Salvatore Sanfilippo 提交于
PSYNC2: second_replid_offset should be real meaningful offset
-
由 zhaozhao.zz 提交于
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 5月, 2020 2 次提交
-
-
由 Salvatore Sanfilippo 提交于
add CI for 32bit build
-
由 Oran Agra 提交于
-
- 23 5月, 2020 1 次提交
-
-
由 antirez 提交于
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().
-
- 22 5月, 2020 3 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
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 提交于
Implements sendfile for redis.
-