• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Plesk Migrator - Failed to copy content of database

gustavok

New Pleskian
Failed to copy content of database 'XXXXXX'
Migration tools tried to perform operation in 3 attempts: Command execution failed on the source server 'source' (xxx.xxx.xxx.xxx) with non-zero exit code.
command: MYSQL_PWD="$(cat)" mysqldump --no-defaults -h localhost -P 3306 -uadmin --quick --quote-names --add-drop-table --default-character-set=utf8 --set-charset --routines --events xxxxxxxDB > /root/plesk_migrator/plesk_migrator-06xxxxxxxxxxxxxxxxxxxxx/db-dumps/XXXXXXXX.sql
exit code: 2
stdout:
stderr: mysqldump: Couldn't execute 'show events': Cannot proceed, because event scheduler is disabled (1577)



CentOS Linux 7.8.2003 (Core)
Plesk Obsidian
Versión 18.0.29
10.3.24-MariaDB
 
source server 'source' (xxx.xxx.xxx.xxx)
Looks like subscription has databases on a different MySQL servers and the issue on a remote MySQL server. As this configuration lies outside of current Plesk Server, contact the remote MySQL server administrator to check and resolve this issue. I believe that dump without --events option will be created successfully, like:

# mysqldump -uplesktestuser -p --host xxx.xxx.xxx.xxx database_name > plesktestbackup.sql
 
Hi, thanks for your response.
Both servers are 10.3.24-MariaDB.
How can i do the dump without --events option?
 
You can also try to enable the "event scheduler" in MariaDB (on the target source server). This can be done by running the SQL command
Code:
SET GLOBAL event_scheduler = ON;
for example from the admin level MariaDB phpMyAdmin GUI, accessible through the Tools & Settings > Database server page.

Check the "Executing Events" section of this page:
 
Last edited:
I've tried it and it doesn't work. Select one the db, I did the sql query. I tried to do the migration, and the same result ...
 
The scenario is this:

From Server A I migrated the DB to server B successfully.

Reinstall Server A.

I'm trying to migrate from Server B to Server A and it shows that error ...
 
I was probably wrong to only ask you to make the change on the target, because the error message seems to be generated by the source. So maybe you can try again setting the global on the source server, please.

If that does not lead to success you can try to stop the mariadb service on both systems, then edit the /etc/my.cnf (or whatever you have for your MariaDB database) and add the "event_scheduler=ON" directive to these two sections:

Code:
[mariadb]
event_scheduler=ON

[mysqldump]
event_scheduler=ON


Then start the database server again. It should then have the setting memorized. The "mysqldump" section might be missing in your my.cnf file. If so, simply append the file by that section.
 
exit code: 7
stdout:
stderr: mysqldump: unknown variable 'event_scheduler=ON'
I was probably wrong to only ask you to make the change on the target, because the error message seems to be generated by the source. So maybe you can try again setting the global on the source server, please.

If that does not lead to success you can try to stop the mariadb service on both systems, then edit the /etc/my.cnf (or whatever you have for your MariaDB database) and add the "event_scheduler=ON" directive to these two sections:

Code:
[mariadb]
event_scheduler=ON

[mysqldump]
event_scheduler=ON


Then start the database server again. It should then have the setting memorized. The "mysqldump" section might be missing in your my.cnf file. If so, simply append the file by that section.


Now:

exit code: 7
stdout:
stderr: mysqldump: unknown variable 'event_scheduler=ON'
 
O.k., that was an attempt. Before I posted my suggestion I had tested this here on a MariaDB 10.3 default installation with exactly that setup (including CentOS 7.8 as the OS) and it did not give me that error. I am lost why it gives you that error. Actually, it should not complain at all, even if there are settings that it might not know, these should be ignored. Anyway, what you'll need to do is to revert the configuration and then probably consult Plesk support on this.
 
O.k., that was an attempt. Before I posted my suggestion I had tested this here on a MariaDB 10.3 default installation with exactly that setup (including CentOS 7.8 as the OS) and it did not give me that error. I am lost why it gives you that error. Actually, it should not complain at all, even if there are settings that it might not know, these should be ignored. Anyway, what you'll need to do is to revert the configuration and then probably consult Plesk support on this.


Yes, it is a bit strange. Thank you very much for your help.
 
Back
Top