joomla / joomla-cms

Home of the Joomla! Content Management System
https://www.joomla.org
GNU General Public License v2.0
4.69k stars 3.63k forks source link

Joomla! 4.0 can't be installed on MariaDB 10.5.10 #34847

Open fontanil opened 2 years ago

fontanil commented 2 years ago

Steps to reproduce the issue

Use MariaDB 10.5.x on your server (I used the 10.5.10 on WampServer 64) and try to install Joomla! 4.0 RC (4 or 5dev)

Expected result

Installation OK

Actual result

With MySQi type of database driver: only 9 tables were created and the installation stopped with a message "table tags" is missing. Same error with MySQL PDO but 25 tables were created. With MySQL PDO type, another message is displayed: "42000, 1118, Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline."

System information (as much as possible)

PHP 8.0.7 or 8.0.8 (perhaps 7.4 too)

Additional comments

Installation on MariaDB 10.4.13 is OK.

richard67 commented 2 years ago

@fontanil Can you check if the issue happens also with MariaDB 10.5.11? The release notes of current 10.5.11 mention 2 regressions of which one could cause the problem here, I think: https://jira.mariadb.org/browse/MDEV-25672 .

fontanil commented 2 years ago

I just tried with MariaDB 10.5.11 and 10.6.3 (on PHP 8.0.8): same issue.

richard67 commented 2 years ago

@fontanil And you are getting exactly the same errors as with 10.5.10? Or are you getting different ones? The one you describe for MySQLi I would have expected to come from https://jira.mariadb.org/browse/MDEV-25672 , which has been fixed with 10.5.11.

fontanil commented 2 years ago

Yes, I have the same messages with MariaDB 10.5.11 and 10.6.3 on Wampserver 64.

New test with 10.6.3

With MySQL(DBO) type:

42000, 1118, Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

42S02, 1146, La table 'j4rc5dev.ru3b1_tags' n'existe pas

With MySQLi type only

Error

La table 'j4rc5dev.ru3b1_tags' n'existe pas

alikon commented 2 years ago

as per https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/

can you run before to install

SET GLOBAL innodb_default_row_format='dynamic';
SET SESSION innodb_strict_mode=OFF;
fontanil commented 2 years ago

Sorry, I don’t know how to do this on WampServer for Windows!

fontanil commented 2 years ago

Sorry, I'm not comfortable with server management and didn't know there was a MariaDB console to enter these lines.

Indeed, after their entry, the installation could well be done on the version 1.5.10

But how to do if these versions are installed on a shared server?

alikon commented 2 years ago

i've runned all the install sql on 10.5.11-MariaDB without issue https://dbfiddle.uk/?rdbms=mariadb_10.5&fiddle=17a8cb6934ddb2647c42200d02aae363 maybe some wampserver misconfiguration

wilsonge commented 2 years ago

https://github.com/joomla/joomla-cms/compare/4.0-dev...feature/mariadb-system-test

https://ci.joomla.org/joomla/joomla-cms/45970

@richard67 system tests running - shouldn't be a hard requirement to run it locally

wilsonge commented 2 years ago

These system tests pass with that mariadb version. So we're going to need to spend some more time figuring out exactly where the differences are between the wamp setup and the official docker setup. Official docker image is out the box 10.5.11 install. Unfortunately I don't have a windows machine to validate wamp...

richard67 commented 2 years ago

@richard67 system tests running - shouldn't be a hard requirement to run it locally

Yes ... if I had the right MariaDB version locally.

fontanil commented 2 years ago

On mariadb.log last try yesterday with MariaDB 10.6.3: Version: '10.6.3-MariaDB' socket: '' port: 3306 mariadb.org binary distribution 2021-07-21 8:39:41 5 [ERROR] InnoDB: Cannot add fieldimagesin tablej4rc5dev.rfmsc_tagsbecause after adding it, the row size is 8761 which is greater than maximum allowed size (8126 bytes) for a record on index leaf page.

fontanil commented 2 years ago

@alikon You are right, its a Wampserver misconfiguration. As said in the MariaDB page https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/ (Solving the problem)

In MariaDB 10.2 and later, the DYNAMIC row format is the default row format. If your tables were originally created on one of these newer versions, then they may already be using this row format. In that case, you may need to try the next solution.

So I uninstalled Wampserver, installed the full version 3.2.3 with MariaDB 10.5.4 and its update 3.2.5 and tried to install the last RC5-dev: no problem.

But if I add MariaDB 10.6.3 an try to install, the previous error is displayed. So I think that the MariaDB addon versions don't set the DYNAMIC row format.

PS: SET GLOBAL innodb_default_row_format='dynamic'; added in the MariaDB console is sufficient to correct this error

fontanil commented 2 years ago

page_size is 16K but in 10.5.11 and 10.6.3:

innodb-default-row-format=compact

