MariaDB 10.6: InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED

[ruifung]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

On my MariaDB installation where I have page compression enabled by default (https://mariadb.com/kb/en/innodb-page-compression/) which the official documentation recommends on the page for COMPRESSED row format (https://mariadb.com/kb/en/innodb-compressed-row-format/).

While page compression is enabled by default, DB migrations that create new tables fail as ROW_FORMAT=COMPRESSED can not be used with a page compressed table. While this is primarily a database configuration matter, is it possible to override the default create options specified at (https://github.com/nextcloud/server/blob/905e1918d2796b9a79025283cd6edf2c40f49d77/lib/private/DB/ConnectionFactory.php#L228) from the nextcloud configuration?

See https://github.com/nextcloud/mail/issues/4443

[ax-meyer]

I would appreciate it if there was a clear path communicated how this problem will be handled.

E.g. on the Docker-Image page (https://hub.docker.com/_/nextcloud) the example file for a setup with docker-compose still pulls mariadb:latest which is 10.6.5 and won't work without a workaround. Very bad experience for new users.

I manually pinned my setup to 10.6.5 with the workaround to avoid a full break when the upgrade to 10.7 rolls out.

[Tsaukpaetra]

I just find it hilarious that it's come this far. Are the devs asleep at the helm? Put a test fix on a testing branch and get some feedback. Once nobody notices any further breakage, put it to prod.

What the hay is the holdup???

[solracsf]

Tests had been added: https://github.com/nextcloud/server/pull/30129

[jakimoff]

:star2: Hello everybody! :star2:

If you already install MariaDB/MySQL on your Linux you can disable it in this way. nano /etc/mysql/mariadb.conf.d/50-server.cnf or nano /etc/my.cnf.d/server.cnf

add in mysqld section next line

[mysqld] innodb_read_only_compressed=OFF

and then run

sudo service mysql restart

Cheers ;-)

[My1]

If you already install MariaDB/MySQL on your Linux you can disable it in this way.

this is known but also is mentioned to be removed in newer versions so other than a bandaid it's really nothing

[davralin]

Forgot I was subscribed to this post, I "resolved" my issue by migrating to postgresql instead.

My instance seems to even run faster now.

[solracsf]

Merged and will be shipped with NC24.

[Nascire]

Out of curiousity - the referenced change only affects new installations it seems? What about existing installations with COMPRESS format?

[dr-m]

To allow the ROW_FORMAT=COMPRESSED tables of old installations to be written to in MariaDB Server 10.6 or later, you should set the following in the server configuration. With the loose_ prefix it will be compatible with older MariaDB or MySQL as well.

loose_skip_innodb_read_only_compressed

This parameter was introduced in MariaDB/server@9bc874a594edbc0e124131d0ff30b44f5fade52d to give users advance notice about the possible removal of this feature. Note: There currently is no plan or committed schedule to remove the format.

[Nascire]

With "it will be compatible" you mean "it will work till they deprecate it", right?

What I´m asking for, is an official way (recommended by Nextcloud) for all people out there ...

[Aaron-Ritter]

if i get you right @Nascire and likely the same what I am looking for:

Looking for a solution on how to "fix" existing installations e.g. migrate the existing data away from using compressed row_format. basically an upgrade migration script?

[assen-totin]

Hi,

Don't know about "supported", but here is what you need to do

SELECT TABLE_NAME from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='your_nc_db_name' AND ENGINE='InnoDB' foreach ALTER TABLE your_nc_db_name.table_name ROW_FORMAT=DYNAMIC

Use your favourite scripting language.

WWell,

Assen Totin

On Wed, 19 Jan 2022 at 19:35, Aaron Ritter @.***> wrote:

if i get you right @Nascire https://github.com/Nascire and likely the same what I am looking for:

Looking for a solution on how to "fix" existing installations e.g. migrate the existing data away from using compressed row_format. basically an upgrade migration script?

— Reply to this email directly, view it on GitHub https://github.com/nextcloud/server/issues/25436#issuecomment-1016703844, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQG3C4WKJWSCNFTTYI5Z33UW3Y7VANCNFSM4W6UY4DA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[tohojo]

Here's a query to generate the required ALTER_TABLE commands for all affected tables in a mysql instance:

SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," ROW_FORMAT=DYNAMIC;") from INFORMATION_SCHEMA.TABLES where CREATE_OPTIONS LIKE "row_format=compressed" AND ENGINE="InnoDB"

This can be directly piped into mysql to run the whole conversion at once (but do make sure to run the query manually first to see that it looks reasonable):

mysql --batch --skip-column-names -e 'SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," ROW_FORMAT=DYNAMIC;") from INFORMATION_SCHEMA.TABLES where CREATE_OPTIONS LIKE "row_format=compressed" AND ENGINE="InnoDB"' | mysql

It needs to be run as a user with the right privileges to perform the conversion (e.g., root), obviously... Also it takes a while to run, depending on the size of the tables.

[dr-m]

@tohojo Thank you. I would also expect ROW_FORMAT=DEFAULT to work. It should drop any explicit ROW_FORMAT. The global parameter innodb_default_row_format was introduced in MySQL 5.7 and MariaDB Server 10.2, with the default value DYNAMIC, which in my opinion is the most sensible format. Older versions of MySQL and MariaDB have already reached their end of life.

In retrospect, https://dev.mysql.com/worklog/task/?id=7703 and https://dev.mysql.com/worklog/task/?id=8307 should have been done already in MySQL 5.6 or perhaps even 5.5. The original motivation of these parameters was to allow easy downgrades from a separately distributed InnoDB Plugin for MySQL 5.1. Generally, I do not think that downgrades between major releases can ever be really tested or guaranteed. It is enough effort to ensure that upgrades work.

[dr-m]

Forgot I was subscribed to this post, I "resolved" my issue by migrating to postgresql instead.

My instance seems to even run faster now.

@davralin I am not surprised of that if the MariaDB server is mostly running with the default settings (if there are no additional settings to those that Beetix/My-infra@7d8e400b4f636728538c50f14168d284ae6644e1 changed).

The default innodb_buffer_pool_size=128M might be reasonable for a tiny system nowadays, say, a Raspberry Pi model with 1GiB of RAM and running also other services. For reasonable performance, the buffer pool should be made as large as possible: something like 80% of the available RAM, unless the active working set is expected to be smaller than that, and the some RAM is needed for other processes that are running on the system.

Likewise, the default value of innodb_log_file_size=96M is unreasonably small. Starting with MariaDB Server 10.5, we should not run out of memory in recovery even if the log is much larger than the buffer pool. While also older versions of MariaDB or MySQL can perform crash recovery in multiple batches, it could run out of memory due to some inefficiencies and bugs in the recovery memory management.

With a large log, log checkpoints will be less frequent. This means that changed pages can stay dirty in the buffer pool longer, and will have a better chance of being changed again in the buffer pool, before having to be written back to the data files. (On log checkpoint, or when a page needs to be evicted from the buffer pool to make room available for other pages.) The downside of a large log and infrequent checkpoints is that crash recovery may run longer. But, the recovery speed was improved in MariaDB Server 10.5 thanks to an easier-to-parse redo log format.

MariaDB Server 10.6 made the default configuration even ‘worse’ by changing innodb_flush_method=O_DIRECT by default (MariaDB/server@420f8e24ab73ef00b323aaa9423f365fb38e9306). With this change, writes to InnoDB data files will go directly to the data files, bypassing the Linux kernel’s file system cache. So, if you have lots of RAM available but a tiny buffer pool, and the pages will have to be read frequently back from the data files, the data would no longer be in the Linux kernel’s cache, but instead it would be always be fetched directly from the files.

One size does not fit all. The default 128MiB buffer pool could make perfect sense in a small system, so it may not be reasonable for MariaDB to change the default.

For any administrator, I think that it is good to review the configuration. The buffer pool size makes a huge impact for all workloads (even read-only), and an unreasonably small log file size makes writes slow, or can cause premature wear of the storage device due to unnecessarily frequent log checkpoints.

Perhaps the NextCloud documentation or setup scripts should cover this, if it is not already the case. There probably also are some Postgres tuning hints.

[rugk]

@dr-m IMHO the real "proper" solution that would likely cover 90% of the use cases is if MariaDB would just calculate the mentioned default values dynamically (based on the RAM, e.g., as you said) instead of using fixed ones - if they are not explicitly overwritten), that would help a lot. Just my opinion, maybe there are feature requests for it, maybe there are arguments against it. Anyway, it's kinda off-topic… But interesting observation anyway, in any case, thanks.

