1. 27 Mar, 2020 4 commits
  2. 25 Mar, 2020 2 commits
    • antirez's avatar
      PSYNC2: meaningful offset implemented. · 57fa355e
      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.
      57fa355e
    • antirez's avatar
      Explain why we allow transactions in -BUSY state. · f15042db
      antirez authored
      Related to #7022.
      f15042db
  3. 23 Mar, 2020 2 commits
    • Oran Agra's avatar
      MULTI/EXEC during LUA script timeout are messed up · ec007559
      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
      ec007559
    • antirez's avatar
      918086e2
  4. 20 Mar, 2020 1 commit
  5. 18 Mar, 2020 1 commit
    • WuYunlong's avatar
      Fix master replica inconsistency for upgrading scenario. · f6029fb9
      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.
      f6029fb9
  6. 16 Mar, 2020 1 commit
  7. 04 Mar, 2020 1 commit
  8. 03 Mar, 2020 1 commit
  9. 12 Feb, 2020 1 commit
  10. 10 Feb, 2020 1 commit
  11. 07 Feb, 2020 3 commits
  12. 06 Feb, 2020 3 commits
  13. 05 Feb, 2020 1 commit
  14. 04 Feb, 2020 1 commit
  15. 28 Jan, 2020 1 commit
  16. 27 Jan, 2020 1 commit
  17. 15 Jan, 2020 1 commit
  18. 10 Jan, 2020 1 commit
  19. 17 Dec, 2019 1 commit
  20. 16 Dec, 2019 1 commit
  21. 12 Dec, 2019 1 commit
  22. 11 Dec, 2019 1 commit
  23. 28 Nov, 2019 1 commit
    • Oran Agra's avatar
      Converting more configs to use generic infra, and moving defaults to config.c · 18e72c5c
      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
      18e72c5c
  24. 26 Nov, 2019 1 commit
    • Oran Agra's avatar
      Additional config.c refactory and bugfixes · e0cc3c99
      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
      e0cc3c99
  25. 22 Nov, 2019 2 commits
  26. 20 Nov, 2019 1 commit
    • Maxim Ivanov's avatar
      Prune leftover TODO comment · c7b68d10
      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.
      c7b68d10
  27. 19 Nov, 2019 3 commits
    • Johannes Truschnigg's avatar
      Auto-detect and link libsystemd at compile-time · 129d14e1
      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.
      129d14e1
    • Johannes Truschnigg's avatar
      Use libsystemd's sd_notify for communicating redis status to systemd · 641c64ad
      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.
      641c64ad
    • antirez's avatar
      ce03d683
  28. 18 Nov, 2019 1 commit