• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • Support for BIND DNS has been removed from Plesk for Windows due to security and maintenance risks.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS.

WARNING to those relying on pleskbackup for MySQL <= 4.1.20 RHEL4 or <= 5.0.22 RHEL5!

Hi

I made a backup with plesk backup interface. After restoring, I have the same auto_increment problems with mysql 4.1.20.

What can I do ?

thanks
 
Originally posted by opensia
Hi

I made a backup with plesk backup interface. After restoring, I have the same auto_increment problems with mysql 4.1.20.

What can I do ?

thanks

If you have the original schema, then you can just dump your data only, replace the schema, and insert your data.

If you don't have the original schema, unfortunately your only option is to re-create the indexes by hand.
 
I tried to change auto_increment value by hand using

ALTER TABLE tbl AUTO_INCREMENT = 100;

but it doesn't change anything ?
 
Originally posted by opensia
I tried to change auto_increment value by hand using

ALTER TABLE tbl AUTO_INCREMENT = 100;

but it doesn't change anything ?

In answer to your query, not only are the auto increment values lost, but the field is no longer marked auto_increment.

You need to set the field as auto_increment, then set the auto_increment value (you may be able to do it in the same query, but I'm not 100% sure on that).
 
Surely there is a default auto_increment value (e.g. 1) so all you need to do is set auto_increment on?

I'm half asleep so I'm probably wrong.


Faris.
 
You just have to alter the table to add the auto_increment flag. You can do this with the ALTER TABLE `table` CHANGE `column` ...; syntax. The next time a record is updated it will grab the next highest value for that column and then auto set the next auto_increment value.

If you want to specify a specific auto_increment value to jump to for the next insert, that is when you'd use ALTER TABLE `table` AUTO_INCREMENT = #; For instance when you get checks from your bank they generally start at 100 and when you re-order they ask where you'd like the next check number to start at.
 
Ah. Good. I'm glad I wasn't going mad. Thanks!

Incidentally just in case it helps someone, when you make the modification to the script in migration manager you should be doing it on the system that you are migrating to (the one in charge of the migration if you like), not the one you are migrating from.

Also, when migrating, if you migrate a domain (with a database) that is switched off (disabled) on the source host system, although the database and database user will be migrated to the destination system database access will not be allowed to the user on the destination system even when switched back on. At least in my experience. I'm not sure why this is the case or if it was just something that happened in my particular circumstances but it is something to look out for (and easily resolved) if you get mysterious problems after migrating.

Faris.
 
Incidentally just in case it helps someone, when you make the modification to the script in migration manager you should be doing it on the system that you are migrating to (the one in charge of the migration if you like), not the one you are migrating from.

I think this is only correct for the migration manager due to the way it communicates. If you are using pleskbackup you will want to make those changes on the system your backing up from.

Also, when migrating, if you migrate a domain (with a database) that is switched off (disabled) on the source host system, although the database and database user will be migrated to the destination system database access will not be allowed to the user on the destination system even when switched back on. At least in my experience. I'm not sure why this is the case or if it was just something that happened in my particular circumstances but it is something to look out for (and easily resolved) if you get mysterious problems after migrating.

I noticed this problem too. I believe it is another Plesk bug. Recreating the user for the database seems to do the trick.
 
Workarounds are nice (recreating the db user), but please send bugreports to SWsoft so these issues might actually get fixed in future releases.
 
Originally posted by breun
Workarounds are nice (recreating the db user), but please send bugreports to SWsoft so these issues might actually get fixed in future releases.

I've already tried, there is no clear channel of submitting bug reports to SWSoft. It's more of a submit and pray sort of situation. If you know of an official way to submit bug reports by all means let me know.
 
Yeah, I have had the same experience. If you submit a bug, there is no feedback at all, even to say that they received your bug report.

If you use Plesk through a reseller, they don't offer any support at all directly (though they generally always have helped anyhow, and then told me they don't offer support for me :))
 
Occasionally I got a response, but submit your reports anyway. Even though you might not get any feedback, they might fix it anyway.
 
I guess I am one of those lucky or extorted few (depending how you look at it) who have a support contract - I send in my stuff every time I have encountered a problem - I don't care if they get sick of me, if they have a problem or I find one I let them know.

Typically they respond back in a day or two and let me know its a known issue, their devs are working on it, and give me some sort of a work around
 
Fix for PleskBackup Issue?

We were referred to this post today from the Planet and I noticed that it was originally opened back in March, just wondering if anyone has heard of a fix being available yet? We have tried the workarounds referenced here and still having a few issues. Someone mentioned this in an earlier post as well but finding out the hard way about this issue certainly is inconvenient, there needs to be a notice or something posted in the cp itself alerting users that this could become an issue during migrations, etc. We might have chosen a different course during preflight to this migration had we known.
 
Back
Top