Thank you, received.
It looks like the main.log contains several instances of
“Error: =[31;1mError:[0m Error establishing a database connection.” which seem to be from the issues you mentioned in the thread.
Nothing points to the database import itself failing though it the connection failed part way in the process it would make sense tables are blank.
I’ll share this with our developers so they can be aware.
There are docker failed to start permission issues earlier in the log too.
This may be an instance where deleting your sites from DevKinsta, verifying the containers have been removed and attempting the import would be the best.
Exporting a copy of your DB from MyKinsta, and importing it into DevKinsta’s version of the site would likely get it running but I wouldn’t trust that everything would be 100% given the problems you’ve had creating/importing the site.
I think the initial symlink issue started a snowball of problems. I apologize for the issues you’ve run into with your site here.
If you could try to start fresh it’s the path I would recommend.
-Delete the site(s) in DevKinsta
-Uninstall DevKinsta
-Removing any remaining containers in Docker should be sufficient
-Reinstall DevKinsta
-Attempt the reimport now that any conflicting docker containers and site entries in MK have been removed, and the symlink issue resolved.
Would you be able to send your main.log file again, now that it should have the new site creation.
Looking at your database in MK, I noticed there are 8 tables with no database prefix.
Did those tables make it over into DevKinsta when the site was created?
I’m wondering if the lack of a prefix is causing the issue. It may be something that ultimately our devs will need to address, as I don’t know of a way to work around that (if its actually the cause).
I’ll add a few non-prefixed tables to my test site and see how it goes.
That’s interesting, and I can’t think of why that would be. I’ll get a report together for this.
After activating your plugins, is everything working as it should be?
I see in the main.log on line 8706 there was a syntax error reported. Parse error: syntax error, unexpected ‘}’ in /www/kinsta/public/testing/wp-content/themes/twentytwentytwo/functions.php on line 156
On your site in MyKinsta nothing looks unexpected there.
The testing directory is another site i created from scratch just now. Ignore that one.
After activating my plugins, the plugins seemed to work, just that there is no data. So all my pages did not exist, and neither does the data that was in the plugins.
After talking with our devs, I found a little more information about the overall process and what could be going wrong.
Before syncing files (where your main.log was partially started during the rsync) a database dump is created from the remote DB.
After the files are synced, the DB import is attempted locally. Checking your log that happens at:
“[2022-04-08 17:00:55.570] [info] [importBackupToDb] Import db”
Unfortunately, it’s not a verbose log entry and just says it happens, though from the timestamps, it is not taking much time at all. ~5 seconds if I’m reading it correctly.
There do not appear to be any import errors in the log.
Could you check in your local files for a “backup.sql” file. This is the DB dump that is used and should be located in your pull sites main directory.
If it’s there, I could help you manually import it and check for any errors during that process, which is where I think something is going wrong.
It could be a malformed join, stored procedure, or another minor syntax/charset/collation error causing the entire failure.
If the backup.sql file doesn’t exist, there would appear to be a problem actually creating the database dump.
In that case, we could try to manually dump the database from your MyKinsta environment and check for errors on that side to explain why the backup.sql doesn’t exist.
Interesting it’s not there. Even on my successful import the backup.sql file remains in place.
To generate a SQL dump, first SSH into your site here in MyKinsta using the SSH/SFTP details from your Info page of the site.
To do this, you’ll need an SSH client or use WSL. https://kinsta.com/help/connect-to-ssh/
Once you’re logged in, use the Database details from the Info tab. mysqldump -p -u USERNAME DATABASENAME > ~/private/backup.sql
This should run for a minute or two (your DB isn’t too large), and place the exported file in your users private directory.
If any errors are found they will be displayed on the screen during the mysqldump process running.
If you prefer I can also attempt the export in the same way, just let me know the environment (live/staging) you’ve been trying to import to DevKinsta.
Our support team can also help you get connected with SSH if you run into issues, just open a chat!
Correct, nothing will change by running that command beyond generating a new file in that non web-accessible directory.
It’s exporting/backing up your database, not actually dropping tables from it in the process.
You can create a backup in MyKinsta -> sitename -> Backups -> Manual instantly if you have any worries though.
It’s essentially the same as what we run to generate the backup.sql from our end, and the same as using the Export option in PHPMyAdmin only more verbose.
Note: It won’t move the database to your local machine, only the ~/private directory of the MyKinsta environment.
I exported the backup I believe (there was no indication of completion from the terminal). I waiting for 5 minutes so I guess it should have completed.
However I do not see any back.sql file in my user directory.
Checking your files from the site in MyKinsta, I see the backup.sql file was generated. The size of that file it does indicate its complete.
It will be in the private directory. Over SSH: ls -lha ~/private/
I’ll share with our devs that no errors were seen during the manual export.
If you connect to the site using SFTP, this file will be available for you to download. You can store it on your local machine, then attempt to import it manually to DevKinsta.
To import open your site in DevKinsta and click Database manager (where you saw the empty tables).
-Select all Tables using the top left check box.
-Scroll to the bottom and click the blue DROP button → Confirm Yes.
This will clear the empty tables and get things ready for the import.
Now with a clean database, you can try to import it manually.
-In the top left there will be an import option.
-Click the File Upload → Choose Files button and locate the backup.sql you downloaded.
-Click Execute.
This will output any errors and stop if there is one. Given the successful export you performed, I’m hoping there will be none.
That brings us back to the initial issue of the import failing during the automatic process, though, which we’re trying to identify now.
The fact that up to this point, nothing appears to have failed is strange. If manually importing it using the steps above works, even more so.
Give this a try and let me know if you see errors or have any trouble.