Guide Import a Large SQL File in CyberPanel Over SSH (phpMyAdmin Stops at 2 MB)

Guide Import a Large SQL File in CyberPanel Over SSH (phpMyAdmin Stops at 2 MB) - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel)
+---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials)
+----- Forum: CyberPanel Databases & phpMyAdmin Guides (https://adminsforum.com/Forum-cyberpanel-databases-phpmyadmin-guides)
+----- Thread: Guide Import a Large SQL File in CyberPanel Over SSH (phpMyAdmin Stops at 2 MB) (/Thread-guide-import-a-large-sql-file-in-cyberpanel-over-ssh-phpmyadmin-stops-at-2-mb)

Import a Large SQL File in CyberPanel Over SSH (phpMyAdmin Stops at 2 MB) - JAY - 10-27-2026

Import a Large SQL File in CyberPanel Over SSH (phpMyAdmin Stops at 2 MB)

You moved a site to CyberPanel, open phpMyAdmin, click Import, and the limit next to the file field says (Max: 2,048KiB). That's 2 MB, so almost any real database is too big, even zipped. You could raise PHP's limits, but there's a faster and more reliable way: import over SSH. We tested it on our lab server (CyberPanel 3.0, MariaDB 10.11, Ubuntu 24.04) with a 241 MB dump, and on purpose ran into the five errors people hit most, with the fix for each.

phpMyAdmin's Import page on a default CyberPanel server:
[Image: attachment.php?aid=610]

Why 2 MB, and why we don't just raise it
CyberPanel's phpMyAdmin runs on the panel's own PHP, but it reads the same php.ini as your PHP 8.3 websites:

Code:

/usr/local/lsws/lsphp83/etc/php/8.3/litespeed/php.ini

on our server (

Code:

upload_max_filesize = 2M

Code:

post_max_size = 8M

). Raising it there raises it for every PHP 8.3 site too, and big imports through a browser still run into PHP timeouts. SSH has none of these limits.

Step 1: Create the empty database
In CyberPanel: Databases > Create Database, pick the website, enter a database name, user and password. Write down the exact database and user names as List Databases shows them, in case a prefix was added. Ours: database

Code:

cyber_imp

, user

Code:

cyber_imp

.

Step 2: Get the dump onto the server
Upload the

Code:

.sql

Code:

.sql.gz

file over SFTP to the website's home folder (for example

Code:

/home/example.com/

), or from your PC:

Code:

scp shop.sql.gz root@YOUR-SERVER-IP:/root/imp/

Keep it compressed. Our dump was 241 MB as plain SQL and 19 MB as

Code:

.gz

, and you never have to unpack it on the server. Don't leave dumps inside

Code:

public_html

, where anyone could download them.

Step 3: Import
The simple way, it asks for the database user's password:

Code:

gunzip < shop.sql.gz | mysql -u cyber_imp -p cyber_imp

For a plain

Code:

.sql

file:

Code:

mysql -u cyber_imp -p cyber_imp < shop.sql

.

What we used, with a progress bar and the password kept out of the command line and history:

Code:

printf '[client]\nuser=cyber_imp\npassword=YOUR-DB-PASSWORD\n' > /root/.imp.cnf
chmod 600 /root/.imp.cnf
pv shop.sql.gz | gunzip | mysql --defaults-file=/root/.imp.cnf cyber_imp

(

Code:

pv

was already installed on our server; if not:

Code:

apt install pv

.)
Our 241 MB test import:
[Image: attachment.php?aid=611]

241 MB, 1.5 million rows, 23 seconds. For really big imports run it inside

Code:

screen

Code:

tmux

, so a dropped SSH connection doesn't kill it halfway. Delete

Code:

/root/.imp.cnf

when you're done.

Why the database user and not root? Importing as the site's own user shows the problems your site would also have later (missing rights, wrong database names) and can't touch other databases by mistake. One more catch: on CyberPanel root has its own

Code:

/root/.my.cnf

. With

Code:

--defaults-extra-file

that file is still read and quietly logged us in as root;

Code:

--defaults-file

(as above) uses only your file.

Error 1: "ERROR 2006 (HY000): Server has gone away"
The dump contains a single row bigger than the server allows (images or files stored in the database, big serialized options). MariaDB's default

Code:

max_allowed_packet

is 16 MB; our test row was 20 MB. Raising the limit only on the client side did not help, the server has to allow it too:
Server has gone away, and the fix:
[Image: attachment.php?aid=613]

To test quickly,

Code:

SET GLOBAL max_allowed_packet=268435456

(256 MB) works until the next MariaDB restart. To make it permanent, add a small config file and restart:

Code:

printf '[mysqld]\nmax_allowed_packet = 256M\n' > /etc/mysql/mariadb.conf.d/60-import.cnf
systemctl restart mariadb
mysql -N -e 'SELECT @@max_allowed_packet'

Keep

Code:

--max_allowed_packet=256M

on the import command as well, because the

Code:

mysql

client has its own limit.

Error 2: "Unknown collation: utf8mb4_0900_ai_ci"
The dump comes from MySQL 8, CyberPanel runs MariaDB. Our MariaDB 10.11.19 didn't know MySQL 8's default collation. Replace it with one MariaDB has, in the file, before importing:

Code:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_520_ci/g' shop.sql

For a

Code:

.gz

Code:

gunzip < shop.sql.gz | sed 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_520_ci/g' | mysql ...

Making it permanent, then the collation error and its fix:
[Image: attachment.php?aid=614]

Error 3: "Access denied; you need (at least one of) the SUPER, SET USER privilege(s)"
The dump has views, triggers or procedures with

Code:

DEFINER=`olduser`@`localhost`

, a user from the old server. Only root may create objects for another user. Remove the DEFINER parts; the objects then belong to the user who imports them:

Code:

sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' shop.sql > shop-fixed.sql

The DEFINER error and the fix:
[Image: attachment.php?aid=612]

Error 4: "Access denied for user ... to database 'oldshop'"
Some dumps start with

Code:

CREATE DATABASE

and

Code:

USE `oldshop`

. Then the import tries to create or switch to the old database name, and your CyberPanel user isn't allowed there. Check the top of the file with

Code:

head

, then delete those lines:

Code:

sed -i -E '/^(CREATE DATABASE|USE) /d' shop.sql

A dump with its own CREATE DATABASE and USE lines:
[Image: attachment.php?aid=615]

Error 5: "Table ... already exists"
A failed import stops halfway and leaves the tables it already created. Run it again and it fails on the first one. Start over with an empty database: drop and re-create it in Databases, or drop the leftover tables in phpMyAdmin, then import again.

After the import

Count rows in a big table and compare with the old server:
Code:
mysql -u USER -p -e 'SELECT COUNT(*) FROM wp_posts' DBNAME
Put the new database name, user and password in your app's config (
Code:
wp-config.php
,
Code:
.env
).
Delete the dump and
Code:
/root/.imp.cnf
from the server.
If you added
Code:
60-import.cnf
only for this import, you can keep it: 256 MB is a normal value. Delete it and restart MariaDB if you prefer the default.

More CyberPanel guides

Tested on CyberPanel 3.0 with MariaDB 10.11.19 and phpMyAdmin 5.2.1 on Ubuntu 24.04, October 2026. Error texts are copied from our terminal; MySQL instead of MariaDB words some of them a little differently.