mikew
March 1, 2022, 9:51am
4
I have just checked another server and it seems to be related to mysql.
When looking at the process’s running I noticed two for mysql.
I tried to restart mysqld and it just kind of hung, using systemctl restart.
tried to stop using systemctl and hung as well.
ran kill -9 on PID and this fixed the issue.
I am still in the dark as why this happened or would happen
Doctrine requires the DB version is specified:
I’ve just checked the file app/config/local.php
and it seems it doesn’t specify the version.
@ekke , this is something Mautic should address, as it may cause issues like this in this issue.
ekke
March 1, 2022, 4:31pm
6
@aerendir not sure why it would hit out of blue sky, though… any thoughts?
@aerendir we do not specify it in the local.php any more since Mautic 4.0.
Please reference the detailed writeup in this PR:
mautic:features
← dennisameling:dynamic-db-platform-detection
opened 08:40PM - 28 Feb 21 UTC
| Q | A
| --------------------------------… ------ | ---
| Branch? | features
| Bug fix? | yes and no
| New feature? | no
| Deprecations? | no
| BC breaks? | yes
| Automated tests included? | no
| Related user documentation PR URL | N/A
| Related developer documentation PR URL | N/A
| Issue(s) addressed | Fixes #...
<!--
Additionally (see https://contribute.mautic.org/contributing-to-mautic/developer/code/pull-requests#step-5-work-on-your-pull-request):
- Always add tests and ensure they pass.
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against the "features" branch.
-->
<!--
Please write a short README for your feature/bugfix. This will help people understand your PR and what it aims to do.
-->
## Description
Mautic currently has a hardcoded `server_version` config parameter, set to '5.7'. However, this is problematic for a few reasons:
- Version 5.7 assumes MySQL, while MariaDB has a different versioning scheme (10.1, 10.2, etc.). Officially, if the `server_version` is hardcoded and the database type is MariaDB, [it needs to be prefixed](https://symfony.com/doc/current/reference/configuration/doctrine.html) by `mariadb-{VERSION}`, so that Doctrine knows it's MariaDB. Mautic currently doesn't do this, so Doctrine always thinks it's interacting with MySQL.
- The hardcoded version is written to Mautic's `config/local.php` file, so without a migration it won't be updated automatically if Mautic's minimal database version requirement changes. This has led to problems before; see https://github.com/mautic/mautic/pull/9437 as an example.
Since version 2.5, Doctrine has [automatic platform version detection](https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#automatic-platform-version-detection) built-in. So it will recognize if e.g. the minimum MySQL version is 5.7, required for some functionality that was only added in version 5.7.
As far as I know, there's no need (anymore) for Mautic to hardcode the database server version, hence this PR.
This PR also adds a new tab "Database info" to the "System info" page for easier debugging/troubleshooting:


<!--
If you are fixing a bug and if there is no linked issue already, please provide steps to reproduce the issue here.
-->
## Why database auto-detection is tricky in the installer
When Mautic isn't installed yet, you'll get an exception in the installer when no explicit `server_version` is set:

This was [already reported](https://github.com/doctrine/DoctrineBundle/issues/351#issuecomment-68962538) by @alanhartless to the Doctrine team in 2015, with no good fix for Mautic's use case to date.
The good news is that we can set a `server_version` manually in the installer, until the database credentials are set. The order of steps is as follows then:
1. Mautic sets temporary `server_version` to `5.7` in the installer
1. User enters DB config in Mautic's installer UI (db host, name, etc.)
1. Mautic recognizes that the DB config has been entered and switches over to Doctrine's automatic platform detection
1. Mautic installs the database schema (`installSchema()` below)
This order of steps is crucial. During my testing, before I had a fix for this in place, the detected database platform remained `MySQL` and it stayed like that until I removed the cache. In order to prevent issues in the future, we want step 3 (switch to automatic platform detection _before_ installing the schema) to happen first.
I came up with a somewhat ugly fix for this in the `AppKernel` by setting a constant called `MAUTIC_DB_NOT_CONFIGURED` that the installer can recognize. That way it knows exactly when to switch over to automatic database platform detection.
**Step 1.0 in the installer** (user sets database credentials):

**Step 1.1 in the installer** (Mautic now switches to automatic database platform detection, prior to installing the schema):

During schema installation, the correct database platform (MariaDB in this case) is indeed detected:

#### Steps to test this PR:
1. Load up this PR locally
2. Ensure Mautic's installer works correctly (ideally try both with MariaDB and MySQL, and both UI + CLI installations)
3. Check if the "database info" tab works as expected under `System info > Database info`
4. Run `php bin/console doctrine:schema:update --dump-sql`, it should return less than 10 queries to be executed
5. Try to do a clean installation based on the `features` branch. Ensure your `app/config/local.php` has a `db_server_version` parameter (if it doesn't show up right away, go to Configuration in Mautic's UI and hit Save). Then checkout this PR and run `php bin/console doctrine:migrations:execute --up 20210502162314`. The `db_server_version` parameter should now be removed from your `app/config/local.php` file.
<!--
If you have any deprecations, list them here along with the new alternative.
If you have any backwards compatibility breaks, list them here.
-->
1 Like
So, maybe the detection doesn’t work well?
The error is clear: it requires the database version to be set, so somewhere in the process of setting the version there is an error.
Maybe this is a bug of Doctrine… I don’t know…
Hi folks I had the same issue. That’s what I made and what I had:
I made a backup of Mautic (files and db)
I copy all in a new server
I gone to /app/config.php and correct all I need
I had this error:
Than i tried:
‘db_server_version’ => ‘5.1’
‘db_server_version’ => ‘mariadb-10.3.27’
nothing change.
Can you help me?
Thanks @mikew , my customer is on a shared hosting, I’ll open a ticket let me try
EJL
March 8, 2022, 1:17am
12
Running Mautic on a “shared hosting” plan is trouble looking for a place to happen. One of the newest examples in the upgrade from UI is going away in Mautic 5. Another is not being able to troubleshoot or run manual actions in the case of this issue. The “out of the blue” nature of this issue may be caused by a host restart of your VPS or the DB server.
1 Like
Thanks but not everyone can afford a personal server, the important thing is to be aware of it
mikew
March 8, 2022, 8:31am
14
Hey @antonio-lazzari
That is correct, however did you know that you can run a good version of Mautic on a $5 server/month. Not sure how much you are paying for shared hosting, but something to maybe bring up with your customer
1 Like
Lot of good options, best price/performance is:
UpCloud, Vultr, Linode, OVH (harder to use), DigitalOcean, Lightsail
2 Likes
Dears I finally solved it in this way:
I installed mautic to the same version
I have downloaded the old db in compatibility version mysql40
I have uploaded the dump
I updated the local.php file
I updated to the recent version and did some small setups
Now all working fine.
The problem was due to the old hosting service that ruined the db when exporting
1 Like
Another good option for about 5 eur / month is contabo
1 Like
Where is is stored now @rcheesley ? Which table(s)? Which file(s)?
TY!
Please read the detailed write up in the PR here:
mautic:features
← dennisameling:dynamic-db-platform-detection
opened 08:40PM - 28 Feb 21 UTC
| Q | A
| --------------------------------… ------ | ---
| Branch? | features
| Bug fix? | yes and no
| New feature? | no
| Deprecations? | no
| BC breaks? | yes
| Automated tests included? | no
| Related user documentation PR URL | N/A
| Related developer documentation PR URL | N/A
| Issue(s) addressed | Fixes #...
<!--
Additionally (see https://contribute.mautic.org/contributing-to-mautic/developer/code/pull-requests#step-5-work-on-your-pull-request):
- Always add tests and ensure they pass.
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against the "features" branch.
-->
<!--
Please write a short README for your feature/bugfix. This will help people understand your PR and what it aims to do.
-->
## Description
Mautic currently has a hardcoded `server_version` config parameter, set to '5.7'. However, this is problematic for a few reasons:
- Version 5.7 assumes MySQL, while MariaDB has a different versioning scheme (10.1, 10.2, etc.). Officially, if the `server_version` is hardcoded and the database type is MariaDB, [it needs to be prefixed](https://symfony.com/doc/current/reference/configuration/doctrine.html) by `mariadb-{VERSION}`, so that Doctrine knows it's MariaDB. Mautic currently doesn't do this, so Doctrine always thinks it's interacting with MySQL.
- The hardcoded version is written to Mautic's `config/local.php` file, so without a migration it won't be updated automatically if Mautic's minimal database version requirement changes. This has led to problems before; see https://github.com/mautic/mautic/pull/9437 as an example.
Since version 2.5, Doctrine has [automatic platform version detection](https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#automatic-platform-version-detection) built-in. So it will recognize if e.g. the minimum MySQL version is 5.7, required for some functionality that was only added in version 5.7.
As far as I know, there's no need (anymore) for Mautic to hardcode the database server version, hence this PR.
This PR also adds a new tab "Database info" to the "System info" page for easier debugging/troubleshooting:


<!--
If you are fixing a bug and if there is no linked issue already, please provide steps to reproduce the issue here.
-->
## Why database auto-detection is tricky in the installer
When Mautic isn't installed yet, you'll get an exception in the installer when no explicit `server_version` is set:

This was [already reported](https://github.com/doctrine/DoctrineBundle/issues/351#issuecomment-68962538) by @alanhartless to the Doctrine team in 2015, with no good fix for Mautic's use case to date.
The good news is that we can set a `server_version` manually in the installer, until the database credentials are set. The order of steps is as follows then:
1. Mautic sets temporary `server_version` to `5.7` in the installer
1. User enters DB config in Mautic's installer UI (db host, name, etc.)
1. Mautic recognizes that the DB config has been entered and switches over to Doctrine's automatic platform detection
1. Mautic installs the database schema (`installSchema()` below)
This order of steps is crucial. During my testing, before I had a fix for this in place, the detected database platform remained `MySQL` and it stayed like that until I removed the cache. In order to prevent issues in the future, we want step 3 (switch to automatic platform detection _before_ installing the schema) to happen first.
I came up with a somewhat ugly fix for this in the `AppKernel` by setting a constant called `MAUTIC_DB_NOT_CONFIGURED` that the installer can recognize. That way it knows exactly when to switch over to automatic database platform detection.
**Step 1.0 in the installer** (user sets database credentials):

**Step 1.1 in the installer** (Mautic now switches to automatic database platform detection, prior to installing the schema):

During schema installation, the correct database platform (MariaDB in this case) is indeed detected:

#### Steps to test this PR:
1. Load up this PR locally
2. Ensure Mautic's installer works correctly (ideally try both with MariaDB and MySQL, and both UI + CLI installations)
3. Check if the "database info" tab works as expected under `System info > Database info`
4. Run `php bin/console doctrine:schema:update --dump-sql`, it should return less than 10 queries to be executed
5. Try to do a clean installation based on the `features` branch. Ensure your `app/config/local.php` has a `db_server_version` parameter (if it doesn't show up right away, go to Configuration in Mautic's UI and hit Save). Then checkout this PR and run `php bin/console doctrine:migrations:execute --up 20210502162314`. The `db_server_version` parameter should now be removed from your `app/config/local.php` file.
<!--
If you have any deprecations, list them here along with the new alternative.
If you have any backwards compatibility breaks, list them here.
-->
Since version 2.5, Doctrine has automatic platform version detection built-in. So it will recognize if e.g. the minimum MySQL version is 5.7, required for some functionality that was only added in version 5.7.
… there’s no need (anymore) for Mautic to hardcode the database server version…
Read the PR for more detailed descriptions of how it works with the installer process.
Thank you @rcheesley .
My question was badly written tho.
I wanted to know where all the stuff (usually 500+ lines) that was in local.php is now to be found, since the local.pho file built by a fresh M4.4 installation is just over 30 lines.
Obviously I didn’t understand the issue at hand in this thread, so I think it is best if I open a new thread for the question, it is here:
Your software
My PHP version is : 8.0
My MySQL/MariaDB version is (delete as applicable): MySQL 8.0
Updating/Installing Errors
I am (delete as applicable): Installing and Updating
Your problem
After a fresh 4.4.5 install, I went to the local.php file to configure my Mautic.
I found there just over 35 lines, instead of the usually 400+ or even 700+ lines in some other installs.
Is this a bug on 4.4.5 and the file being generated on my 4.4.5 is bad?
or is it the new way of doing things?
…
1 Like
Ironically, I just experienced this on my own Mautic instance
It turned out something had made MariaDB angry and it was running but had crashed somewhere and wasn’t servicing connections.
Restarting MariaDB would not work so I had to reboot the server.
So I guess the long and the short of it is (based on what I’ve read from folks in the forum with this error), if you see this error, it’s very likely that something has gone awry with your database connection. Either your DB software is broken / disconnected, your credentials are incorrect, or maybe the server itself is under load which is causing intermittent issues with the database connection.