0

I have asked the question at Serverfault but it was suggested to take it to the DB specific forum. So here goes.

I'm tasked with migrating a bunch of MariaDB databases as well as some PHP and WSGI intranet applications from a RHEL7 host to RHEL8. During the transition / testing period the apps will run on both hosts in parallel but of course must access the same DB in order to stay up to date. Since the apps currently just use "localhost" for their DB host it would be convenient if they could continue to do that when transferred to the RHEL8 host, but that requires the DB on both hosts to be in sync with read/rite access.

Now if this all were done right and professionally, the host would have a central config file or environment variable pointing to the correct DB, so the final migration step on the RHEL8 server would be as simple as transferring the DBs using mysqldump etc, setting the single central DB info to the new host and be done. Suffice it to say that the whole setup is the surprisingly stable work of a bunch of in-company hobbyists (because we lack the proper IT resources), which includes me as an administrator.

Changing the currently hard-coded DB connections in the apps from the old to the new servers wouldn't be that much work. I just have to tell the app owners that they will have to do that within a very specific short time frame at some point. I'm just looking for a possibly easier strategy.

[EDIT]

Clarifications:

  1. All web apps and the MariaDB server are on the same host and will be moved together to a new host. As I mentioned, all apps refer to the DB on "localhost".

  2. DB version 10.3.35 is simply what was installed on the server by IT when they initially set up the VM. Probably need to do a yum upgrade. Except for my Python venvs I'll just stick to whatever RHEL8 deems up-to-date.

  3. Don't know yet if I will make all end users move to new URL or have IT do a DNS "rename" of the new host. From my experience our IT prefers to not make DNS changes.

1
  • Welcome to the DBA.SE community. Could you possibly be a bit more specific regarding your setup? Is your setup a server containing an app and the database that has to be migrated to a server containing the app and a new "same" database? Or are do you have a server with the app connecting to a server with a database and want to migrate the server containing the app to e a new server while also migrating the database to a new server? It's not quite clear (for me). Please hit edit and add your details. Thanks.
    – John K. N.
    Commented May 11, 2023 at 7:39

1 Answer 1

1

You choice of 10.3.35 (assumedly the RHEL8 one), is odd as the 10.3.39 just released yesterday represents the upstream end of life for 10.3. 10.6 or 10.11 from upstream might serve your long term needs better.

Replication seems the right option with binlog_checksum = NONE it seems. Run the replication for a while to ensure there aren't any data issues.

I'd provide your users with test only setup (separate from the to be production RHEL8) that contains their application running on the later MariaDB version. Get them to test this, with the realization that changes aren't save, and when they are when statised (then them no going back after migrated so they test it well), and move their application. Disable their web application on RHEL7 host and enabled on RHEL8 host (DNS etc). Ensure RHEL7 is disabled for their app (and don't do a drop database that gets replicated, much sadness will come from this).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.