When cloning a site to my local DevKinsta, I was getting “Can’t create MySQL dump - DK0029” error. So, after finding this thread, I contacted Kinsta support, they increased the max_allowed_packet and the server could create the dump correctly, allowing me to download the site.
But now DevKinsta is not handling the downloaded DB dump with a different error : Failed to import database dump - DK0066. After looking the logs, I couldn’t find a topic with the same error I’m getting: Got a packet bigger than ‘max_allowed_packet’ bytes.
I’ve also tried to manually import the database, but it didn’t work either, with the same error message.
So now I’m trying to figure out how to increase the max_allowed_packet on my DevKinsta (probably directly on Docker) to import the database and, after researching a lot, I couldn’t figure it out yet.
We regret to inform you that the Pull Devkinsta action is currently not working for pulling a new Kinsta site that uses the specific Mysql/MariaDB mysqldump - MariaDB dump 10.19 Distrib 10.11.8-MariaDB - version. Our developers have been notified, and you can follow the thread below for updates on this issue: DK0066: IMPORT_DB_DUMP: Error (1): (ERROR at line 1: Unknown command '\-' - #11
One workaround would be to create a downloadable backup of your site in MyKinsta. The backup will contain both your site’s WordPress files and its database data.
After that, in DevKinsta, you can create an empty site (Custom Site >> Empty site) and manually import both the files and the database from the downloadable backup. You can use WP CLI or the built-in Database manager to import the database (.sql file).
However, please remember to delete the first line in the SQL file before performing the database import.
Finally, you can run a search and replace using WP CLI to update the site’s URL from the live site domain to the Devkinsta domain assigned to it.
Actually, it might be easier to just use the DevKinsta Add new site >> Custom Site >> Import from Backup option with the zip file exported from Kinsta using the downloadable backup option.
But before importing the zip file, you will need to extract it on your local machine and edit the .sql file to remove the problematic line mentioned on my previous reply. Then create a new zip file for both the WP files and the edited sql file. Then finally do the Import from Backup in DevKinsta.
but, although it has the same error code DK0066, this “Unknown command” is not the error I’m getting. As I said, I tried to manually import the database on an empty WP site, using exactly the steps @Adrian_L shared on his last message and it didn’t work.
When running WP CLI wp db import backup.sql I got the error “Got a packet bigger than ‘max_allowed_packet’ bytes” - it’s the same error message I’m getting when pulling the entire site from the Kinsta.
I think my issue will be resolved if I can simply increase the max_allowed_packet on Docker, but I couldn’t figure out how to do it.
If you’re able to open the MariaDB Docker container, the /etc/mysql/mariadb.conf.d/50-server.cnf file should have a line similar to this:
#max_allowed_packet = 1G
Un-commenting that line by removing the # symbol should allow the database to use the higher value. However if the container is deleted or recreated, the configuration change will be lost.
Uncommenting that line solved my issue and I was able to successfully clone my site.
For those passing by, those were the steps I took:
Open Docker Dashboard
Look for the DB container, named devkinsta_db
Click on the three dots “Show container actions” and choose “Open in terminal”
Once in the terminal,. I needed to install vim to edit the file. For this, I ran:
apt-get update
apt-get install vim
And to open the vim editor:
vim /etc/mysql/mariadb,conf.d/50-server.cnf
If you are not familiarized with vim, you might face some difficulties. Start by locating this row #row_allowed_packet = 1G, once your cursor is on it, press the “a” key on the keyboard to enter on the edit mode. Erase the # and press esc to quit the edit mode. Then type :wq and presse Enter. (w is for saving the file, q is for quiting vim). Pay attention to not save this file if you erase or overwrite anything than the #.
After that, get back to the Docker dashboard and restart your DB container.
,