- 27 Mar, 2020 4 commits
- 25 Mar, 2020 2 commits
-
-
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.
-
antirez authored
Related to #7022.
-
- 23 Mar, 2020 2 commits
-
-
Oran Agra authored
Redis refusing to run MULTI or EXEC during script timeout may cause partial transactions to run. 1) if the client sends MULTI+commands+EXEC in pipeline without waiting for response, but these arrive to the shards partially while there's a busy script, and partially after it eventually finishes: we'll end up running only part of the transaction (since multi was ignored, and exec would fail). 2) similar to the above if EXEC arrives during busy script, it'll be ignored and the client state remains in a transaction. the 3rd test which i added for a case where MULTI and EXEC are ok, and only the body arrives during busy script was already handled correctly since processCommand calls flagTransaction
-
antirez authored
-
- 20 Mar, 2020 1 commit
-
-
antirez authored
This fixes issue #7011.
-
- 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
-
-
zhaozhao.zz authored
-
- 04 Mar, 2020 1 commit
-
-
bodong.ybd authored
-
- 03 Mar, 2020 1 commit
-
-
antirez authored
-
- 12 Feb, 2020 1 commit
-
-
antirez authored
-
- 10 Feb, 2020 1 commit
-
-
antirez authored
-
- 07 Feb, 2020 3 commits
- 06 Feb, 2020 3 commits
-
-
Oran Agra authored
-
Guy Benoish authored
1. server.repl_no_slaves_since can be set when a MONITOR client disconnects 2. c->repl_ack_time can be set by a newline from a MONITOR client 3. Improved comments
-
Oran Agra authored
SELECT, and HELLO are commands that may be executed by the client as soon as it connects, there's no reason to block them, preventing the client from doing the rest of his sequence (which might just be INFO or CONFIG, etc). MONITOR, DEBUG, SLOWLOG, TIME, LASTSAVE are all non-data accessing commands, which there's no reason to block.
-
- 05 Feb, 2020 1 commit
-
-
Oran Agra authored
-
- 04 Feb, 2020 1 commit
-
-
antirez authored
-
- 28 Jan, 2020 1 commit
-
-
antirez authored
-
- 27 Jan, 2020 1 commit
-
-
antirez authored
-
- 15 Jan, 2020 1 commit
-
-
antirez authored
-
- 10 Jan, 2020 1 commit
-
-
Vasyl Melnychuk authored
So error message `ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context` will become `ERR 'get' command submitted, but only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context`
-
- 17 Dec, 2019 1 commit
-
-
Madelyn Olson authored
-
- 16 Dec, 2019 1 commit
-
-
antirez authored
-
- 12 Dec, 2019 1 commit
-
-
Oran Agra authored
since the refactory of config.c, it was initialized from config_hz in initServer but apparently that's too late since the config file loading creates objects which call LRU_CLOCK
-
- 11 Dec, 2019 1 commit
-
-
antirez authored
This message is there for ten years, but is hardly useful. Moreover it is likely that it will fill an entire disk if log ratation is not configured, for no good reasons.
-
- 28 Nov, 2019 1 commit
-
-
Oran Agra authored
Changes in behavior: - Change server.stream_node_max_entries from int64_t to long long, so that it can be used by the generic infra - standard error reply instead of "repl-backlog-size must be 1 or greater" and such - tls-port and a few TLS booleans were readable (config get) even when USE_OPENSSL was off (now they aren't) - syslog-enabled, syslog-ident, cluster-enabled, appendfilename, and supervised didn't have a get (now they do) - pidfile was initialized to NULL in InitServerConfig but had CONFIG_DEFAULT_PID_FILE in rewriteConfig (so the real default was "", but rewrite would cause it to be set), fixed the rewrite. - TLS config in server.h was uninitialized (if no tls config args were provided) Adding test for sanity and coverage
-
- 26 Nov, 2019 1 commit
-
-
Oran Agra authored
- add capability for each config to have a callback to check if value is valid and return error string will enable converting many of the remaining custom configs into generic ones (reducing the x4 repetition for set,get,config,rewrite) - add capability for each config to to run some update code after config is changed (only for CONFIG SET) will also enable converting many of the remaining custom configs into generic ones - add capability to move default values from server.h and server.c to config.c will reduce many excess lines in server.h and server.c (plus, no need to rebuild the entire code base when a default change 8-)) other behavior changes: - fix bug in bool config get (always returning 'yes') - fix a bug in modifying jemalloc-bg-thread at runtime (didn't call set_jemalloc_bg_thread, due to bad merge conflict resolution (my fault)) - side effect when a failed attempt to enable activedefrag at runtime, we now respond with -ERR and not with -DISABLED
-
- 22 Nov, 2019 2 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
Random command like SPOP with count is replicated as some SREM operations, and store them in also_propagate array to propagate after the call, but this would break atomicity. To keep the command's atomicity, wrap also_propagate array with MULTI/EXEC.
-
- 20 Nov, 2019 1 commit
-
-
Maxim Ivanov authored
Is it sufficient... ? -- Yes it is. In standalone mode, we say READY=1 at the comment point; however in replicated mode, we delay sending READY=1 until the replication sync completes.
-
- 19 Nov, 2019 3 commits
-
-
Johannes Truschnigg authored
This adds Makefile/build-system support for USE_SYSTEMD=(yes|no|*). This variable's value determines whether or not libsystemd will be linked at build-time. If USE_SYSTEMD is set to "yes", make will use PKG_CONFIG to check for libsystemd's presence, and fail the build early if it isn't installed/detected properly. If USE_SYSTEM is set to "no", libsystemd will *not* be linked, even if support for it is available on the system redis is being built on. For any other value that USE_SYSTEM might assume (e.g. "auto"), PKG_CONFIG will try to determine libsystemd's presence, and set up the build process to link against it, if it was indicated as being installed/available. This approach has a number of repercussions of its own, most importantly the following: If you build redis on a system that actually has systemd support, but no libsystemd-dev package(s) installed, you'll end up *without* support for systemd notification/status reporting support in redis-server. This changes established runtime behaviour. I'm not sure if the build system and/or the server binary should indicate this. I'm also wondering if not actually having systemd-notify-support, but requesting it via the server's config, should result in a fatal error now.
-
Johannes Truschnigg authored
Instead of replicating a subset of libsystemd's sd_notify(3) internally, use the dynamic library provided by systemd to communicate with the service manager. When systemd supervision was auto-detected or configured, communicate the actual server status (i.e. "Loading dataset", "Waiting for master<->replica sync") to systemd, instead of declaring readiness right after initializing the server process.
-
antirez authored
-
- 18 Nov, 2019 1 commit
-
-
antirez authored
-