I'm starting to use redis for my applications as a cache backend and "shared memory" store.
I've asked the servers maintenance team to install Redis on our CentOS 6.5 production environments. From EPEL, the version is 2.4.10, which we hope will upgrade in the future. Also, on our internal registry, we have a 3.0.7 available. The maintenance team would prefer the EPEL version.
I'm not quite sure of the differences between the versions. I haven't found a document listing major changes from 2.x to 3.0. Are there major features/ performance improvements/bugfixes in 3.0 that I MUST have?
My first guess is that 2.4.10 would be sufficient enough for my needs.
The most significant change from 2.x to 3.0 is that Redis 3.0 introduces Redis Cluster which is a distributed implementation of Redis.
You can also get change list (bug fix, new features and so on) of other versions from 00-RELEASENOTES file of each version: github link:
Related
Currently I have a single DC cluster with 3 nodes running 4.1.7 version of Scylla. This setup has been running for a long time and I don't want to make changes to this DC, if possible. Now I have a requirement to add another DC cluster with 3 nodes. Can I set up this new DC with the latest stable version of Scylla? Will the two DCs be able to communicate with each other without any issues? Or am I forced to upgrade the existing DC to the latest version?
Scylla supports rolling upgrades, which means you can indeed upgrade just some of the nodes in the cluster while the rest are still running the older version. The cluster should be able to fully work in this state - including the communication between old and new nodes. Not all upgrade paths are equally supported or have been equally tested, obviously, but most "interesting" upgrade paths (a newer release in the same major version, the next major version) are indeed supported.
That being said, while staying at a half-upgraded state for a long time is possible, it is not recommended. It also means that whatever new features or improved algorithms were introduced in the new version, the new nodes will need to avoid them until the full cluster is upgraded.
OSS 4.1.7 is a pretty old OSS release from Oct 2020. The assumption that you can add another DC running OSS 5.0 (latest OSS release from 10 days ago) to the existing cluster, is a bit of a risky one.
The supported upgrade path (QA tested) is from OSS 4.6 to 5.0. You can read more about the upgrade path here: https://docs.scylladb.com/upgrade/upgrade-opensource/
The tested upgrade route is via minor versions 4.1 --> 4.2 --> 4.3 --> 4.4 --> 4.5 --> 4.6 --> 5.0, jumping multiple minor version should work, but we can't say that it was tested.
We have run redis 2.6 (and now 2.8) for some time with good success.
Looking at 3.2, I have not spotted a migration document.
Can you suggest where to find a doc describing new/dropped/changed commands and other migration topics. I could not put a finger on it.
The most significant change between 3.x and 2.x is that since Redis 3.x, it supports cluster mode.
You can get other change lists from Redis 3.2 release note and Redis 3.0 release note.
Ubuntu shipped CMake 2.8 when version 3.3 was the current version. Other Linux distributions do it similar. Is there a reason like backwards-compatibility issues with CMake 3.0?
I found plenty of people willing to explain how to upgrade CMake to the latest version, but couldn't figure out why it wasn't done by default. I'd like to understand the mentality of keeping it back before I decide to override the decision and upgrade it myself.
Depends on the Linux distribution you're using. A distribution's maintainers cannot ship future versions and often they don't upgrade version with updates as it might break existing applications.
CMake 3.0 has some minor incompatibilities. More important, it got new features and some bugs were fixed. If software relys on these, you'll need a new version.
Btw: With CMake 2.8 the third part of the version number is relevant. They stayed a long time with 2.8.x and added features with increasing x. Then they could not update to 2.9 or 2.10, thus they decided to change the version scheme and increase y in 3.y.
Your question applies to a wider range of software. It is a general question, whether a distribution should stick to defined versions of software they provide or whether they should update it and potentially break the costumers' setup. Enterprise distributions like RHEL or SLE are very conservative and fix bugs for at least a decade. Ubuntu updates it distribution every six month but you can stick to the LTS for three years. Fedora even updates some key components like the kernel after the release. Arch Linux and openSuse Tumbleweed are rolling releases, the update their software almost on a daily bases, when the upstream updates publish new versions.
I need to do integration testing for a spring cloud application running with spring data on redis.
Tests work locally with the regular redis server instance and I need to run this on a Jenkins CI server that is controlled by the corporate CI engineering group.
Obviously I can attach to a redo server there so I used an embedded redis server (from here: https://github.com/kstyrc/embedded-redis).
Running tests locally with this redis server works well since there is a test profile to inject the embedded server in place of the production one.
Now the problem is that when we run this in the Jenkins environment this is the error we see.
/tmp/1430170830037-0/redis-server-2.8.19: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/1430170830037-0/redis-server-2.8.19)
So this version of redis has specific dependency on a specific version of glibc. I tried a couple of other libraries but they all depend on the same underlying version of the embedded redis server.
Is there a spring data mock framework that can be used to get around this sort of issue?
This might come a little late for you, but there is indeed a Spring Data Mock framework that you can use, which let's you mock repositories (regardless of the specific backend solution) without a real database connection.
Here is a link: https://github.com/mmnaseri/spring-data-mock
You don't have a high enough version of libc6, that is causing the error.
From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”? – Super User:
That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).
So, you just need to upgrade your libc6 package. All versions of Ubuntu have at least version 2.15 because it's a faily important package (reference).
To upgrade it, use these commands in a terminal:
sudo apt-get update
sudo apt-get install libc6
p.s. This is answer from askubuntu.com by minerz029
I use Centos 6.5, I've installed apache 2.2 on my server by yum, I want to upgrade my apache to 2.4, but yum not support that, so I download apache 2.4.7 and install it to opt/apache/httpd-2.4.7 follow the tutorial here: Apache 2.4.x Manual install on RHEL 6.4 - No apache modules will load on start . I want to change environment variables to new apache version to write apache 2.4 modules (change include folder for header file, change "modules" folder when build with apxs,...). I think I must install another httpd-devel for apache 2.4.7, because I still not install httpd-devel-2.4.7, but I don't know how to install and use it instead of httpd-devel-2.2 by yum. I can not describe my problems clearly in English, so I hope you can understand it. I'm a newbie and I really need your help. Thank you!
CentOS is image of RHEL, which stands for Red Hat Enterprise Linux. RHEL is designed to be an "Enterprise class" operating system, in which you rely on software packages that are delivered from controlled repositories where they are made available only after being thoroughly tested for Enterprise level use.
From that point of view, its generally not a good idea to install packages from source code, or using third party RPMs, because once you do, your OS is no longer "Enterprise" class.
If you're trying to upgrade for security reasons, you shouldn't. Critical security updates are always backported in previous RPM releases, so you only have to update your current package from the same yum repo from where you got it first. The binary will still say it is Apache 2.2, but it will have the latest security updates.
If you need an actual feature of 2.4, the smart move is to upgrade your CentOS. It may seem like the harder option initially, but it never is in the long run.
In my experience these reports can be fairly basic/binary:
Are you running the latest version of the software? If no flag as security risk.
However this fails to take into account package managers which back port fixes to older versions and so often have addressed potential security issues.
By moving away from the packaged version you are making security updates more difficult (as can't do a simple "yum update" to address them anymore).
Apache 2.2 is still maintained for security and bug fixes - though how long for remains to be seen and it is falling further and further behind in features.
So often you just need to explain (and prove!) you have a regular patching process and so the "version of Apache" you are reporting is not really accurate in terms of security patching.
See here for more details: https://serverfault.com/questions/731657/pci-compliance-apache-versions/
Saying all that we moved to Apache 2.4 on centos a while back for some extra features we wanted and just upgrade it to the latest version as part of regular patching cycle and are not finding it too inconvenient. Yes it's not quite as simple as "yum update" but it's a decision we've made because of some features we required. Not a decision to be taken lightly as Garreth states but it had the added side effect of this not getting highlighted anymore in these sorts of security scans :-)
We made this decision despite upgrading to a newer version of Red Hat as that was still on an older version of Apache (2.4.7 if memory serves me correctly) which still missed a few features we required. Sometimes it's frustrating how far behind some of these "enterprise" versions are, but that's the downside when there are plenty of upsides to using them too (stability, security... etc.).