Cloudron Forum

@necrevistonnezr I wasn't aware of the setting, good to know.

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 !