Support

Akeeba Backup for WordPress

#24360 – ErrNo #0 while restoring website on the same server

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 03 February 2016 23:49 CST
Hi there!

I've been running in a new problem yesterday.

I made and downloaded a complete backup of the website just minutes before crashing it completely.
I erased everything from the server and the database before uploading the archive and kickstart.php.

And then, I get this message from Angie (whatever the option settings are; i've tried various combinations):
Database error processing line 0

Database server error reply:

ErrNo #0

SQL=CREATE TABLE `wp_ak_params` (`tag` varchar(255) NOT NULL ,`data` longtext NULL , PRIMARY KEY (`tag`)) ENGINE=InnoDB DEFAULT COLLATE utf8mb4_unicode_ci

Raw query text:

CREATE TABLE `#__ak_params` (`tag` varchar(255) NOT NULL ,`data` longtext NULL , PRIMARY KEY (`tag`)) ENGINE=InnoDB DEFAULT COLLATE utf8mb4_unicode_ci



Using phpMyAdmin, i tried the query directly and got the following message:
#1071 - Specified key was too long; max key length is 767 bytes


Considering the problem could be linked to the host, I tried to restore the website on another server: I get the exact same error.

I've seen in ticket #24358 that I'm not the only one to have same trouble... But I do not have the same means as Paul to regenerate a new backup, unfortunately.

Can you help me on this?

Thanks in advance!
m

PS: credentials to access the server are still the same (see ticket #24321)
Custom Fields
Which documentation pages did you read? angie-installers.html#angie-common-database
Which troubleshooter articles did you read? troubleshooter/abidatabase.html
Have you searched the tickets before posting? Yes
Did you already run the log analyser (ALICE)? Not Applicable
WordPress version (in x.y.z format) 4.4.1
PHP version (in x.y.z format) 5.5.25
MySQL/database version 5.6.22
Host (who is hosting your site, not your domain) http://www.west263.net/
Akeeba Backup version (x.y.z format) 1.6.2
 
mlelao
Thursday, 04 February 2016 01:42 CST
As I have explained, there is nothing we can help with. You need to make sure that your target MySQL server supports utf8mb4.

You CAN transfer FROM utf8 TO utf8mb4. You CANNOT transfer FROM utf8mb4 TO utf8. This is a MySQL limitation!

Even worse, even if you had your original site and you explicitly converted all tables to plain old utf8, WordPress would STILL upgrade ALL your tables to utf8mb4 WITHOUT asking you the next time it installs a core update.

If we allowed you to downgrade from utf8mb4 to utf8 you would get truncated data. The simple fact of life is that utf8mb4 can store up to 4 byte characters, utf8 can store up to 3 byte characters, if you try to save 4 byte characters to utf8 MySQL truncates the inserted data up to before the 4-byte character without warning and without throwing an error! Therefore if we allow you to do that you WILL get a corrupt site.

The only possible course of action is buying hosting on a host with a utf8mb4-capable MySQL database server.


Nicholas K. Dionysopoulos

Lead Developer and Director



Greek: native

English: excellent

French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



nicholas
Thursday, 04 February 2016 02:11 CST
Hi Nicholas!

I think I didn't make things clear enough...

The site was up and running on the very same servers using the exact same configuration. I crashed it while trying to solve a problem with the plug-ins I use to manage translations (CMS multilingual, provided by wpml.org).

Since I knew beforehand there was a risk to crash the website, I made backup and downloaded the jpa archive; then I started to tweak the DB and plug-ins, which resulted in the crashed website.

After the crash, I cleaned both the DB and the website files, planning to restart one step before the crash thanks to the jpa archive. Unfortunately, I get this error –described in my first message– while I try to reinstall the database on the same mysql server.

Whatever, if you confirm you cannot do anything to help, I can still understand it ;-)

Best
m
 
mlelao
Thursday, 04 February 2016 02:42 CST
OK, if it's on the same server try unchecking the Detect utf8mb4 option in the restoration script, in the database setup page. Apparently one of your tables is still in utf8 format because of its key size. Trying to upgrade it to utf8mb4 causes an error.


Nicholas K. Dionysopoulos

Lead Developer and Director



Greek: native

English: excellent

French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



nicholas
Thursday, 04 February 2016 11:11 CST
I tried this also, and it didn't work.

I've restarted from the ground up, taking the last backup archive from the development server and reinstalled everything.
I took the time to check at each step that each table of the DB had the proper collation.

Now everything works fine!

Once more, thanks for the kind support!
m
 
mlelao
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Upcoming unavailability: We will be closed December 23rd, 2019 19:00 to January 3rd, 2020 10:00 Cyprus timezone (EEST) due to the Holiday Season. You will not be able to file new support tickets or reply to existing ones.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.