Request for permanent fix for DevKinsta pull/import compatibility on this site

DevKinsta Bug Reports
1

Q: Date/Time this occurred (Provide your time zone also)
A: March 27, 2026, approximately 4:14 PM (America/Mexico_City)

Q: DevKinsta Version
A: 2.13.6.9094

Q: OS Version
A: Windows 11 Pro

Q: Docker Desktop Version
A: 4.29

Q: Were any error codes or messages observed? If so, what were they?
A: Yes. During the automatic backup.sql import step in DevKinsta, I observed these errors:

  1. First error:
    ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'

  2. After manually patching the SQL file during the short import window, the next error became:
    ERROR 1062 (23000) at line 113732: Duplicate entry '\xEF\xBF\xBD\xEF\xBF\xBD\xEF\xBF\xBD\xEF\xBF\xBD\xEF\xBF\xBD\xEF' for key 'PRIMARY'

DevKinsta also reported:
DK0066: IMPORT_DB_DUMP: Error (1)

Q: Detailed Description of the Problem
A: I am trying to clone a site from Kinsta into DevKinsta using the standard pull workflow.

My local environment is:

  • DevKinsta 2.13.6.9094

  • Docker Desktop 4.29

  • local DevKinsta DB container running MariaDB 10.5.17

The downloaded SQL dump shows it was generated from:

  • MariaDB 11.4.7

The import fails during the automatic backup.sql import step.

The first failure was caused by an unsupported collation:

  • utf8mb4_0900_ai_ci

I managed to intercept the downloaded backup.sql during the short time window before the import failed, and I manually patched:

  • the MariaDB 11 sandbox comment at the top of the file

  • utf8mb4_0900_ai_ci → utf8mb4_unicode_520_ci

That allowed the import to progress further, so the collation issue appears to be real and confirmed.

However, after that, the import failed again on a different section of the dump. I found that the file contains binary-sensitive INSERT data, especially in table wp_pmxi_hash, where:

  • hash is binary(16)

  • the table uses PRIMARY KEY (hash)

  • the INSERT rows contain raw binary-looking values

After editing/saving the file, the import later failed with a duplicate primary key error, which suggests the raw binary data may be getting corrupted if the dump is manually modified or saved.

So the core issue seems to be a compatibility problem between:

  • the source dump generated from MariaDB 11.4.7

  • and the local DevKinsta MariaDB 10.5.17 import target

At the moment, this means the site cannot be reliably pulled into DevKinsta using the normal automated workflow without manual intervention during the import window, and that manual intervention is risky because the dump contains binary-sensitive data.

What I need is a permanent, supported fix so any team member can pull this site into DevKinsta without having to manually patch the SQL file during import.

3

Hi @Luis_Pinillo,

Welcome to the Kinsta Community!

I’m sorry to hear that you’re experiencing issues with our DevKinsta app. I’ve forwarded your feedback to our DevKinsta development team for their review. Unfortunately, I can’t provide a specific timeframe for when we might update the MariaDB version on DevKinsta to match the version used on your Kinsta sites.

In the meantime, I can only recommend running a search and replace for any unsupported entries, for example, utf8mb4_0900_ai_ci to utf8mb4_unicode_520_ci, in the database of your source Kinsta site before executing the Pull action.

If you have any further questions or need clarification, please let me know.