I’ve noticed that the generic linux downloads for both XtraBackup 2.4 and 8 only say they are compiled against glibc 2.17. Will this be an issue if we upgrade to RHEL9 which only has glibc 2.34? I know PXC has two different tarballs, one for glibc 2.17 and one for 2.34.
Hi @brucehvn
Your question is similar to the ones we have heard in the recent past.
Short answer is that we build the generic tarballs in such a way that they fit the most operating systems and for that reason we use the oldest suitable glibc, which happens to be glibc2.17.
The possible workarounds for this are as follows:
- Use the packages created specifically for operating systems. This way the glibc version used for compilation are likley to be more modern versions.
- Compile the software on your end. I understand that this might be tricky to pull off.
- Have Percona release tarballs which are not generic, but created specifically for operating systems and versions. While we are not doing it now, we are considering creating such downloads. I do not have ETA at this point in time.
May I ask why you decided to use the generic tarballs instead of rpm packages? If you prefer, I’ll be happy to jump on a quick call to discuss this more conveniently.
For a reference, here are two other threads with similar requests:
Warm regards,
Bartek
Group PM at Percona
1 Like
Hello Bartek,
Thanks for the response. We have our own in-house server monitoring/metrics software. This software uses several third-party components including PXC 5.7 (we just switched from 5.6 as we are moving to RHEL9) and XtraBackup. We don’t install this software directly into the system. We collect all the third-party components into its own folder tree and package that up as a single RPM. When installed to the system, it maintains its separate folder structure and our metrics software sets the paths properly and runs the third-party components so as not to be dependent on whatever might be installed on the system. Because this is critical software for us, we maintain tight control over the versions of these third-party components and we rarely upgrade unless we need to due to security concerns, etc. Most of the third-party components we also build ourselves from source, but for PXC and XtraBackup, we use your generic tarballs. We’re moving towards RHEL9 from our current OEL7 OS. Hence, that is why we are only now migrating from PXC 5.6 to 5.7 since you do provide tarballs that can run with GLIBC 2.13 for EL7 and 2.34 for RHEL9. We will eventually move to PXC 8, but for now, they want to minimize the pain of migrating the db for the hundreds of clusters we have, so 5.7 was the compromise even though it is past EOL. About a year ago, I embarked on a quest to compile PXC for arm64 and it was a failure and I was never able to get it to compile all the way through. There were many dependencies that weren’t outlined in the documentation for building from source and it took me many days just to get through the configuration stage. It just didn’t seem practical for us and we had been using the 5.6 tarballs for many years with no issues. We have things working now with OEL7, PXC 5.7, and XtraBackup 2.4. We will be starting to test with RHEL9 soon, which is how my question came up. If your OS specific RPMs were totally relocatable so we could unpack and isolate them to a folder tree of our own, that might work for us as well.