On our server we are running GNU Libc 2.11 and we want to update MySQL 5.1 to 5.6.
Just to be sure that this won't fail i'm looking for information of if this can be done with the current Glibc version.
Anyone? :)
Yes.
Linux distributions use packages to install or uninstall software. These are similar things as the .msi on windows, but they contain dependency informations, too: every package contains which other packages it needs, and at least (or at most) which versions.
There are multiple package management systems (rpm and dpkg are the most common), it depends on the distro which is used by you, but they are the same from this aspect.
If you install mysql 5.6, it will either upgrade the libc as well (and so, all other programs which need a newer libc), or it won't be installable. Or it will simply work (if they are compatible).
A bigger danger for the mysql upgrades isn't the possibility of the incompatibility with the libc, but the incompatibility of the mysql databases between the mysql versions. I.e. your mysql-5.6 will perfectly work with the libc, but it will have troubles to use the databases files he got from the 5.1.
It is highly suggested to make a backup from your mysql directories (/var/lib/mysql) and configurations (/etc/mysql), and even a dump (mysqldump --all).
Related
Installing a PHP application that requires MySQL or MariaDB, I first installed MariaDB via 'apt install' from the MariaDB repos, but there were behaviours with the installation of the application that seemed to be caused by some kind of incompatibility. Calls to the DB were timing out, and although I could see it was creating the DB, it was impossible to set the application up in its setup routine.
So I used apt remove to get rid of MariaDB. I saw the application had a *.deb installer for all requirements (wish I'd seen this sooner!) and, after removing PHP and Nginx, I attempted to install it the normal way. Unfortunately, the MySQL portion of the installation failed with:
Automatic maintenance of MySQL Server daemon disabled.
Packaging maintainer scripts detected a case that it does not know how to handle and cannot continue configuring MySQL. Automatic management of your MySQL Installation has been disabled to allow other packaging tasks to complete. For more details, see /etc/mysql/FROZEN
Unfortunately, /etc/mysql/FROZEN is a symlink to a non-existent file explaining downgrading. I can't run the uninstaller of the overall package or repair the installation with sudo --fix-broken install because the installer requires a MySQL password I can't provide it.
How can I fix my borked MySQL installation? If I could just get to a place to have MySQL run properly, understanding what left-overs perhaps from the MariaDB installation that I need to delete manually before trying to repair it, that would be helpful. FYI, the version of MariaDB was 10.3, and the version of MySQL the application package was installing was 5.7.
Any suggestions appreciated.
Have inherited a very old site that needs a local dev environment created in Docker, which normally is really quick, but it appears it needs to have MySQL 3.23 since using MySQL 5.7 and importing the sqldump of the existing site has a bunch of issue regarding character sets, which are only easily resolved above MySQL v4.x. So I've been trying to find the specific apt-get install instructions for MySQL 3.23 since there is definitely no docker hub images available.
Does anyone have a source or example for installing MySQL v3.23 on Ubuntu 16.04? or maybe I should just keep working on figure out the character set issues?
Wow! The last release of MySQL 3.23 was 2003-09-11, which is 14 years ago as we type this. Oracle has done its best to remove all unsupported versions from official download sites.
You might find old copies of MySQL 3.23 binaries and source floating around on obscure sites in lesser-known corners of the internet.
I don't expect the binaries can run on modern OS versions. The runtime shared libraries are just the wrong versions. You'd have to compile MySQL 3.23 from source.
Even finding the source is hard. I found a copy of 3.23.49 here: http://live.dadanini.at/mysql/downloads_html/mysql-3.23.html
(3.23.49 was released 2002-02-14, 19 months before the last version 3.23.58, dated 2003-09-11).
I spun up a Vagrant box with Ubuntu 16.04 and installed:
sudo apt-get update
sudo apt-get install -y --reinstall build-essential libncurses5-dev
I got the MySQL source to configure... sort of. It wouldn't recognize the pthreads option, so I tried to use mit-threads instead:
./configure --prefix=/usr/local/mysql --enable-large-files --enable-shared=yes --with-mit-threads --with-innodb
But it ran into errors trying to configure mit-threads:
checking host system type... Invalid configuration `x86_64-unknown-linux': machine `x86_64-unknown' not recognized
checking target system type... Invalid configuration `x86_64-unknown-linux': machine `x86_64-unknown' not recognized
checking build system type... Invalid configuration `x86_64-unknown-linux': machine `x86_64-unknown' not recognized
configure: error: System type not recognized or not supported.
See ./config/configure.in for supported systems.
That's right, the mit-threads code is so old, it doesn't support 64-bit architecture on Linux!!
I'm not going to download a Vagrant box for 32-bit Ubuntu, if such a thing can even be found.
I'm giving up at this point. You are welcome to continue trying! :-)
I have to comment that software that is so old has had hundreds of severe security bugs fixed over the years. I wouldn't recommend using the software except temporarily to help serve as a source for ETL of the data into a more current RDBMS.
If I were you, I would invest the time instead into figuring out the character set issue so you could import directly into MySQL 5.7.
I would like to "update" a MySQL server from version 5.6.14 to the latest GA release 5.6.21. I have already reviewed the MySQL reference at http://dev.mysql.com/doc/refman/5.6/en/upgrading.html and Oracle's "How does Patching Work in MySQL?; How to Apply All the Latest Patches?; How to Find the Latest Patches (Doc ID 1589556.1)." But, these don't clearly explain the patching mechanism. The doc (id 1589556.1) instructs that "...to apply the latest patches to an existing installation, all that is required is to download and install the latest patch release." Well, will this not overwrite the existing server metadata and effectively make me loose the user, database, and privileges related info. in the existing server?
Please help with the exact patching steps or any link to a document with clearer instructions. Also, any gotchas, i.e., what do I need to watch out for?
Thank you.
https://dev.mysql.com/doc/refman/5.6/en/installing.html
Hi,
I did an upgrade from 5.6.14 to 5.6.22 recently on our dev environment. Please note this was on a Linux server
Backup database - I used MEB but MySQLDump or a cold backup is okay
Shutdown the database cleanly.
Upgrade the binaries (rpm -Uvh)
Start the database
I didn't need to run mysql_upgrade as the release has not changed.
Hope it helps.
I use yum update and its updated automatically into latest patchset.5.6.37.
So run "yum update" for centos or as per your linux distribution
I just did a clean install of CentOS Linux. The first thing I did after installing CentOS was to download MySQL and try to install the -server rpm file. But the installation fails with a lot of messages stating conflicts with MariaDB packages which seem to be redundant to those in MySQL. I want to use MySQL as my database.
Are there any reasons why I should not just delete mariadb, so that the conflicts can be resolved? If mariadb performs some important functions in CentOS, I do not want to end up having my system crash.
You could use MariaDB as mysql version 5.5 for it is just another MYSQL branch...
In Centos 7, it is a alternative project of oracle mysql. It contains all mysql functions and optimize structures, data processing, Algorithm etc..
you could even login the server with a "mysql" command.
you don't need to pay attentions on the name, it is no problem to your former mysql projects.
ps:
I don't think that a linux system will have a "clean", "pure" os environment. Linux is a free and open source system which means you could install and remove every thing with no problem.
To have MySQL database functionality you can install either the MySQL packages or the MariaDB packages. MariaDB is a fork originating from the same MySQL code base. For compatibility see https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibility/
Yes, you can remove MariaDB packages and replace them by MySQL packages.
I would like to replace MySQL 5.1 on my Debian Lenny 32-bit server to Percona Server with XtraDB. The main reason is better performance of Percona.
It's production server with many services running. Many other software may depend on mysql-client and other mysql shared libraries.
Is it safe to replace MySQL?
By "safe" I mean: 1. remove mysql, 2. install percona 3. everything works as before
Will it break dependencies in third party software?
Will it require to change configuration of third party software (ie. socket path, server port, shared libraries path)?
Will it require to install trillion of additional packages?
I really don't want situation with broken libraries, missing or incompatible header files and so on
We are currently in the process of upgrading from MySQL 4.1 to Percona Server 5.5 at work and Percona is as they say on their site a complete drop-in replacement for MySQL, the binaries use the same names, it uses the same libraries, same config file placement, takes the same parameters and it has exactly the same SQL syntax. They should also be data file compatible on the same version (MySQL 5.1 to Percona 5.1, etc) but it's nothing I've personally verified.
You are able to do an apt-get install percona-server-server-5.1 after adding their repositiories and it will automatically replace MySQL because it marks it as a conflicting package. But you must take an SQL dump of your database first, of course.
We currently have replication set up from a MySQL 4.1 master to a couple of Percona 5.5 slaves and have had no problems inserting SQL dumps either.
... don't know.
In my experience, the only way is to make up a copy of your existing setup on an old machine and run some tests. Then swap over to the new DB and run same tests again.
I just swapped a set of applications from Tomcat 5 to Tomcat 6 and in theory, with one or two tweaks, all should have worked fine. First time I tried it OpenJava was installed and the garbage collection fouled things up. Second time around with Sun Java, some dodgy date handling fouled things up and had to be corrected, seems to run fine now.