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
Related
My table looks like
create table try ( name varchar(8), CREATED_BY varchar(40) not null);
and then I have a trigger to auto populate the CREATED_BY field
create trigger autoPopulateAtInsert BEFORE INSERT on try for each row set new.CREATED_BY=user();
When I do an insert using
insert into try (name) values ('abc');
the entry is made in the table but I still get the error message
Field 'CREATED_BY' doesn't have a default value Error no 1364
Is there a way to suppress this error without making the field nullable AND without removing the triggfer? Otherwise my hibernate will see these exceptions ( even though the insertions have been made) and then application will crash.
This is caused by the STRICT_TRANS_TABLES SQL mode defined in the
%PROGRAMDATA%\MySQL\MySQL Server 5.6\my.ini
file. Removing that setting and restarting MySQL should fix the problem.
See https://www.farbeyondcode.com/Solution-for-MariaDB-Field--xxx--doesn-t-have-a-default-value-5-2720.html
If editing that file doesn't fix the issue, see http://dev.mysql.com/doc/refman/5.6/en/option-files.html for other possible locations of config files.
Open phpmyadmin and goto 'More' Tab and select 'Variables' submenu.
Scroll down to find sql mode.
Edit sql mode and remove 'STRICT_TRANS_TABLES'
Save it.
In phpmyadmin, perform the following:
select ##GLOBAL.sql_mode
In my case, I get the following:
ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES ,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Copy this result and remove STRICT_TRANS_TABLES. Then perform the following:
set GLOBAL sql_mode='ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
Set a default value for Created_By (eg: empty VARCHAR) and the trigger will update the value anyways.
create table try (
name varchar(8),
CREATED_BY varchar(40) DEFAULT '' not null
);
When I had this same problem with mysql5.6.20 installed with Homebrew, I solved it by going into my.cnf
nano /usr/local/Cellar/mysql/5.6.20_1/my.cnf
Find the line that looks like so:
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
Comment above line out and restart mysql server
mysql.server restart
Error gone!
Run mysql console:
mysql -u your_username -p
, select database:
USE your_database;
and run (also from mysql console):
SET GLOBAL sql_mode='';
That will turn off strict mode and mysql won't complain any more.
To make things clear: your database definition says "this field must have default value defined", and by doing steps from above you say to MySql "neah, just ignore it". So if you just want to do some quick fix locally this solution is ok. But generally you should investigate in your database definition and check if field really needs default value and if so set it. And if default value is not needed this requirement should be removed to have clean situation.
As others said, this is caused by the STRICT_TRANS_TABLES SQL mode.
To check whether STRICT_TRANS_TABLES mode is enabled:
SHOW VARIABLES LIKE 'sql_mode';
To disable strict mode:
SET GLOBAL sql_mode='';
Before every insert action I added below line and solved my issue,
SET SQL_MODE = '';
I'm not sure if this is the best solution,
SET SQL_MODE = ''; INSERT INTO `mytable` ( `field1` , `field2`) VALUES ('value1', 'value2');
Modify your query and add "IGNORE" as:
INSERT IGNORE INTO `mytable` ( `field1` , `field2`) VALUES ('value1', 'value2');
Its work and tested Copy to Config File: /etc/mysql/my.cnf OR /bin/mysql/my.ini
[mysqld]
port = 3306
sql-mode=""
then restart MySQL
This appears to be caused by a long-standing (since 2004) bug (#6295) in MySQL, titled
Triggers are not processed for NOT NULL columns.
It was allegedly fixed in version 5.7.1 of MySQL (Changelog, last entry) in 2013, making MySQL behave as “per the SQL standard” (ibid).
For Windows WampServer users:
WAMP > MySQL > my.ini
search file for sql-mode=""
Uncomment it.
In Windows Server edit my.ini (for example program files\mysql\mysql server n.n\my.ini)
I would not simply set the sql-mode="", rather I suggest one removes STRICT_TRANS_TABLES from the line, leave everything as-was, and then restart MySQL from the services utility. Add a comment for future programmers who you are and what you did.
Most of these answers are a lot of work for the not-seasoned coder. Like mentioned the issues is with STRICT_TRANS_TABLES.
First verify STRICT_TRANS_TABLES is running.
$ mysql -u root -p -e "SHOW VARIABLES LIKE 'sql_mode';"
You can disable strict mode on your MySQL server by running the following command on your Linode's command line:
$ mysql -u root -p -e "SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';"
Then, you can verify that the mode is set by running the following:
$ mysql -u root -p -e "SELECT ##GLOBAL.sql_mode;"
This answer was found here https://www.linode.com/community/questions/17070/how-can-i-disable-mysql-strict-mode
i set the fields to not null and problem solved, it updates when an information is commanded to store in it, no more showing msqli message that the field was empty cus you didnt insert value to it, well application of this solution can work on some projects depends on your project structure.
This is for SYNOLOGY device users:
How to set global variables (strict mode OFF) on SYNOLOGY device.
(checked on DSM 7.0.1-42218 - device model DS418)
Used PUTTY to connect:
login as root and
sudo su after... (to be admin total)
if not exist create my.cnf in:
MariaDB 5:
/var/packages/MariaDB/etc
MariaDB 10:
/var/packages/MariaDB10/etc
this should be in the file (at least for strict mode off)
# custom configs
[mysqld]
innodb_strict_mode = OFF
sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
restart mysqld daemon:
MariaDB 5:
/usr/syno/bin/synopkg restart MariaDB
MariaDB 10:
/usr/syno/bin/synopkg restart MariaDB10
check for strict mode enabled at these two global options - both should be not there or off (see config above)
log into mysql:
mysql -u root -p
enter password:
show variables like 'sql_mode';
show variables like '%STRICT%';
i solved problem changing my.ini file located in data folder. for mysql 5.6 my.ini file moved to data folder rather the bin or mysql installation folder.
I think in name column have null values in this case.
update try set name='abc' where created_by='def';
I am using Xampp 7.3.28-1 for Linux. It uses MariaDB 10.4.19. Its configuration file is:
/opt/lampp/etc/my.cnf
It does NOT contain an entry that defines sql_mode.
However the query "select ##GLOBAL.sql_mode;" does return a result and it contains the problematic STRICT_TRANS_TABLES. I guess it is by default now.
My solution was to explicitly define the mode by adding this line below [mysqld]:
sql_mode=NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
You can define the modes that you need or just leave it blank.
I found that once I removed what was a doubling up of a foreign key and primary key, when I could have just used the foreign key as the primary key alone in the table. All my code then worked and I was able to upload to db.
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`);
CREATE TABLE `revenue_daily` ( `wallet` varbinary(100) NOT NULL DEFAULT '0',
`tc_access` varbinary(100) NOT NULL DEFAULT '0',
`tc_short` varbinary(100) NOT NULL DEFAULT '0',
`total_toll_collection` varbinary(100) GENERATED ALWAYS AS (`wallet` + `tc_access`) VIRTUAL NOT NULL,
`cash_collection` varbinary(100) GENERATED ALWAYS AS (`total_toll_collection` - `tc_short`) VIRTUAL NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=ascii;
That table has generated column.I backed up database structure with data and when i am restoring same .sql file then error occur.
Error is:-
ERROR 3105 (HY000) at line 262: The value specified for generated column 'total_toll_collection' in table 'revenue_daily' is not allowed.
I am using mysql version:-
sunilp#sunilp ~> mysql --version
mysql: [Warning] World-writable config file '/etc/mysql/mysql.conf.d mysqld.cnf' is ignored.
mysql Ver 14.14 Distrib 5.7.18, for Linux (x86_64) using EditLine wrapper
This is a problem when using mysqldump from MariaDB with virtual generated columns.
MariaDB's mysqldump apparently dumps the generated values, but MySQL only accepts DEFAULT as value for a virtual generated column.
It seems like you need to use MySQL's mysqldump to correctly dump and restore virtual generated columns on a MySQL server.
The bug was also reported here.
What I do as a workaround, is replace the virtual column in the dump:
sed -i 's/GENERATED ALWAYS AS .* VIRTUAL/NOT NULL/' mydump.sql
then restore the dump, then drop/add the generated column again:
mysql -e "ALTER TABLE foo DROP COLUMN bar;\
ALTER TABLE foo ADD COLUMN bar VARCHAR(255) AS ...;"
I also posted this answer here.
I had the same problem dumping it from mariadb using adminer (https://www.adminer.org/)
In my case I solved it doing dump with phpmyadmin. It worked for me.
I don't know reason but adminer dump generated values columns. It shouldn't because that value should be generated when rows are inserted.
I didn't try what happens when using mysqldump from command line...
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
I imported a MySQL dump file into my MySQL server using following command.
mysql> create database database_name;
mysql> use database_name;
In Linux command prompt,
$ mysql -u user_name -p database_name < /tmp/test1.dmp
But, while viewing the database using phyMyAdmin the newly created database_name does not show table relations. It shows only the tables, but not relations.
Is there any set up required before importing the database in mysql database?
How to extract the relations between tables?
I just went through the exact same problem.
Is there any set up required before importing the database in mysql database?
Not exactly, but it seems LAMP Server installed on Ubuntu or any Linux Distribution uses MyISAM storage engine by default while creating tables. On InnoDB supports Foreign Key relation. [more info]
To change the storage engine afterwards. [Source answer]
You have to add the line default-storage-engine = InnoDB under the [mysqld] section of your mysql config file (my.cnf or my.ini depending on your operation system) and restart the mysqld service. I don't believe you can change this through phpMyAdmin.
On ubuntu, my.cnf is located inside /etc/mysql/.
Or, you can use mysql command
mysql> SET storage_engine=InnoDb;
After this, all the tables and database you create after this, will use InnoDB as their default storage engine, thus eliminating the issue afterwards.
How to extract the relations between tables?
After you change default engine of your database. You also have to change the default engine of your tables, because they haven't been changed yet. Use the syntax below to change the storage engine
ALTER TABLE <table_name> ENGINE = innodb
Using phpMyAdmin
Go to the operations tab after selecting a table
Go to the table options [See below]
You will see an option to change the storage engine of the table
Change the storage engine to InnoDb and hit Go
After this, export the database using phpMyadmin or dump your database using mysqldump. it will show the relations.