So I have a new computer and I'm trying to set everything up for some projects.
When I try to import some databases I'm getting this message after the import fails in phpmyadmin:
Missing expression. (near "ON" at position 25)
SET FOREIGN_KEY_CHECKS = ON;
MySQL error 2006: mysql server has gone away
and I get logged out of phpmyadmin alltough the import just takes few seconds.
I already read some hints and I already did:
Set the my.cnf values like:
[mysql]
max_allowed_packet=512M
[mysqld]
max_allowed_packet=512M
wait_timeout=600
interactive_timeout = 86400
and also adjusted my php.ini to:
max_execution_time = 500
max_input_time = 500
memory_limit = 512M
post_max_size = 512M
upload_max_filesize = 256M
Tried the import via command line:
mysql -u USER -p database < import.sql
The command line gives me this as an error:
ERROR 2013 (HY000) at line 12042: Lost connection to MySQL server during query
So apparently this is not just some php stuff.
The import seems to fail. I tried it with multiple Databases. Some where 10MB, some where 120MB. If I start a fresh web application or a wordpress instance, everything works fine and there is no error at all. But the failing databases should also work fine. At least they do on production, staging and on my former working machine.
So I'm a bit lost here.
Here are the current version:
Ubuntu 20.04
mysql Ver 8.0.27-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))
PHP 7.4.25 (cli) (built: Oct 22 2021 12:34:33) ( NTS )
phpmyadmin 4:4.9.5+dfsg1-2
Update:
I looked into the error.log of mysql:
2021-10-29T13:10:12.337942Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.27-0ubuntu0.20.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu).
2021-10-29T13:14:31.622915Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: ddl0builder.cc:1495:n >= IO_BLOCK_SIZE thread 140053145696000
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:14:31 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x100000
Maybe someone did run into this?
This answer is piggybacking off this answer from emanuelv. Unfortunately, I do not have enough reputation to comment.
If this is indeed an error due to phpMyAdmin attempting to add table indices after data insertion, and MySQL 8.0 chokes on tables with a lot of data already present during import, you can tell phpMyAdmin to use IF NOT EXISTS during table creation, thus forcing indices to be created before any data is inserted.
On the database export screen, select the "Custom" export method, and enable the following option:
[✓] IF NOT EXISTS (less efficient as indexes will be generated during table creation).
Screenshot of the option
This error happens when dumping databases with PhpMyAdmin, since it adds index creation in a separate statement at the end.
It first creates the TABLE without indices, then INSERTs all the data and at the end it creates indices with ALTER statement.
The import will fail on MySQL 8 when creating multiple indices in one ALTER statement.
So, this will fail (if the data is already in the table):
ALTER TABLE `wp_posts`
ADD PRIMARY KEY (`ID`),
ADD KEY `post_name` (`post_name`(191)),
ADD KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`),
ADD KEY `post_parent` (`post_parent`),
ADD KEY `post_author` (`post_author`);
And this will not:
ALTER TABLE `wpul_posts` ADD PRIMARY KEY (`ID`),
ALTER TABLE `wpul_posts` ADD KEY `post_name` (`post_name`(191)),
ALTER TABLE `wpul_posts` ADD KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`),
ALTER TABLE `wpul_posts` ADD KEY `post_parent` (`post_parent`),
ALTER TABLE `wpul_posts` ADD KEY `post_author` (`post_author`);
Still trying to figure out what exactly is the deal here, looks like something to do with collations / charsets.
Would appreciate any further info on this error.
By now, I switched to docker containers. But I still found the reason for the problem and want to share the solution with you:
On my old system with mysql 5.something I exported the database directly from phpmyadmin. This file couldn't be imported to mysql 8.0.27 with the import function or the command line.
The solution was a dump with mysqldump. This SQL had no problems when importing.
Somehow I thought, that the export of phpmyadmin is the same as the mysqldump.
So if someone runs into this problem, mysqldump is the solution. :)
We solved this problem with mysqldump, too. The client had a phpMyAdmin 4.9.7 SQL Dump from MySQL server 5.7.36 to be imported on MySQL Server 8.0.27. I broke it down to the following reproducer:
-- phpMyAdmin SQL Dump
-- version 4.9.7
-- https://www.phpmyadmin.net/
--
-- Host: localhost
-- Erstellungszeit: 29. Nov 2021 um 21:06
-- Server-Version: 5.7.36
-- PHP-Version: 7.3.33
/*!40101 SET #OLD_CHARACTER_SET_CLIENT=##CHARACTER_SET_CLIENT */;
/*!40101 SET #OLD_CHARACTER_SET_RESULTS=##CHARACTER_SET_RESULTS */;
/*!40101 SET #OLD_COLLATION_CONNECTION=##COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
DROP TABLE IF EXISTS `s_mail_log`;
CREATE TABLE `s_mail_log` (
`id` int(11) NOT NULL,
`type_id` int(11) DEFAULT NULL,
`order_id` int(11) DEFAULT NULL,
`shop_id` int(10) UNSIGNED DEFAULT NULL,
`subject` longtext COLLATE utf8_unicode_ci,
`sender` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`sent_at` datetime NOT NULL,
`content_html` longtext COLLATE utf8_unicode_ci,
`content_text` longtext COLLATE utf8_unicode_ci
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `s_mail_log` (`id`, `type_id`, `order_id`, `shop_id`, `subject`, `sender`, `sent_at`, `content_html`, `content_text`) VALUES
(3586,
2,
9463,
1,
'A',
'B',
'2021-09-22 12:51:39',
'1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222233333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333334444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444123456789',
'111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111122222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222223333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444455555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555556666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777788888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888889999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999111111111122222222223333333333444444444455555555556666666666123456789012345678'
),
(3587,
2,
9465,
1,
'1234567890123456789012345678',
'123456789012345',
'2021-09-22 14:20:30',
'11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111',
'22222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222');
ALTER TABLE `s_mail_log`
ADD PRIMARY KEY (`id`),
ADD KEY `s_mail_log_idx_type_id` (`type_id`),
ADD KEY `s_mail_log_idx_order_id` (`order_id`),
ADD KEY `s_mail_log_idx_shop_id` (`shop_id`);
/*!40101 SET CHARACTER_SET_CLIENT=#OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=#OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=#OLD_COLLATION_CONNECTION */;
Fails to console with
ERROR 2013 (HY000) at line 64: Lost connection
and in the mysql.err with
[ERROR] [MY-013183] [InnoDB] Assertion failure: ddl0builder.cc:1495:n >= IO_BLOCK_SIZE thread 140481166030592
InnoDB: We intentionally generate a memory trap.
at
ADD KEY `s_mail_log_idx_shop_id` (`shop_id`);
Related
There is a mariadb version 10.7 instance running in Kubernetes.
Recently log-bin was added to the server.cnf.
The restore scripts stopped working for any database not in binlog_do_db with no error.
The problem seems to be related to: SET UNIQUE_CHECKS=0;SET FOREIGN_KEY_CHECKS=0;.
Also the mariadb log contains no errors or messages related to the restore.
Any ideas greatly appreciated.
Thank you.
server.cnf
[mariadb]
log-bin
server_id=1
log-basename=1
binlog-format=mixed
binlog_do_db=db1
binlog_do_db=db2
example.sql
DROP DATABASE if EXISTS test;
CREATE DATABASE test;
USE test;
CREATE TABLE IF NOT EXISTS `test` (
`test` INT(11) NULL DEFAULT NULL
);
SET UNIQUE_CHECKS=0;
SET FOREIGN_KEY_CHECKS=0;
INSERT INTO test VALUES (1);
SET FOREIGN_KEY_CHECKS=1;
SET UNIQUE_CHECKS=1;
SELECT * FROM test;
-- if binlog_do_db contains test (or log-bin is not used), the insert works.
-- if log-bin is used and binlog_do_db doesn't contain test, the insert will silently fail.
Edit: Added mariadb version 10.7. Same problem with 10.8-rc
I exported a database from a production server and I'm trying to import it into my local test environment. When I try to import it gives me the error below on multiple tables.
ERROR 1146 (42S02): Table 'abc123' doesn't exist
I have verified that the tables do exist in the production database and the sql file has the create table statement:
CREATE TABLE `wp_posts` (
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
On the Production Database, the Collation is set to latin1_swedish_ci and each table Collation is set to `utf8mb4_unicode_ci' which I have replicated in the local database.
Production Database server: Server version: 5.7.34
Local Database server: Server version: 5.7.24
I have read through a lot of posts on SO and can't find a solution to this.
EDIT:
I was able to fix this problem by increasing the packet size in mysql.ini
I was able to fix this problem by increasing max_allowed_packet to 64MB in the mysql.ini.
I'm running a MySQL 5.1 server under CentOS 6.5. During an import of a SQL file today, all tables were created under MyISAM, even if they were declared to use InnoDB engine.
For example, I had a table declared on the .sql file as this:
CREATE TABLE `customer` (
`customer_id` int(11) NOT NULL AUTO_INCREMENT,
`customer_no` varchar(20) DEFAULT NULL,
`company_name` varchar(50) DEFAULT NULL,
[....]
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT
When the .sql file was imported using:
mysql -u <username> -p < new_db.sql
The customer table was created using the MyISAM table. How can this be possible?
To fix the issue I have added on MySQL config to set the default engine to InnoDB and restarted but, since the table engine was declared to be InnoDB, shouldn't it be loaded using that declared engine instead of the default ?
MySQL 5.1 have some problems. I prefere to update it.
The other way is to disable different InnoDB settings in your my.cnf until innoDB is running.
show engine innodb status
With this command you can check the current state. Dont forget to restart mysql after every change.
After a long time searching for an explanation of the issue I have found none, but there are ways to prevent the issue and to fix it.
1st - Check this MySQL configuration: no engine substitution. It will help to avoid the issue. http://dev.mysql.com/doc/refman/5.0/en/sql-mode.html#sqlmode_no_engine_substitution
2nd - When the error is happening, use both show_warnings and show_engines to see any errors that occurred and to see if InnoDb is enabled. You can also use show engine innodb status to gather detailed information.
3rd - Since MySQL 5.1 have by default MyISAM as the default engine, set mysql configuration to use InnoDB as the default engine.
default-storage-engine=InnoDB
default-table-type=InnoDB
And if all of that fails and you can't still find out why or what is happening, then, this might help:
$ sudo service mysqld stop
$ mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
$ mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak
$ sudo service mysqld start
It doesn't properly explain why the issue happened but it will help solve it. My next step is verify if the server and application will support a MySQL update to 5.5
I restored a mysql database from a mysql server running on linux to one running on windows. Everything seemed fine until I tried to run an ALTER TABLE on one of the tables. The error I get if I try to ALTER anything is:
Error Code: 1067. Invalid default value for 'creation_date'
Now the strange thing is that dump file successfully restored and created the table. If I use Workbench to get the create statement for the table I see:
`creation_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
For the column which is causing an issue.
How can the CREATE TABLE statement succeed in such a way that I cannot perform alters on it now?
Some background on sql_mode and 'NO_ZERO_DATE': http://dev.mysql.com/doc/refman/5.1/en/sql-mode.html
You mentioned that you restored the tables from another server. If you used mysqldump then the answer to your question is that mysql turned off 'NO_ZERO_DATE' mode while loading the dumped SQL. Mysqldump (tested in 5.5) puts this line at the top of the dumped SQL:
/*!40101 SET #OLD_SQL_MODE=##SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
It also turns off foreign key checks and other useful things while loading the dump.
/*!40014 SET #OLD_UNIQUE_CHECKS=##UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET #OLD_FOREIGN_KEY_CHECKS=##FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
This explains why you were able to restore the tables, but when trying to alter you must play by stricter rules. If you really want to override this you can try the following just before your alter table:
mysql> SET SESSION sql_mode='';
Then alter table.
I run a daily backup mysqldump backup of the production database (mysql version 5.1.66):
mysqldump --user=username --password=secret -C -e --create-options --hex-blob --net_buffer_length=5000 databasename > file
I also do a daily restore of that database on my development machine (mysql version 5.6.12)
mysql --user=username --password=secret databasename < file
I get the error:
ERROR 1813 (HY000) at line 25: Tablespace for table 'databasename.tablename' exists. Please DISCARD the tablespace before IMPORT.
My reading indicates this is because the mysql innodb database requires the command:
ALTER TABLE tbl_name DISCARD TABLESPACE;
to be run before the table is dropped -- it seems that dropping the table isn't sufficient to get rid of its indexes.
(my development server uses the innodb_file_per_table option)
I don't want to use 'replace' option because i could potentially have data in my development database that was deleted on the production database.
btw after the error the tables are not readable, but restarting mysqld fixes it.
So the question is, is there any mysql dump option that will help fix this issue, or is there another way to import the data that will prevent the error?
thanks in advance for reading.
Sounds like you have a tablename.ibd but no tablename.frm.
To check:
cd to your mysql data directory then the database name.cd /var/lib/mysql/database_name
Search for the table name that is giving the error.
ls tablename.*
You should see two files:
tablename.ibd
tablename.frm
But I'm guessing you don't and only see tablename.ibd
To fix you have a few options:
Add the follow to mysqldump, which will cause the database to be dropped, cleaning up data directory, before restore.--add-drop-database
Copy the tablename.frm from prod over to dev and then issue a delete table statement.
Also:
No need to use net_buffer_length=5000 when you're dumping to a file on localhost.
Other backup solutions - Percona Xtrabackup
I found the easiest way to skip this problem was to manually edit phpmyadmin database dump and edit/change the table that had problems to something else than INNODB. I changed the problem table to ENGINE=MyISAM and voila. Import worked.
CREATE TABLE IF NOT EXISTS `home3_acymailing_tag` (
`tagid` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(250) NOT NULL,
`userid` int(10) unsigned DEFAULT NULL,
PRIMARY KEY (`tagid`),
KEY `useridindex` (`userid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
I also encountered that problem while dropping a schema and creating it again. I overcome this issue by going C:\ProgramData\MySQL\MySQL Server 5.6\data\my_database_name and deleting the tables which remained from the previous database creation. You can also delete the entire database, if you wish.
if you are using XAMPP then first ("stop") MySQL
Then go to C:\xampp\mysql\data\dnb
where in my case dnb is my database name folder.
so then open it and delete .ibd file hence you can only delete it when you already stop MYsql .
then go to phpmyadmin
1 click on phpmyadmin .
2 click on databases that appear below (server.127.0.0.1 in your case my be change)
3 then check your database which you want to drop,and click on drop.
4 then you can create database with same name and import your database successfully .here you can see how you drop database from phpmyadmin