mariadb docker fails to Initialize database contents from dump file

Question

I have a Nextcloud server set up that uses docker image mariadb:10.11. I use mysqldump to back up the database. Where I am having trouble is trying to restore that to a test system as described here https://hub.docker.com/_/mariadb#initializing-the-database-contents.

For the restore I added the extra service "adminer" so I could check it out. I also added a new volume to mount the dump file - /data/blue/nextcloud/db_backup/db_dump_nextcloud.sql:/docker-entrypoint-initdb.d/db_dump_nextcloud.sql.

I then started it with docker-compose up -d adminer. On the first try I saw that there were 52 (I think) tables in the nextcloud database so I thought we was good, but when starting nextcloud it was giving me errors about missing tables.

A few days later I got around to trying it again and now it only gets part of one table downloaded. The last time or two I tested by deleting the database volume and then just start the database with docker-compose up db. I think in the logs I am seeing the data be dumped into one of the tables and then the Lost connection error:

...
db-1 | ('3507453_0','3507453_0',1,3507453,'�0円0円0円0円0円0円0円0円;0円0円0円 c�ZB�J@K�4�T@ �c�J@�]K��T@�>W[��J@�H�}�T@��k ��J@�A�f�T@33333�J@?�ܵ��T@�1��%�J@z�):��T@���<,�J@;pΈ��T@1�*▒��J@�,C��T@/�$��J@��b��T@����J@����M�T@��ڊ��J@b��4��T@+�٦J@�ZӼ��T@|a2U�J@�Q�@��{���J@�9#J{�T@�HP��J@��g���T@4��7��J@�x�&1�T@�����J@��k ��T@�C�l��J@�c�]K�T@gDio��J@2U0*��T@-C���J@_�Q�T@d�]KȯJ@��|г�T@ףp=\n�J@M��St�T@�3���J@�a2�T@-����J@�N@a�T@Ԛ���J@��C�l�T@Gr���J@K�=�U@P�▒sײJ@���oU@\'�W�J@�HPU@6<�R��J@�;NU@���{��J@�E��U@������J@k+���U@�2ı.�J@ޓ��ZU@�A�f�J@�p=\n�U@���ZӬJ@ףp=\nU@�rh���J@��C�lU@ݵ�|ЫJ@�c]�FU@��C��J@�ܵ�|U@�$���J@$(~��U@� ��J@Gr��U@���~��J@▒&S�U@�d�`T�J@t���U@�o_ΩJ@\\���(U@�&S�J@8��d�U@▒&S��J@=\nףpU@�W�2ĩJ@���QIU@S��:�J@���<,U@ףp=\n�J@S�!�uU@���H�J@S�!�uU@�٬�\\�J@?�ܵU@�e�c]�J@
 +�U�Zd�J@��|?5U@�z�G�J@A�c�]�T@�HP��J@:#J{��T@�����J@F�����T@����J@?5^�I�T@�����J@�K7�A�T@��DؠJ@$�����T@x
 $(�J@-!�l�T@ c�ZB�J@K�4�T@')
db-1 | --------------
db-1 | 
db-1 | ERROR 2013 (HY000) at line 316271: Lost connection to server during query
db-1 | /usr/local/bin/docker-entrypoint.sh: line 298: 88 Segmentation fault (core dumped) "$@" --skip-networking --default-time-zone=SYSTEM --socket="${SOCKET}" --wsrep_on=OFF --expire-logs-days=0 --skip-slave-start --loose-innodb_buffer_pool_load_at_startup=0
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Last binlog file './binlog.000001', position 272159596
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: 128 rollback segments are active.
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Rollback of non-prepared transactions completed
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: log sequence number 206149883; transaction id 298
db-1 | 2025年07月22日 2:31:34 0 [Note] Plugin 'FEEDBACK' is disabled.
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Cannot open '/var/lib/mysql/ib_buffer_pool' for reading: No such file or directory
db-1 | 2025年07月22日 2:31:34 0 [Note] Recovering after a crash using binlog
db-1 | 2025年07月22日 2:31:34 0 [Note] Starting table crash recovery...
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Starting recovery for XA transactions...
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Transaction 295 in prepared state after recovery
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: Transaction contains changes to 3086 rows
db-1 | 2025年07月22日 2:31:34 0 [Note] InnoDB: 1 transactions in prepared state after recovery
db-1 | 2025年07月22日 2:31:34 0 [Note] Found 1 prepared transaction(s) in InnoDB
db-1 | 2025年07月22日 2:31:34 0 [Note] Crash table recovery finished.
db-1 | 2025年07月22日 2:31:34 0 [Note] Server socket created on IP: '0.0.0.0'.
db-1 | 2025年07月22日 2:31:34 0 [Note] Server socket created on IP: '::'.
db-1 | 2025年07月22日 2:31:34 0 [Note] mariadbd: ready for connections.
db-1 | Version: '10.11.13-MariaDB-ubu2204-log' socket: '/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution
w Enable Watch

The relevant part of my compose file is as follows. The db service is set up the same as on the source container except the new volume.

services:
 adminer:
 image: adminer
 restart: always
 ports:
 - 8080:8080
 depends_on:
 - db
 db:
 image: mariadb:10.11
 command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW --log_bin_trust_function_creators=1
 restart: always
 volumes:
 - db:/var/lib/mysql
 # For mysqldump conf file for backups.
 - /home/monterey/confg/restic/db-env.cnf:/app/db-env.cnf:ro
 - /data/blue/nextcloud/db_backup/db_dump_nextcloud.sql:/docker-entrypoint-initdb.d/db_dump_nextcloud.sql
 environment:
 - MARIADB_AUTO_UPGRADE=1
 - MARIADB_DISABLE_UPGRADE_BACKUP=1
 env_file:
 - db.env
 redis:
 image: redis:alpine
 restart: always
 app:
 #image: nextcloud:apache
 build: ./nextcloud
 restart: always
 volumes:
...

Edit - I did a --no-data dump and was able to restore that. It gave me a 195 tables and took a little over a minute. I did not see it dumping out ever line of sql so I wonder if when it was doing that before it was trying to say there was an error.

• AlexD: That BLOB looks suspicious.
• danblack: The "Segment Fault" indicates that MariaDB has crashed during the insert. If you can kindly provide a bug report, and if you are willing, a privately shared copy of the sql file, potentially minimised to the rows around the output and table structures that are relevant.
• JohnT: @danblack I will do some more testing and see about making a bug report. The link above takes me to jira. Is that where I should submit a bug? Do I need to set up an account there to submit a bug? Would github work? I think I already have an account there.
• danblack: yes, JIRA is for a bug reports. There isn't a github login for bug report. You could create a new general topic on mariadb.zulipchat.com related to your bug with a github login. And eventually someone (probably me) will make a bug report out of it.
• JohnT: I finally got the bug report made. jira.mariadb.org/browse/MDEV-37418

Answer 1

Since you are using mysqldump, many things can work against you.

max_allowed_packet : This governs the maximum size a MySQL packet is allowed to grow. Since you are using docker, this could bottleneck a mysqldump with the extended insert format from loading.

--extended-insert : This causes the dump to group hundreds or even thousands of rows to be inserted from a single INSERT command.

Docker may not be able to withstand the pressure of doing multirow inserts.

If you do not want to change the container configuration in any way, I would highly recommend recreate the mysqldump using --skip-extended-insert or skip-opt. This will cause mysqldump to have each INSERT command insert just one row. While this will significantly bloat the mysqldump filesize, the mysqldump will be able to be loaded into MariaDB without consuming the limited OS settings in Docker. It may take longer than usual to load.

• JohnT: Thanks for your reply. My dump commmand looks something like this docker exec nextcloud-db-1 mysqldump --defaults-extra-file=/app/db-env.cnf --single-transaction --host=localhost nextcloud > db_dump_nextcloud.sql. What would be your suggestions for changes to the container configuration that might help?
• JohnT: I am running a test using the --skip-extended-insert option on the dump. It did not take supper long to make the dump, but the restore is either frozen or taking a long time. (I think we are at over 5 hours now)
• JohnT: Would I set max_allowed_packet in the command part of the docker compose file? Would that perhaps allow me to use the original dump and be a little faster?
• JohnT: I was able to restore the backup made with --skip-extended-insert. It took about 23 hours to restore. The dump was about 1.1 GB. @RolandoMySQLDBA I want to find a faster way to do a restore. I will try changing max_allowed_packet. Is there anything else I can try to make it faster? Thanks