• Resolved Roger Holman

    (@flight750)


    This host has had this EOL DB server for a long time, I called them about it a long time ago, they tell me that they are aware it is an EOL DB server and will be updating, but their (offshore) tech support cannot say when… Perhaps it goes without saying, but I am looking to bail on this lackluster host ASAP!

    I have been testing (DB only) migration to Ubuntu 20.04.5 LTS running MySQL 8.0.32 (test server in my office) and it finishes, logs say there are no errors, but it takes 2.5 hours (FWIW, dup-database_.sql file is ~131mb) and the message that Duplicator provides seems to read the issue backwards (implies that the source host has a newer MySQL):

    Character Set and Collation Capability

    STATUS
    character set and collation isn’t supported on current database. “Legacy Character set” and “Legacy Collation” will be replaced with default values.

    DETAILS
    Character set list
    utf8mb4 Pass
    latin1 Pass
    utf8 Fail

    Collations list
    ascii_general_ci Pass
    latin1_swedish_ci Pass
    utf8_general_ci Fail
    utf8mb4_unicode_520_ci Pass

    The database where the package was created has a character set and collation that is not supported on this server. This issue happens when a site is moved from an newer version of MySQL to a older version of MySQL. The recommended fix is to update MySQL on this server to support the character set that is failing below. If this is not an option for your host, then you can continue the installation. Invalid values will be replaced with the default values. For more details …

    So my primary questions are:

    1) How might I best validate the migration really worked (I can live with one final multi-hour migration)
    2) What can I do to help your team get the right info for the error message?

    Thanks in advance!

    • This topic was modified 2 years, 1 month ago by Roger Holman.
Viewing 1 replies (of 1 total)
  • Plugin Support devdavidam

    (@devdavidam)

    @flight750 It’s ok to see this message. Most of the time, replacing the not supported charset and collations with the default values is working fine.

    I think, if you want to make sure that the migration really worked, the only way is to run a test installation and just test the results.

Viewing 1 replies (of 1 total)
  • The topic ‘EOL Percona (5.6.49-89.0) to MySQL 8.0.32/takes 2.5 hrs & result misleading’ is closed to new replies.