| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|\ |
|
| |\
| | |
| | | |
avoid using sendfile if tls-replication is enabled
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
this obviously broke the tests, but went unnoticed so far since tls
wasn't often tested.
|
|/ / |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| | |
soloestoy/second-replid-offset-should-be-meaningful-offset
PSYNC2: second_replid_offset should be real meaningful offset
|
|/
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
add CI for 32bit build
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
|\ |
|
| |\
| | |
| | | |
Implements sendfile for redis.
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
EAGAIN not handled for TLS during diskless load
|
| | | |
|
|\ \ \
| | | |
| | | | |
Disconnect chained replicas when the replica performs PSYNC with the master always to avoid replication offset mismatch between master and chained replicas
|
|/ / /
| | |
| | |
| | | |
always to avoid replication offset mismatch between master and chained replicas.
|
|\ \ \
| |/ /
|/| | |
fix server crash for STRALGO command
|
| | | |
|
|/ / |
|
|\ \
| | |
| | | |
Replace 'addDeferredMultiBulkLength' with 'addReplyDeferredLen' in comment
|
| | | |
|
|\ \ \
| | | |
| | | | |
TLS: Improve tls-protocols clarity in redis.conf.
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Fix reply bytes calculation error on 32bit platform
|
| | |/ /
| |/| |
| | | |
| | | | |
Fix #7275.
|
|\ \ \ \
| |/ / /
|/| | | |
Tracking: flag CLIENT_TRACKING_BROKEN_REDIR when redir broken
|
|/ / / |
|
|\ \ \
| |/ /
|/| | |
fix a rare active defrag edge case bug leading to stagnation
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There's a rare case which leads to stagnation in the defragger, causing
it to keep scanning the keyspace and do nothing (not moving any
allocation), this happens when all the allocator slabs of a certain bin
have the same % utilization, but the slab from which new allocations are
made have a lower utilization.
this commit fixes it by removing the current slab from the overall
average utilization of the bin, and also eliminate any precision loss in
the utilization calculation and move the decision about the defrag to
reside inside jemalloc.
and also add a test that consistently reproduce this issue.
|
|/ /
| |
| |
| |
| | |
also support:
debug mallctl-str thread.tcache.flush VOID
|
|\ \
| | |
| | | |
fix clear USER_FLAG_ALLCOMMANDS flag in acl
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
in ACLSetUserCommandBit, when the command bit overflows, no operation
is performed, so no need clear the USER_FLAG_ALLCOMMANDS flag.
in ACLSetUser, when adding subcommand, we don't need to call
ACLGetCommandID ahead since subcommand may be empty.
|
|\ \ \
| | | |
| | | | |
Redis Benchmark: make test data better
|
| | | |
| | | |
| | | |
| | | | |
The function of generating random data is designed by antirez. See #7196.
|
|\ \ \ \
| | | | |
| | | | | |
Redis-Benchmark: avoid potentical memmory leaking
|
| | |/ /
| |/| | |
|
|\ \ \ \
| |/ / /
|/| | | |
Tcl client support hash tagged keys.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
tag.
|
|\ \ \ \
| | | | |
| | | | | |
Use dictSize to get the size of dict in dict.c
|
| | | | | |
|