De : Nicola Galgano @.> Envoyé : jeudi 22 juillet 2021 09:56 À : joomla/joomla-cms @.> Cc : fontanil @.>; Mention @.> Objet : Re: [joomla/joomla-cms] Joomla! 4.0 can't be installed on MariaDB 10.5.10 (#34847)

@wilsonge https://github.com/wilsonge what is the value for innodb_page_size in 4.0-dev...feature/mariadb-system-test ? i suspect 16K = 16384, should be possible to run the system test with innodb_page_size = 8K ?

i also suspect that @fontanil https://github.com/fontanil setting is innodb_page_size = 8K = 8192

alikon commented 2 years ago

finally able to replicate image

with this settings in my.cnf

innodb_page_size=8K innodb_default_row_format=compact

richard67 commented 2 years ago

@alikon What happens if you add a ROW_FORMAT=DYNAMIC to the end of the create table statement for the extensions table? Does the "Table '..._extensions' doesn't exist" disappear? And what do you think, should we try to fix our SQL scripts in such a way, or should we note required configuration details in our requirements on environment in the docs?

richard67 commented 2 years ago

Or maybe nicer not at the end but after the engine:

CREATE TABLE IF NOT EXISTS `#__extensions` (
  `extension_id` int NOT NULL AUTO_INCREMENT,
  `package_id` int NOT NULL DEFAULT 0 COMMENT 'Parent package ID for extensions installed as a package.',
  `name` varchar(100) NOT NULL,
...
  `state` int DEFAULT 0,
  `note` varchar(255),
  PRIMARY KEY (`extension_id`),
  KEY `element_clientid` (`element`,`client_id`),
  KEY `element_folder_clientid` (`element`,`folder`,`client_id`),
  KEY `extension` (`type`,`element`,`folder`,`client_id`)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_unicode_ci;
fontanil commented 2 years ago

Adding ROW_FORMAT=DYNAMIC (in CREATE TABLE for extensions or tags) doesn't work for me

alikon commented 2 years ago

so under 10.5.8-MariaDB-1:10.5.8+maria~focal-log with in my.cnf

innodb_page_size=8K
innodb_default_row_format=compact

i've setted ENGINE=InnoDB ROW_FORMAT=DYNAMIC for all tables

and i was able to install.... but dunno at moment what can be the best way to do it in a way that all mysql supported version and mariaDB works ....

richard67 commented 2 years ago

i've setted ENGINE=InnoDB ROW_FORMAT=DYNAMIC for all tables

and i was able to install....

@fontanil For @alikon it worked. Why not for you? Can you check if you maybe made something wrong or if you missed the error having change to another table? Can you check if you can install when adding it for all tables like @alikon did?

fontanil commented 2 years ago

I replaced "ENGINE=InnoDB DEFAULT" with "ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT" for all tables of the three installation sql files and it works now.

But I have same error with Event Gallery and Appointmentbooking Pro (extensions I am using on personal websites) and also with Community Builder. I therefore suspect that the installation of other extensions will fail for the same reasons.

richard67 commented 2 years ago

But I have same error with Event Gallery and Appointmentbooking Pro (extensions I am using on personal websites) and also with Community Builder. I therefore suspect that the installation of other extensions will fail for the same reasons.

@fontanil Yes, that's right. So the right solution might be that we have to update our docs about requirements by the necessary server settings. But at least we know now more about what the problem is and what could be possible solutions.

alikon commented 2 years ago

i would say... check

show variables like 'innodb_default_row_format;'

if compact set

SET GLOBAL innodb_default_row_format='dynamic';
fontanil commented 2 years ago

On shared servers I think we can't modify the "my.ini" with this code.

I tried to install the same sql (with ROW_FORMAT=DYNAMIC for each table) on MySQL 8 and I had no error.

I made the same changes for AppointmentBooking Pro and had no more errors on MariaDB.

richard67 commented 2 years ago

What confused me was that using "ROW_FORMAT=COMPACT" did not cause the error on MySQL 8 when I tested.

richard67 commented 2 years ago

On shared servers I think we can't modify the "my.ini" with this code.

@fontanil If a shared hosting provider doesn't provide an environment when you can run a CMS on, you should chose a different one. I'm pretty sure other CMS will fail, too, on that environment. It's the same if they have not sufficient PHP settings and not allow you to change that. The important thing is that we clearly identify and document the requirements.

Because I did not get the error when using "ROW_FORMAT=COMPACT" on my MySQL environment, I think it might be connected to other settings, too, if the error happens or not, e.g. to the innodb_page_size.

fontanil commented 2 years ago

Same problem with a 3.9.29 dev version and a 3.9.28 stable on MariaDB 10.5.11 and 10.6.3 (and PHP 8.0.8 or 7.4.9): Error La table 'j39dev.#__tags' n'existe pas Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

richard67 commented 2 years ago

As described here, the default row format on MySQL 5.6 and earlier was "compact", too: https://tonnygaric.com/blog/difference-in-innodb-s-default-row-format-between-mysql-5-6-and-5-7 . Joomla 3 and 4 run with MySQL 5.6 and J3 with older versions without problems, J3 since ages. So it must be some other server setting in addition which makes the problems.

fontanil commented 2 years ago

In the my.ini files of MySQL up to 5.7 and MariaBD up to 10.4, there is no line innodb-default-row-format It is only found starting with MySQL 8 and MariaDB 10.5 I compared the my.ini files of MariaDB 10.6 and MySQL 8 and I could not find what difference in settings could explain this behaviour of MariaDB and this size error

brianteeman commented 2 years ago

Is this something that should be marked as a release blocker or should it just be documented as a known issue with wamp

richard67 commented 2 years ago

I’d say the latter.

fontanil commented 2 years ago

This error will occur on all servers that use a version >=10.5 of MariaDB with row format = compact. You will need to be able to change to row format = dynamic. In Wampserver it is easy to modify my.ini or use the console. As I said, the problem will arise on shared servers if you can't change this format.

brianteeman commented 2 years ago

@richard67 was this documented? If so then this can be closed?

richard67 commented 2 years ago

I don’t know of this being documented somewhere.

brianteeman commented 2 years ago

I would write it myself but I dont fully understand it.

fontanil commented 2 years ago

Hi, Use a server with MariaDB 10.5 or 10.6 (I tried this morning with MariaDB 10.6.5 and Joomla! 4.0.4 on Wampserver), install Joomla!, you will get this message "La table 'getjmdb106.jfspi_tags' n'existe pas" (The table 'getjmdb106.jfspi_tags' does not exist). As we said, it's a problem with the row format and need to add ROW_FORMAT=DYNAMIC for each table creation in the SQL files. A lot of shared servers are using MariaDB only and if this problem in not solved before they change their version from 10.3 or 10.4 we will have many failed installations and probably users who will not know how to modify the installation SQL themselves and may abandon Joomla! This problem will also affect third party extensions. Can't anyone work with the MariaDB team to find a solution to this problem?

alikon commented 2 years ago

despite i still think that's a server mis-configuration issue we need to start to think at MariaDB as 1st citizen DB

alikon commented 2 years ago

i mean MariaDB it's STILL not mentioned on https://docs.joomla.org/Special:MyLanguage/J4.x:Optional_Technical_Requirements it should be

stavroszach commented 2 years ago

My two VPS servers use MariaDB 10.3 and since this version's EOL is in a year or so, I thought of upgrading them (through the WHM control panel) to MariaDB version 10.5. In the process, I got three warnings, requiring my express authorization before proceeding, which stopped me in my tracks. One of the warnings concerns a third party database monitoring software which I don't use, therefore it's irrelevant for me. The other two put me into scratching my head because of my ignorance of what they say and whether they may impact negatively on my Joomla websites totaly/partially immediately or sometime later down the road. Those two warnings are copied below. Can somebody with experience tell me whether a Joomla 3 or 4 website may somehow be negatively affected?

Thank you.


Severity: Critical Message: In MariaDB 10.4 and later, the mysql.global_priv table has replaced the mysql.user table. The mysql.user table is converted into a view of the mysql.global_priv table during the database upgrade. The dedicated mariadb.sys user is created as the definer of the new mysql.user view.

Severity: Normal Message: All binaries previously beginning with mysql now begin with mariadb. Symlinks are created for the corresponding mysql commands to ensure backwards compatibility. Usually that should not cause any changed behavior, but when starting the MariaDB server via systemd, or via the mysqld_safe script symlink, the server process will now always be started as mariadbd, not mysqld. Any 3rd party software or scripts looking for the mysqld name in the system process list must now look for mariadbd instead.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/34847.

richard67 commented 2 years ago

@stavroszach Both messages have nothing to do and no effect on Joomla CMS, they are related to the database server setup and configuration. Note that this here is an issue tracker for the CMS and not a support forum for hosting questions.

joomleb commented 2 years ago

i mean MariaDB it's STILL not mentioned on https://docs.joomla.org/Special:MyLanguage/J4.x:Optional_Technical_Requirements it should be

I'm totally agree, hoping that there will soon be news about it...

xillibit commented 4 weeks ago

I have just spend hours on trying to install Joomla! 4.4.5 on my hosting provider, then i have found this issue. I have just figured out that he is using MariaDB 10.6.18. I can only install a backup with Akeeba, then i can't log on the backend it says that the page isn't redirected correctly

fontanil commented 4 weeks ago

Hi,

I think the problem was resolved as I have on a local server (MariaDb 11.2.2) many sites, some are from Akeeba backups, other were installe as new sites.

Try to rename the .htaccess and test the administrator access.