Unistall MariaDB or create new server?

1

Hello

I have a server with php + apache + mariadb…
It has some important customizations. I would like to separate mariadb on another server.

However, as there are customizations, I would like to NOT need to install php + apache again on one server and mariadb on another server.
That said, is it valid to uninstall mariadb from the current server and just install mariadb on another server?

Or would this cause problems and the ideal is to install hestiacp again on 2 servers, one with apache + php fpm and the other with mariadb?

2

Will they conflict? If so, you can choose not to install mariadb where it is not needed.

3

Hi @brunoschneider,

There is no problem and there is no need to install Hestia with mariadb in the other server, you can install only mariadb.

In your Hestia server, you should add the remote db with command v-add-database-host.

v-add-database-host TYPE HOST DBUSER DBPASS [MAX_DB] [CHARSETS] [TPL] [PORT]

Once added you could select it inside Hestia to create/use those dbs.

Yes but, if you are using webmail (roundcube or snappymail) you can’t uninstall mariadb on Hestia side because both webmails need the db.

1 Like
4

First of all, thanks for the “v-add-database-host” tip

I would like to install hestiacp + mariadb on another server because I currently create a database using the hestia api (v-add-database) and with that I can use the backup issue…

So supposing I install hestiacp + mariadb on another server.
The current server is “all” (hestiacp + mariadb + php + apache), can I UNINSTALL mariadb? Won’t it cause problems since you have a hestiacp installation and could it generate conflicts?
Or in this case, the ideal would be to just inactivate mariadb without uninstalling it?

5

And you will configure your current Hestia sites to connect to the other db, right?

If you are not sure about the result, never uninstall, just stop or disable and stop the service, in this case mariadb.

As fas as I know (I didn’t take a deep look) you don’t need to reconfigure the Hestia conf to disable DB_SYSTEM so just add your new db host with the command v-add-database-host, test it to create or use it in one of your sites, if it works as expected and you are not using roundcube or snappymail, disable and stop mariadb and if in a future you want to remove it… just do it but there is no need .

1 Like
6

Yes, the idea is that all current databases are migrated to the new server… I’ll go along the lines you mentioned, on the current server, after migrating the databases, just stop mariadb to avoid any problems … Thanks

2 Likes
7

You may go ahead by uninstalling any of the modules/packages of MariaDB. I have done it a thousand times on several servers. This has never ever been a problem because the install uses all defaults that has nothing specific to HestiaCP.

Mind you, the new install uses a start script. So after re-install of the MariaDB, the DB server will not start unless you once again modify the start script. This happened after each and every update of MariaDB, hence I always uninstall and reconfigure.

To avoind headaches, I wrote a little bash script for that. If you want the re-install script, I can give you here.

8

Thanks for reply…

My main question is whether on the server where I currently have mariadb, I can uninstall mariadb (after migrating to another server). I have my doubts if uninstalling mariadb on the current server won’t cause problems…

9

Why uninstall? Can’t exist with each other? Is this just OCD?

10

Thanks for posting your contribution.

11

I have not experimented with this variation.

I do not use any remote MariaDB connections. I think it is not very good to use MariaDB over a remote connection unless there is a need to go for distributing loads and seperating services, like http on one and DB on the other. When admins do this setup, this may also have intentions of load balancing and protection technoloigies in mind.

I use the entire setup of multiple servers differently. On each server, I have Galera cluster installed and properly configured. Then it will make sure that one remains a MasterDB and others slaves. It will map every transaction to a Global ID and there will never be a conflict.

By doing so, the consistency of DB is maintained, DB remains updated, load gets distributed, which is a different form of load balancing.

This setzup should be used - in particular - when the VPS/Servers are residing in different datacenters. When they are within the same datacenters (or with the same provider) the latency and connectivity isn’t a problem. But otherwise it can cause a problem.