[ManjotS]

I am surprised nextcloud didn't deal with this during MariaDB 10.2 or 10.3 when most people stopped using compressed.

[montywi]

Manjot, where have you heard/seen that people are stopping using compressed? I need to check from the feedback plugin how many people are using compressed pages. (Fortunately this is something that is logged that we can check)

[dr-m]

@dr-m IMHO the real "proper" solution that would likely cover 90% of the use cases is if MariaDB would just calculate the mentioned default values dynamically (based on the RAM, e.g., as you said) instead of using fixed ones - if they are not explicitly overwritten), that would help a lot.

@rugk You are right. I was just informed that the task MDEV-19895 exists to achieve exactly this.

@montywi The built-in InnoDB in MySQL 3.23, 4.0, 4.1, 5.0, and 5.1 supported only column prefix index sizes up to 767 bytes (CHAR(255) in UTF-8). This was because in the clustered index, for any column that is longer than that, a 768-byte (yes, not 767-byte) prefix was stored locally, followed by a 20-byte BLOB pointer. For the "InnoDB Plugin" that Oracle (which had acquired Innobase Oy) distributed separately for MySQL 5.1, I implemented ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPRESSED formats that were like the ROW_FORMAT=COMPACT that I had introduced in MySQL 5.0.3, with the exception that no local prefix of off-page columns is stored in the index page.

