Also, see https://forum.cloudron.io/topic/3237/remote-sql-support-on-a-per-app-basis?_=1652377131316 on how one can connect with a SSH tunnel.

(please read warning in above comment before following instructions below).

If you want to make config file changes:

docker exec -ti mysql /bin/bash Edit /run/mysql/my.cnf as needed supervisorctl restart mysql

It is important to note that the changes to config files are not persistent across container restarts and server reboot. In general, we have not envisioned Cloudron as a development environment, but we do have many devs using it as such. So, if there is interest, maybe we need to improve things for such use cases.

@iamthefij Ok. Just restored matomo from backup again and it's all good.

I put some docs on how to fix the mysql addon here - https://docs.cloudron.io/troubleshooting/#mysql-addon . It's not "complete" but it's very hard to write those docs since there's a lot of things that can go wrong with mysql....

@vladimir-d DBeaver Database Dashboard? Or you thinking longer timeframe and more detail?

@jordanurbs thanks! I will look into making this automatic. https://git.cloudron.io/cloudron/box/-/issues/800

Ok, I will mark this as solved but let's investigate further if this comes up again.

FWIW, if you do docker exec -ti mysql /bin/bash then the details mysql logs are located at /tmp/mysqld.err .

@vladimir-d This is already fixed in the coming release - https://git.cloudron.io/cloudron/box/-/commit/6d044bfbf384b8ae98f1beac0f9d1c50005e8d34 . For now, you can ignore the warning, it's harmless.

@girish I think that might be an improvement worth considering, no? Making the necessary changes would (I think)...

Make it clear to monitoring tools and manual checks by users which processes being run are local to the host and which are from containers, particularly useful when multiple instances of a service are being run both on the host and container.

Follow what appears to be "best practices" when running containers.

Improve security in certain situations.

Admittedly these may be minor and not worth the overhead, but now that I'm aware of the behaviour, I'm a bit irked by it as it currently prevents me from easily identifying which services are container-run and which are local to the host, as well as making it confusing to which user is actually running the process listed.

@shai you have to build a custom app, please see this guide https://docs.cloudron.io/guides/multiple-databases-lamp/

@girish I requested the developers to review the query. Meanwhile I changed the setting in mysql and indeed the plugin doe work now as expected!

@msbt the old LAMP app will be left as-is. So, no change to that in the foreseeable future.

Generally, I am wary of putting this information for general use (and even in docs) because many things can go wrong . So, please, if you care about the data, don't hesitate to contact us on support@ . We help regardless of the subscription plan.

@drpaneas Just give that redis more memory. The "e1ca318a" is the app id. If you put in the search in the apps view, you will know which app's redis needs a bit more memory. It was reported earlier that pixelfed's redis needs more memory after the update. I guess this is because of update to Redis 5.

@nebulon I thought it was perhaps the Broken Links Checker on one of my WordPress installs, as as @marcusquinn noted it's widely known to sometimes cause such issues, but I've disabled that and I'm still getting these /mysql was restarted (OOM) (although they don't seem to appear in the event log?).

I note that the most recent one happened 5 minutes after my backups are due to start, and the other previous two times it's been 7-9mins before updates are due to run.

I wonder if either of those (backup/ update) processes might have something to do with it?

I guess I could just give mysql more memory and not worry, but be nice to know what's happening and why...

@d19dotca Ok, thank's to your attention! 🙂

@nj This happens when the initial db install task runs out of memory. I have seen this often in our tests as well. The fix is simply to reinstall.

@subven Thank you! I had not seen those docs 😯

It turned out that the Docker image of Mattermost used PostgreSQL, whereas on Cloudron if I'm not mistaken MySQL is used.

I tried converting migrating the PostgreSQL database to MySQL but it was a bit of a headache, so I have gone down the conventional route of using Mattermost's bulk export/import.

@girish said in Connect to lamp app mysql db from outside with db client like tableplus/navicat over ssh tunnel:

@andirahmat Try this - https://forum.cloudron.io/topic/3237/remote-sql-support-on-a-per-app-basis/2 . I haven't used tableplus/navcat but if you can post a screenshot maybe it helps debugging further. I think instead of mysql you just need to put in the IP of the mysql container using docker inspect mysql | grep IPAddress

ah this is it : docker inspect mysql | grep IPAddress

Thank you @girish !

I will mark this as solved for now but I suspect this will come back some day.

@fbartels said in MySQL tuning with my.cnf settings optimisation:

@lonk said in MySQL tuning with my.cnf settings optimisation:

when do we run / apply it?

Mysql tuning is best applied after a few days of database usage. Applications usually have different load patterns.

Gotcha, thanks for the tip! ☺️

@girish I think the issue with MySQL Workbench is I can't use the latest version as they don't support macOS 10.14 past a certain version, and a colleague on a later macOS can get it working on a later MySQL Workbench version but I can't update my OS at the moment until some other software I use is updated to work with the later OS. Classic catch-22 on that one.

I think the solution to this should just be to use DBeaver, it's free on all platforms, and seems to work on all OS versions. too.

Maybe better to save your time for the odd additional /phpmyadmin/ that might be useful on certain apps.

Certainly appreciate the help and looking, but I don't want to distract you too much given it's a software version compatibility issue and not a Cloudron issue really. Thank you all the same though!!

ok. I gave mysql more RAM. Since then the backups have been running smoothly.

I have added a clear section in the guide - https://cloudron.io/documentation/guides/import-mysql/#import

@woke If you don't mind, I would like to debug further if possible and fix up the docs as needed. Can you enable SSH support and send a mail to support@cloudron.io with the IP address? Thanks

@girish Thanks for the answer, but I didn't mean the internal server. I would like to install MySQL or another standalone server. I would like to try some things. Try and Error 🙂 I have three instances of Cloudron and I would like to install my own applications and if I can understand all things and requirements ... I do not know what can happen ....

First I have successfull ended a course on udemy.com for Docker.

This is possible but will increase complexity in deploys and maintenance. I have also noticed that MySQL changes things between patch releases a lot. Maybe because their release numbers don't follow semver .

@Trankery Yup, I will mark this as a feature request for a future release.

@girish said in mysql password ?:

The server only listens on localhost

I tried as root on the ubuntu (not inside a container)
this time it work, it must be the fault of cornavirus 🦇

There is no easy way to make the internal mysql server public without changing the code and I don't know what that will break.

I think you can setup a ssh tunnel between your minecraft server and the Cloudron.

Something like https://www.linode.com/docs/databases/mysql/create-an-ssh-tunnel-for-mysql-remote-access/

Do this on Cloudron:

docker inspect mysql | grep IPAddress "IPAddress": "172.18.0.4",

So, 172.18.0.4 is the IP of mysql server. Then, you can get the db credentials using the web terminal of the LAMP app:

env | grep CLOUDRON_MYSQL_

You can then connect using the above credentials as:

mysql --host=172.18.0.4 --user=<username> --password=<password> <db>

After the above works, you just setup SSH tunnel accordingly.