I have installed wamp 3.0.6 and it install mysql 5.7.11.
But by default, I now end up with MyIsam tables.
In my.ini, I have default-storage-engine=MYISAM.
Why did it revert back to MyIsam?
The problem is that I'm teaching using WAMP and all my students have this problem. I know that I can simply change the my.ini file or change the var in phpmyadmin, but I wonder why it revert back?
thanks
It did not revert back, we intensionally set it back to default to MYISAM as many people were having many problems with corrupted INNODB databases.
A large proportion of WAMPServer users are first time users of all the technologies that make up WAMPServer.
Most never bother to do a database backup, until they get their first corruption.
Most dont bother to close WAMPServer down cleanly, and therefore INNODB can get corrupted more easily than MYISAM.
It was therefore deemed safer for the beginners to default to MYISAM and expect those that now what they are doing to amend the config, or specifically select INNODB in phpMyAdmin when they know that is the table type they want to use
Related
i will really appreciate if someone help me with this.
I have spend like 8hours googling around and found no solution to problem.
I have MySQL server version 5.7.7 on Windows server 2008 R2
Table engine is innodb
innodb_file_per_table = 1
I get error "Table is full" when table reaches 4Gb.
MySQL documentation sais that there is actualy only one limit on table size, filesystem.
(http://dev.mysql.com/doc/refman/5.7/en/table-size-limit.html)
HDD where are data stored uses NTFS, just to be sure i created 5Gb file without problems. And sure there is more than 10Gb of free space.
I understand setting "innodb_data_file_path" is irrelevant if "innodb_file_per_table" is enabled, but i tried to set it. No differences.
I have tried to do clean install of mysql. Same result.
EDIT
Guy that installed MySQL server before me accidentally installed 32bit version. Migration to 64bit mysql solved that problem
About the only way for 4GB to be a file limit is if you have a 32-bit version of MySQL. Also check for 32-bit Operating system. (Moved from comment, where it was verified.)
i am also not sure but read this it may help you.
http://jeremy.zawodny.com/blog/archives/000796.html
one more thing one guy had same problem.he had made changes to
NNODB settings for the innodb_log_file_size and innodb_log_buffer_size!changes were :
1) shutdown mysql
2) cd /var/lib/mysql
3) mkdir oldIblog
4) mv ib_logfile* oldIblog
5) edit /etc/my.cnf find the line innodb_log_file_size= and increase it to an appropriate value (he went to 1000MB as he was dealing with a very large dataset... 250million rows in one table). If you are not sure I suggest doubling the number every time you get a table is full error. he set innodb_log_buffer_size to 1/4 of the size of his log file and the problems went away.
I didnt find solution to this, i have no idea why mysql is unable to create more than 4Gb table.
As a workaround i moved only this table back to ibdata by setting "innodb_file_per_table" back to 0 and recreated that table.
Interesting is that even ibdata1 reported table is full when it reached 4Gb, even without setting max and enabled autoexpand.
So i created ibdata2 and let it autoexpand, now i am able to write new data to that table.
I want to use foreign key in MySQL. For that I needed to enable InnoDB feature. I have tried downloading latest version of MySQL Server from its official site.
I went through similar questions on stackoverflow but they addressed different issues.
I have tried editing all the .ini files and enabling InnoDB properties by removing # in front of corresponding properties.
Then I restarted MySQL and checked status of InnoDB from MySQL Client using query/
show engines;
It still shows InnoDB is disabled
I want to know steps of enabling the built in InnoDB feature for MySQL.
Here are the links to questions I visited:
Ques1
Ques2
Official MySQL forum
I am newbie in MySQL.
I will be very thankful for any help :-)
Check mysql log file. There could be some messages that may explain why InnoDB does not start. I suppose you don't have important InnoDB data. If so, try deleting ib_logfile0.xxx files and ibdata located in mysql data dir, then restart mysql to force those file to recreate. Also, check if innodb variables in my.cnf are properly configurated (For example, I have set memory for innodb_pool... to 1024G instead of 1024M, as a mistake).
I understand I might be asking the impossible but, well never hurts to try.
Is it possible to rollback changes to a handful of MySQL databases without having any form of backup. The only thing left are the databases with the changes I wish to undone.
Why this happened you might ask, well simply putting it, Windows XP scheduler decided not to run the backup task as scheduled, therefore no backups were made previous to a few dozen queries queried to those databases.
I doubt it is possible to undo those changes, and if it is possible I don't know how.
Maybe MySQL keeps some sort of record on the changes performed to a database, but I don't know.
Does anybody knows a way to undo changes to a MySql database without any form of backup
(neither dump file or files from the data folder)?
Thank you.
System Details:
Windows XP SP3
Server: localhost via TCP/IP
Software: MySQL
Software version: 5.5.25a - MySQL Community Server (GPL)
Protocol version: 10
Server charset: UTF-8 Unicode (utf8)
Update
Possible that Windows XP system restore kept a previous version of
MySQL DBs on file?
Without having any database backup, you are probably pretty much out of luck. If you had mysql query logging or binary logging on, you could glean some information about what queries had been run since a certain point in time, but if you had destructive queries (UPDATE, DELETE, etc.) you will have no way of knowing what the previous data was.
Since I'm making a full backup of my entire debian system, I was thinking if having a copy of /var/lib/mysql directory is a viable alternative to dumping tables with mysqldump.
are all informations needed contained in that directory?
can single tables be imported in another mysql?
can there be problems while restoring those files on a (probably slightly) different mysql server version?
Yes
Yes if the table is using the MyISAM (default) engine. Not if it's using InnoDB.
Probably not, and if there is, you just need to execute mysql_upgrade to fix them
To avoid getting databases in a inconsistent state, you can either shutdown MySQL or use LOCK TABLES and then FLUSH TABLES before the backup. The second solution is a little better because the MySQL server will remain available during the backup (albeit read only).
This approach is only going to work safely if you shut the database down first. Otherwise you could well end up in an inconsistent state afterwards. Use the /etc/init.d/mysql stop command first. You can then restart it after the backup is taken.
It's perfectly OK as long as you shut down the MySQL sever first and use exactly the same version to retrieve the "backup". Otherwise it isn't.
For a complete discussion of the 2 strategies, you need to read this: https://dev.mysql.com/doc/refman/5.5/en/backup-types.html
The currently best free and open-source solution seems to be Percona's: http://www.percona.com/software/percona-xtrabackup
I'll go with a strong NO.
From my experience, backing up/restoring raw mysql data files can be used only on the same os/server version. It does not work cross platform (eg. ubuntu/macos) with same server versions nor if mysql server versions are different on same platform.
Percona XtraBackup (innobackupex) from Percona MySQL distro will let you do live & differential mysql backup and serve you the backup files that can be restored by copying to /var/lib/mysql/. You need to be running Percona Server for MySQL to use all of this.
I just went to look over one my site's databases and noticed that all of the tables had been converted to MyISAM (they used to be InnoDB).
What's more is that InnoDB seems to missing, along with BerkeleyDB, Federated, and others.
A few months ago I upgraded from MySql 5.0 to 5.1.38. I can't imagine that I wouldn't have noticed if InnoDB was not installed after the upgrade, but maybe it's been that way since the upgrade. Having several 10 GB tables automatically convert themselves to MyISAM without hearing about any downtime seems very unlikely to me.
Regardless, the mysql system variable have_innodb is set to NO. Can I simply change that to YES or does that mean InnoDB is missing from the install?
Maybe InnoDB parameters were changed during upgrade? This advice from MySQL Forums helped me in a similar situation: http://forums.mysql.com/read.php?22,397052,408970
In short: Stop the MySQL daemon, delete ib_logfile* from datadir, restart MySQL.
If the field in SHOW ENGINES is "no" it means it's not compiled in. You would have to either compile the server again, compile the innodb plugin and load it or fetch server binaries which have it enabled.
You can't simply set the mysql system variable to YES to convert the table from MyISAM to InnoDB.
ALTER TABLE t1 ENGINE=InnoDB;
When InnoDB support is turned off even is you use ENGINE=InnoDB in your create table statements, the table will use the default storage engine for MySQL which is normally MyISAM.
It could also be the case that the innodb logfile[01] are corrupted. In which case the engine will show as disabled and the tables as ISAM. The log will mention it.