I understood that this feature (not wasting 768 extra bytes per BLOB column in each index record) was why NextCloud started to explicitly specify a ROW_FORMAT. Until MySQL 5.7 or MariaDB 10.2, it had to be specified explicitly to avoid the BLOB limitation.

To allow users to downgrade from the InnoDB Plugin to the built-in InnoDB in MySQL 5.1, the parameter innodb_file_format was introduced. By default, the creation of DYNAMIC or COMPRESSED tables was disabled. I thought already back then (2006 or 2007) that it was a mistake to introduce that parameter. In MySQL 5.5, the former InnoDB Plugin became the built-in InnoDB (because meanwhile Oracle had acquired Sun Microsystems, which had acquired MySQL), and some more ‘damage’ was added by allowing column prefixes of up to 3072 bytes to be used in indexes on DYNAMIC or COMPRESSED tables, but only if another parameter is explicitly enabled. Sane defaults were implemented by me in MySQL 5.7 (WL#7703), and the insane parameters deprecated and removed, I think in MySQL 8.0 and MariaDB Server 10.3.

MariaDB Server 10.2 inherited these sane defaults from MySQL 5.7, and a simple CREATE TABLE would have defaulted to the sane default ROW_FORMAT=DYNAMIC. I think that @ManjotS slightly confused these things.

[wehrlean]

mysql --batch --skip-column-names -e 'SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," ROW_FORMAT=DYNAMIC;") from INFORMATION_SCHEMA.TABLES where CREATE_OPTIONS LIKE "row_format=compressed" AND ENGINE="InnoDB"' | mysql

Thank you for this possibility, but unfortunately then the update to a new version of Nextcloud does not work, because there again new tables are created with COMPRESSED. At least with my Nextcloud when updating from version 22.1.1 to 22.2.3, it is the new table 'oc_ratelimit_entries '(#28815)

[jotoho]

mysql --batch --skip-column-names -e 'SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," ROW_FORMAT=DYNAMIC;") from INFORMATION_SCHEMA.TABLES where CREATE_OPTIONS LIKE "row_format=compressed" AND ENGINE="InnoDB"' | mysql

Thank you for this possibility, but unfortunately then the update to a new version of Nextcloud does not work, because there again new tables are created with COMPRESSED. At least with my Nextcloud when updating from version 22.1.1 to 22.2.3, it is the new table 'oc_ratelimit_entries '(#28815)

A previous comment by a team member said that the patch which closed this issue will be included in Nextcloud 24. So its probably not in any released versions yet

[dr-m]

The immediate problem should go away if you upgrade to MariaDB Server 10.6.6 or later, thanks to @montywi who suggested to implement a permissive default setting: MDEV-27736 Allow seamless upgrade despite ROW_FORMAT=COMPRESSED.

The motivation of disallowing writes to such tables by default was to give an early warning, or to seek feedback from users. (Nobody from NextCloud filed a MariaDB bug; I accidentally found this ticket.) Now that I know that several users still find this old format useful despite its limitations, and that there is no good replacement for it for their use cases, I have changed plans and we will retain the ROW_FORMAT=COMPRESSED support in the foreseeable future.

I apologize for the inconvenience that was caused by this. But I am sure that everyone agrees that it would have been a much bigger inconvenience if we had gone ahead and actually removed code that would be very difficult to restore later due to code cleanups that would have been allowed by the code removal. The 10.6 configuration parameter innodb_read_only_compressed will remain available for those who wish to force a migration away from ROW_FORMAT=COMPRESSED InnoDB tables.

[jotoho]

The immediate problem should go away if you upgrade to MariaDB Server 10.6.6 or later, [...]

Note: The "Fix Versions" noted in that ticket aren't tagged on GitHub or available on Docker Hub right now. So we should probably not blindly upgrade just yet.

But it's good to know that a mariadb update to help with this is on it's way. :+1:

[danepowell]

As a brand new Nextcloud user, can someone please recommend what I should do to avoid shooting myself in the foot here? And can we maybe document this in the Docker Readme?

I see that with the current versions of MariaDB and Nextcloud I can use the --skip-innodb-read-only-compressed flag to work around this issue, but it sounds like that's not a future-proof solution since I'll have to "migrate" the compressed tables at some point after Nextcloud 24 is released?

[Kraligor]

I see that with the current versions of MariaDB and Nextcloud I can use the --skip-innodb-read-only-compressed flag to work around this issue, but it sounds like that's not a future-proof solution since I'll have to "migrate" the compressed tables at some point after Nextcloud 24 is released?

Both sides are working on a fix, but looks like MariaDB has already implemented it for 10.6.6. For now I'd just keep using the flag and removing it once you've updated to a fixed MariaDB version. I'd imagine that Nextcloud 24 will give you an option to keep the compressed tables now that the issue has more or less been resolved, at least "for the foreseeable future".

[nursoda]

Thank you @dr-m for your extensive explanations – it helps a lot to understand historical decisions and it's so cool to see that you're changing plans to allow for a smooth migration. So here's my summary:

• ROW_FORMAT DYNAMIC is superior to COMPRESSED, no drawbacks for typical NC installations
• MariaDB re-allows ROW_FORMAT=COMPRESSED for the time being
• Nextcloud will use ROW_FORMAT=DYNAMIC for new NC installations starting with NC24
• Nextcloud may/should? implement a migration to convert COMPRESSED to DYNAMIC for existing NC installations

@all: Please correct if I got something wrong.

[dr-m]

MariaDB/server@05c33d6216ab125b964be54701f474bcf445241e addressed this in 10.6.6, 10.7.2, 10.8.1.

[GieltjE]

Just as a general heads up MariaDB 10.7.3 has been declared GA. So we might start seeing it soon on real world servers.

[obel1x]

still, current stable nextcloud 23.0.3 does NOT support mariadb 10.6, as rowformat=compressed is still in code and #30129 has not been ported to NC 23.

And of course, updating from 23.0.2 to 23.0.3 fails due to this on mariadb 10.6.

So maybe port it to 23 now!?

[GieltjE]

Even funnier is collaborating with MariaDB while being incompatible with they are now partnering with a product they are at least partially incompatible with: https://nextcloud.com/blog/nextcloud-and-mariadb-collaborate-to-boost-scalability-and-high-availability-for-customers/

[viceice]

Just as a general heads up MariaDB 10.7.3 has been declared GA. So we might start seeing it soon on real world servers.

It seems they reverted the rowformat change on 10.6.6 and 10.7.2, so i assume it's safe to upgrade to 10.7.3 (security fix)?

https://jira.mariadb.org/browse/MDEV-27736

[grooverdan]

Did "Nextcloud may/should? implement a migration to convert COMPRESSED to DYNAMIC for existing NC installations" become a plan? A Nextcloud user did hit a ROW_FORMAT=COMPRESSED bug (MDEV-28512) during Nextcloud upgrades. As @dr-m described convoluted history above shows, ROW_FORMAT=COMPRESSED is still a bit scary.

[mgulick]

I know this issue is closed, but I don't know of any other place where this issue was being discussed at present. Since this issue first happened, I've had mariadb pinned to 10.5 in my docker-compose.yml file. It looks like now, in NC24, tables are no longer converted to COMPRESSED on upgrade (https://github.com/nextcloud/server/commit/e49233a79546f36771e31b96e330eedf61b63a34), so it should be safe to manually convert tables to DYNAMIC. Here is the procedure I used:

1) docker-compose stop # Stop the container to make a backup 1) Snapshot or copy the database docker volume for backup 1) docker-compose start # Restart the containtainer 1) docker-compose exec -u www-data app php occ maintenance:mode --on # Put nextcloud in maintenance mode 1) docker-compose exec db /bin/bash # Enter database container 1) Thanks to @tohojo for the following command (https://github.com/nextcloud/server/issues/25436#issuecomment-1017462542): mysql -u root -p<DB_ROOT_PASSWORD> --batch --skip-column-names -e 'SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," ROW_FORMAT=DYNAMIC;") from INFORMATION_SCHEMA.TABLES where CREATE_OPTIONS LIKE "row_format=compressed" AND ENGINE="InnoDB"' | mysql -u root -p<DB_ROOT_PASSWORD> 1) exit # Exit database container 1) docker-compose start 1) docker-compose exec -u www-data app php occ maintenance:mode --off # Turn off maintenance mode 1) Make sure that nextcloud appears to be working 1) Edit docker-compose.yml and change image: mariadb:10.5 to image: mariadb:latest 1) docker-compose pull 1) docker-compose up -d

Did I miss anything?

[NeoTrace82]

im running nextcloud in a portainer stack and I cannot get past "3." as it says Container isn't running, you might have a hint what to do?

[predmijat]

im running nextcloud in a portainer stack and I cannot get past "3." as it says Container isn't running, you might have a hint what to do?

"db" is a generic container name he used, you should replace it with whatever your Nextcloud container is called - check it with docker ps

[NeoTrace82]

well that I know... but when I execute it, it says its not running...

pi@dontpanic:~ $ sudo docker exec nextcloud_db /bin/bash
Error response from daemon: Container d97fa22f4433fcdd88d0f16e0ad4882039046e1b1fa91b780fac9adcd4b18d9b is not running
pi@dontpanic:~ $ sudo docker start nextcloud_db
nextcloud_db
pi@dontpanic:~ $ sudo docker exec nextcloud_db /bin/bash
OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown
pi@dontpanic:~ $ 

[predmijat]

That's a different error now. Try /bin/sh instead of /bin/bash.

[NeoTrace82]

well I did get to login when using portainer, from the command line it would exit out immediately so far so good but when trying to execute the mysql, I get errors whatever I try (adding my password to the command or trying other stuff)

might have figured it out, how do I check if the change was successfully?

[mgulick]

im running nextcloud in a portainer stack and I cannot get past "3." as it says Container isn't running, you might have a hint what to do?

Sorry I had tried to simplify them a little, but I forgot that the containers had to be running in order to update the database (well technically only the database container needs to be running, but it was simpler for me to have them all running and just turn on maintenance mode in nextcloud).

I've edited the comment and updated the steps.

[mgulick]

well I did get to login when using portainer, from the command line it would exit out immediately so far so good but when trying to execute the mysql, I get errors whatever I try (adding my password to the command or trying other stuff)

might have figured it out, how do I check if the change was successfully?

If you run the mysql query again in the database container, without piping it to mysql, it should print nothing. I suppose its possible that nextcloud may re-enable compressed row format in the future with another database upgrade/repair, but as long as you're running Nextcloud 24 or higher, that code that was previously doing that does appear to be removed. You could check again the next time nextcloud updates itself.

[NeoTrace82]

thanks

did run the command with "dynamic" just to make sure, worked

[danepowell]

Nextcloud docs still say anything above MariaDB 10.5 is not recommended. Is that still the case? It seems to me that there's still work to do here, either those docs should be updated or the official docker-compose example should pin MariaDB to 10.5:

• https://hub.docker.com/_/nextcloud
• https://docs.nextcloud.com/server/latest/admin_manual/installation/system_requirements.html

[dr-m]

It is indeed strange to recommend MariaDB 10.2, which already reached the end of its life; 10.2.44 in May 2022 was the last release in that series. The 10.6 release includes many InnoDB fixes that are not technically feasible to apply to older versions. For example, the upcoming 10.6.9 release finally fixes the infamous bug MDEV-13542 Crashing on a corrupted page is unhelpful.

[dr-m]

I finally figured out how to reproduce MDEV-26577. Upgrades of NextCloud are most certainly affected by that, because they invoke ADD COLUMN. This should affect upgrades to MariaDB Server 10.3 or later from databases that were originally created before MariaDB Server 10.2 or MySQL 5.7. SET GLOBAL innodb_instant_alter_column_allowed=never; would work around it.

[bombz88]

Hello,

I am experiencing what I think is the concern regarding updating NC with mariadb and I cannot continue the NC update due to errors.

 occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug
Updating database schema
Exception: Database error when running migration latest for app core
Update failed
Maintenance mode is kept active
Resetting log level
#

occ upgrade -vv

Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
2022-10-28T10:01:47+00:00 Setting log level to debug
2022-10-28T10:01:47+00:00 Repair step: Repair MySQL collation
2022-10-28T10:01:48+00:00 Repair info: All tables already have the correct collation -> nothing to do
2022-10-28T10:01:48+00:00 Repair step: Repair SQLite autoincrement
2022-10-28T10:01:48+00:00 Repair step: Copy data from accounts table when migrating from ownCloud
2022-10-28T10:01:48+00:00 Repair step: Drop account terms table when migrating from ownCloud
2022-10-28T10:01:48+00:00 Updating database schema
2022-10-28T10:01:49+00:00 Exception: Database error when running migration latest for app core
2022-10-28T10:01:49+00:00 Update failed
2022-10-28T10:01:49+00:00 Maintenance mode is kept active
2022-10-28T10:01:49+00:00 Resetting log level

mariadb log

2022-10-28  6:01:49 1303 [ERROR] InnoDB: Operating system error number 17 in a file operation.
2022-10-28  6:01:49 1303 [ERROR] InnoDB: Error number 17 means 'File exists'
2022-10-28  6:01:49 1303 [Note] InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/
2022-10-28  6:01:49 1303 [Note] InnoDB: The file './nextcloud/oc_ratelimit_entries.ibd' already exists though the corresponding table did not exist in the InnoDB data dictionary. You can resolve the problem by removing the file.
2022-10-28  6:01:49 1303 [ERROR] InnoDB: Cannot create file './nextcloud/oc_ratelimit_entries.ibd'

Been fighting this concern for days and it sounds like something to do with mariadb

I have also been attempting to mysqldump the nextclound.sql db without success to import back into a different docker and get off mariadb completely

When i dump the nextcloud database I face the following concern

MySQLdump: got error :1049 :unknown database

I am not the best at mariadb CLI, so any step-by-step help would be appreciated

Any insight would be appreciated.

Thank you,

[GieltjE]

Sounds like it was incorrectly deleted before, check if ./nextcloud/oc_ratelimit_entries.ibd exists when the table doesn't.

[bombz88]

Sounds like it was incorrectly deleted before, check if ./nextcloud/oc_ratelimit_entries.ibd exists when the table doesn't.

Hello,

Thank you for your prompt response. I have been fighting with NC update using mariadb. Today I have restored(reverted) to a previous working instance so I could access my NC install again as it has been 'offline' for a good week as this update was pending but not installing.

Right now, I am leaning towards either

1. attempting to update process again which I will encounter these concerns as stated above
2. move off of mariadb container as a whole as it sounds very cumbersome to update NC using this database container

If you have suggestions I am open to anything at this point :-)

thank you,

[bombz88]

Based on how NC works with mariadb, I think I am going to move off mariadb for now being that builds of NC will always have concerns moving forward.

[nursoda]

As pointed out above, you could also migrate your tables manually using this (assembled from comments above):

Check…

mariadb --batch --skip-column-names -e 'SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," ROW_FORMAT=DYNAMIC;") from INFORMATION_SCHEMA.TABLES where TABLE_NAME like "oc\_%" AND ENGINE = "InnoDB" AND ROW_FORMAT != "Dynamic";'

…and actually change:

mariadb --batch --skip-column-names -e 'SELECT CONCAT("ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," ROW_FORMAT=DYNAMIC;") from INFORMATION_SCHEMA.TABLES where TABLE_NAME like "oc\_%" AND ENGINE = "InnoDB" AND ROW_FORMAT != "Dynamic";' | mariadb