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.

Environment Information

WordPress version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by mlelao on Thursday, 04 February 2016 11:11 CST

mlelao
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)

nicholas
Akeeba Staff
Manager
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 β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mlelao
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

nicholas
Akeeba Staff
Manager
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 β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mlelao
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

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

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!