- 09 Apr, 2020 1 commit
-
-
antirez authored
Reloading of the RDB generated by DEBUG POPULATE 5000000 SAVE is now 25% faster. This commit also prepares the ability to have more flexibility when loading stuff from the RDB, since we no longer use dbAdd() but can control exactly how things are added in the database.
-
- 07 Apr, 2020 1 commit
-
-
antirez authored
Related to #5145. Design note: clients may change type when they turn into replicas or are moved into the Pub/Sub category and so forth. Moreover the recomputation of the bytes used is problematic for obvious reasons: it changes continuously, so as a conservative way to avoid accumulating errors, each client remembers the contribution it gave to the sum, and removes it when it is freed or before updating it with the new memory usage.
-
- 01 Apr, 2020 1 commit
-
-
antirez authored
-
- 31 Mar, 2020 2 commits
-
-
Guy Benoish authored
Makse sure call() doesn't wrap replicated commands with a redundant MULTI/EXEC Other, unrelated changes: 1. Formatting compiler warning in INFO CLIENTS 2. Use CLIENT_ID_AOF instead of UINT64_MAX
-
antirez authored
37a10cef introduced automatic wrapping of MULTI/EXEC for the alsoPropagate API. However this collides with the built-in mechanism already present in module.c. To avoid complex changes near Redis 6 GA this commit introduces the ability to exclude call() MUTLI/EXEC wrapping for also propagate in order to continue to use the old code paths in module.c.
-
- 27 Mar, 2020 6 commits
-
-
antirez authored
-
antirez authored
Now that this mechanism is the sole one used for blocked clients timeouts, it is more wise to cleanup the table when the client unblocks for any reason. We use a flag: CLIENT_IN_TO_TABLE, in order to avoid a radix tree lookup when the client was already removed from the table because we processed it by scanning the radix tree.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 25 Mar, 2020 1 commit
-
-
antirez authored
A very commonly signaled operational problem with Redis master-replicas sets is that, once the master becomes unavailable for some reason, especially because of network problems, many times it wont be able to perform a partial resynchronization with the new master, once it rejoins the partition, for the following reason: 1. The master becomes isolated, however it keeps sending PINGs to the replicas. Such PINGs will never be received since the link connection is actually already severed. 2. On the other side, one of the replicas will turn into the new master, setting its secondary replication ID offset to the one of the last command received from the old master: this offset will not include the PINGs sent by the master once the link was already disconnected. 3. When the master rejoins the partion and is turned into a replica, its offset will be too advanced because of the PINGs, so a PSYNC will fail, and a full synchronization will be required. Related to issue #7002 and other discussion we had in the past around this problem.
-
- 18 Mar, 2020 1 commit
-
-
WuYunlong authored
Before this commit, when upgrading a replica, expired keys will not be loaded, thus causing replica having less keys in db. To this point, master and replica's keys is logically consistent. However, before the keys in master and replica are physically consistent, that is, they have the same dbsize, if master got a problem and the replica got promoted and becomes new master of that partition, and master updates a key which does not exist on master, but physically exists on the old master(new replica), the old master would refuse to update the key, thus causing master and replica data inconsistent. How could this happen? That's all because of the wrong judgement of roles while starting up the server. We can not use server.masterhost to judge if the server is master or replica, since it fails in cluster mode. When we start the server, we load rdb and do want to load expired keys, and do not want to have the ability to active expire keys, if it is a replica.
-
- 16 Mar, 2020 1 commit
-
-
antirez authored
Note that this as a side effect fixes Sentinel "requirepass" mode.
-
- 04 Mar, 2020 2 commits
-
-
antirez authored
-
bodong.ybd authored
-
- 03 Mar, 2020 1 commit
-
-
antirez authored
-
- 24 Feb, 2020 1 commit
-
-
antirez authored
-
- 19 Feb, 2020 1 commit
-
-
antirez authored
-
- 11 Feb, 2020 2 commits
- 10 Feb, 2020 1 commit
-
-
antirez authored
-
- 07 Feb, 2020 2 commits
- 06 Feb, 2020 1 commit
-
-
Guy Benoish authored
1. Call emptyDb even in case of diskless-load: We want modules to get the same FLUSHDB event as disk-based replication. 2. Do not fire any module events when flushing the backups array. 3. Delete redundant call to signalFlushedDb (Called from emptyDb).
-
- 05 Feb, 2020 1 commit
-
-
Oran Agra authored
-
- 04 Feb, 2020 2 commits
- 03 Feb, 2020 1 commit
-
-
Guy Benoish authored
Because "keymiss" is "special" compared to the rest of the notifications (Trying not to break existing apps using the 'A' format for notifications) Also updated redis.conf and module.c docs
-
- 02 Feb, 2020 1 commit
-
-
Leo Murillo authored
-
- 28 Jan, 2020 1 commit
-
-
antirez authored
-
- 27 Jan, 2020 1 commit
-
-
antirez authored
-
- 20 Jan, 2020 1 commit
-
-
srzhao authored
Checking OOM by `getMaxMemoryState` inside script might get different result with `freeMemoryIfNeededAndSafe` at script start, because lua stack and arguments also consume memory. This leads to memory `borderline` when memory grows near server.maxmemory: - `freeMemoryIfNeededAndSafe` at script start detects no OOM, no memory freed - `getMaxMemoryState` inside script detects OOM, script aborted We solve this 'borderline' issue by saving OOM state at script start to get stable lua OOM state. related to issue #6565 and #5250.
-
- 23 Dec, 2019 1 commit
-
-
Oran Agra authored
-
- 18 Dec, 2019 3 commits
-
-
antirez authored
-
zhaozhao.zz authored
Delete keys in async way when executing DEL command, if lazyfree-lazy-user-del is yes.
-
zhaozhao.zz authored
-
- 17 Dec, 2019 3 commits
-
-
Madelyn Olson authored
-
Madelyn Olson authored
-
Madelyn Olson authored
-