• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Migration BUG!!! Corrupt Characters

D

dalumpi2

Guest
Hi SWSOFT. I'm really satisfied with your software, but I did a migration from one server to my new one.

The Old server (SOURCE) is Plesk 8.01
The New server (DESTINATION), 8.2


Now all was going fine, but in the websites on my new server some symbols are corrupt:

Example:

On my Old Server the word was correctly:
  • Gästebuch
  • Schlüsselanhänger
  • Frühjahr
  • Räucherstäbchen
  • Wanderstöcke
    [/list=a]

    Now it becomes:
    • Gästebuch
    • SchlÃŒsselanhÀnger
    • FrÃŒhjahr
    • RÀucherstÀbchen
    • Wanderstöcke
      [/list=a]

      So there is a problem with:
      1. ü
      2. ö
      3. ä
        [/list=a]

        What can I do? Can anyone help me or give me a SQL - Replace Script? I think that would work.
 
Problem with char set

Migration manager seems to dump the DB with the following command
/usr/bin/mysqldump -h 'localhost' -u 'admin' -p'****' -P '3306' --quick --quote-names --add-drop-table --compatible=mysql323 --default-character-set=utf8 --set-charset 'db_name'

I assume the last part '--default-character-set=utf8' is responsible for what you see now.

Anyway I know lots of people (including myself) who cannot migrate from 8.2 to another 8.2 server. We always get the same error 'Field contains improper value'. SWSOFT doesnt seem to care at all.
 
I simply removed the <<<--default-charset=utf8>>> parameter, on that file (/usr/local/psa/PMM/agents/shared/Db/MysqlShellBackend.pm, at the server witch calls the migration, that is, destination server), and now migration manager is working just perfect. Hope that helps anyone.
 
an another solution was to move the /var/lib/mysql/ directories as a tar.gz and untar it on new server :)
 
Back
Top