Issue Plesk Migrator - Obsidian 18.0.56 - Errors / unable to migrate

[kassi]

Server operating system version

Ubuntu 22.04

Plesk version and microupdate number

18.0.56

The new server has 18.0.56 installed and I needed to upgrade from .55 to .56 on the old server as well.

When starting a migration (4 subscriptions) I'm receiving errors without meaningful messages.
All 4 subscriptions failed. Looking at the protocol, I see

Execute command: check

Execute command: check
  Check InnoDB strict mode on source and target MySQL/MariaDB servers to prevent databases transfer failure.
  Failed to check MySQL InnoDB strict mode.
  (no more info provided)
 
Execute command: transfer-accounts
  Process subscription xyz.de
    START: Deploy subscription
      Failed to deploy subscription 'xyz.de'. Try to repeat operation once more.
       Failed to deploy subscription 'xyz.de'. Try to repeat operation once more.
      Failed to perform an action on subscription 'xyz.de': Failed to deploy subscription 'xyz.de'
Migration for that subscription is considered completely failed. No further actions are performed for it. Exception message: Migration tools tried to perform operation in 3 attempts: Unable to create subscription 'xyz.de'.
Subscription already exists on target server: most probably it was created at the previous attempt,
but migration tools are not sure if it was created correctly.
It is recommended to:
1) Resolve the original issue that caused subscription creation to fail,
delete subscription, and then run migration again.
OR
2) Ensure that created subscription is fine, or the original issue is minor,
then simply run migration for that subscription again.

I added the
innodb_strict_mode=OFF to my.cnf (target server), but the error still exists. It actually means that it can't figure out which mode it's in.

As for the subscription errors: I'm receiving the same messages for all 4 subscriptions.
The first two attempts fail, but don't give a message why they fail.
The third attempt then simply tells me: subscription already exists.
I guess the first attempt creates the subscription but fails afterwards, without telling me why. Second and third attempt then fail due to already existing entry in subscriptions.
Before migration there was no subscription. I actually removed all with

plesk bin subscription -l | xargs -L 1 plesk bin -r

Any idea on how to get around this?

Is there any possibility to fetch the actual hosting-description from somewhere after starting a migration in the panel migrator?

If I need to re-create subscriptions manually: what's the best way to get all data and files back on the correct place from the old server?

Thanks
Kassi

 

[Peter Debik]

Maybe strict mode is on on the source server and you need to turn it on on the target server, too?

 

[kassi]

Thanks for stepping in for the first problem: (MySQL strict mode)

This was not it.
I found the debug.log of the migration in /usr/local/psa/var/modules/panel-migrator/sessions/migration-session
It's getting

+|2023-10-16_16:11:31,999|I|MT|core.workflow.runner.by_subscription|||Check InnoDB strict mode on source and target MySQL/MariaDB servers to prevent databases transfer failure.
+|2023-10-16_16:11:32,000|D|MT|core.runners.base|||Execute command on the source server 'source' (aa.bb.cc.dd): mysql -h localhost -P 3306 -uadmin -p'***hidden***' --silent --skip-column-names -e 'SHOW VARIABLES LIKE '"'"'innodb_strict_mode'"'"''
+|2023-10-16_16:11:32,336|D|MT|core.runners.base|||Command execution results:
=|2023-10-16_16:11:32,336|D|MT|core.runners.base|||stdout:
=|2023-10-16_16:11:32,336|D|MT|core.runners.base|||stderr: WARNING: Forcing protocol to  TCP  due to option specification. Please explicitly state intended protocol.
=|2023-10-16_16:11:32,336|D|MT|core.runners.base|||ERROR 1045 (28000): Access denied for user 'admin'@'localhost' (using password: YES)
=|2023-10-16_16:11:32,336|D|MT|core.runners.base|||
=|2023-10-16_16:11:32,336|D|MT|core.runners.base|||exit code: 1

Running the following on the source server as root however works:

mysql -h localhost -P 3306 -uadmin -p"$(cat /etc/psa/.psa.shadow)" --silent --skip-column-names -e 'SHOW VARIABLES LIKE '"'"'innodb_strict_mode'"'"''

Does the target server use the wrong password when trying to run mysql statements on the source server?

 

[Peter Debik]

There is a known issue when you try to resync a database, that could apply to your case. You could try to modify string 450 of /usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/utils/database_utils.py in text editor:

from
if server.host == 'localhost' and server.port() == 3306:
to
if server.host() == 'localhost' and server.port() == 3306:

If this does not work, please contact the Plesk support team for further assistance at https://support.plesk.com

 

[salvis]

Thank you, Peter!

Actually, the parentheses are missing not just on host, but also on port.

I fixed this, but it doesn't seem to make any difference in my Plesk-to-Plesk Linux-to-Linux pre-migration check. I get this in the log file:

Exception: Traceback (most recent call last): File "/usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/workflow/runner/by_subscription.py", line 167, in run_multi_attempts run() File "/usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/workflow/runner/by_subscription.py", line 156, in run action.run(self._context) File "/usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/actions/hosting_settings/check/mysql_innodb_strict_mode.py", line 70, in run if not is_mysql_innodb_strict_mode(source_database_server): File "/usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/utils/database_utils.py", line 1977, in is_mysql_innodb_strict_mode innodb_strict_mode = get_mysql_variable(server, 'innodb_strict_mode') File "/usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/utils/database_utils.py", line 2025, in get_mysql_variable query_result = runner.execute_command(command, args).stdout File "/usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/runners/base.py", line 125, in execute_command execution_options.log_output, output_encoding File "/usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/core/runners/base.py", line 162, in _check_exit_code exit_code=exit_code NonZeroExitCodeException: Command execution failed on the source server 'source' (176.###.###.###) with non-zero exit code. command: mysql -h localhost -P 3306 -uadmin -p'***hidden***' --silent --skip-column-names -e 'SHOW VARIABLES LIKE '"'"'innodb_strict_mode'"'"'' exit code: 1 stdout: stderr: ERROR 1045 (28000): Access denied for user 'admin'@'localhost' (using password: YES)
The error is in the get_mysql_variable() function, where we're getting the Windows version of the query, because the condition in

if server.is_windows:
on line 2007 seems to be TRUE because it's also missing the parentheses on is_windows.

After adding the parentheses, my pre-migration check passes flawlessly, and I think the chances are good that the error in the check has not affected my prior migrations. Still, it would be nice to get this fixed... ;-)

(I know many programming languages, but not Python, but the fact that the language accepts the constant server.is_windows as TRUE while the result of the function call server.is_windows() would be FALSE (an actual boolean value), and this programming error goes undetected, is a serious flaw in the design of the language, as evidenced here!)