After a reinstall of AMPPS (upgrade failed, so I installed the new version over the old one, some config files fixed after new installation), some MySQL database tables seemed to have been lost. In phpMyAdmin I can only see some of them. I checked the database folder and found that I can see files for all of my tables - only some of them don't show up.
Example:
Files for a table that is displayed in phpMyAdmin:
dbtable_ok.frm
dbtable_ok.MYD
dbtable_ok.MYI
Files for a table that is NOT displayed in phpMyAdmin:
dbtable_not_ok.frm
dbtable_not_ok.ibd
These latter files can also not be accessed by websites (especially Joomla).
This is the info about DB and Server from phpMyAdmin:
Database server
Server: localhost via TCP/IP
Server type: MySQL
Server version: 5.6.23 - MySQL Community Server (GPL)
Protocol version: 10
User: root#localhost
Server charset: UTF-8 Unicode (utf8)
Web server
Apache/2.4.12 (Win32) OpenSSL/1.0.1l PHP/5.3.29 mod_wsgi/3.5 Python/2.7.9
Database client version: libmysql - mysqlnd 5.0.8-dev - 20102224 - $Id: 731e5b87ba42146a687c29995d2dfd8b4e40b325
PHP extension: mysqli Documentation
I hope that there is some simple setting in the config files to fix this ...
Thanks!
Any hints or warnings in the MySQL error log?
It's probably bad news for you. The reinstall probably overwrote your existing database. In particular, InnoDB tables are stored (by MySQL default) in the ibdata1 (and so on) file; this file is not portable between MySQL installations. What probably happened was that the new AMPPS installation installed a new set of databases which wiped out your existing database -- either just the metadata MySQL uses to keep track of it or the complete database.
Now it looks like you've got an individual .ibd file, which means that all hope isn't lost. The instructions are rather complex and IMHO not suitable for copying and pasting here, but refer to the MySQL manual https://dev.mysql.com/doc/mysql-enterprise-backup/3.7/en/partial.restoring.single.html and this random site I just found http://www.chriscalender.com/recovering-an-innodb-table-from-only-an-ibd-file/ and perhaps one of them will help. This is where an error message from the MySQL startup may help determine exactly what's going wrong. Depending how old your backup is, it may be safer to just restore from backup.
Related
I installed phpmyadmin on Debian. I copied the database folder from an old server into the current MySQL folder. Then came the error # 1932 - Table doesn't exist in engine. I also copied the ibdata1 but to no avail. What can I do?
Kind regards
Copying the data/files works only if
It is the same database server version till the subversion
You have to copy all files from the data directory.
You can tryto upgrade the database for that consult the manual
I have tried everything I can find now for over 3 days straight to recover a mySQL database on Windows.
What happened?
I have a Windows Server 2012 that crashed which had WordPress on it and the MySQL 5.1 database for WordPress with no backups. Is there no way to recover from this with a database backup even if you have all the files?
What I have tried!
Attempt 1 recovery (try to add the database from the crashed server to the current mySQL instance):
I reinstalled a new MySQL 5.1 on to the new Windows Server 2012
system and I moved just the /data/wordpress953 folder over
“completely” from the crashed system (which was working fine) into
the /data folder of the new MySQL install.
I start up MySQL and login just fine. I see my database. I see all the tables. However, if I go to a table to view it and I get the following error.
1146 = Table ‘Wordpress953.wp_commentmeta’ doesn’t exist
Attempt 2 recovery (try to completely replace the current mySQL instance files from the crashed server on top and overwrite the new instance):
I completely move over the /data folder from the old server replacing it on the new server
I completely move over the /program files/mysql folder over from the old server onto the new server
I completely move over the /program files (x86)/mysql folder over from the old server
I startup mysql and go to phpmyadmin and get the following error when I try and login:
1045 Cannot log in to the MySQL server
I figure I just need to fix the root password so I attempt to change the root password using this process https://www.youtube.com/watch?v=dyc5b3yT2tI but it fails to even start mySQL to change the password.
Please help with an answer of something I haven't tried....
Ok, I got it!!
The procedure is.
Install vanilla mySQL on new server (I had already done that)
Stop mySQL service
Move ONLY the C:\Program Data\data\wordpress953 (the innodb database you want to restore) folder over “intact” “as is”.
And, move ONLY the ibdata1 file and ib_logfiles off of the original C:\Program Data\data\ root to the new mySQL server. Leave the C:\Program Data\data\mysql folder “as is” from the vanilla install
Re-Start mySQL service
It was a bit of a puzzle because it was basically an “incarnation” of what I was doing but you have to only change/do certain things. The C:\Program Data\data\ibdata1 file down one level in the root went with the C:\Program Data\wordpress953 folder but apparently not with \mysql.
I faced many troubled with MySQL - too many applications related to MySQL was installed
I totally removed MySQL from my MAC_OS - any folder have "mysql" keyword had been removed && all the applications which related to MySQL
I started again from scratch by installing MySQL community and MySQL Workbench
now - MySQL server are not starting
, every time I click on "Start MySQL Server" it load but nothing happens
I think - I don't have enough info about why I have this issue , but any tips will be helpful
I suggest to remove .Log files from MySql data folder. Since it's new installation there is no risk. MySql should definitely start
It started with installation of wampserver for php, before that I had already running MySQL server 5.7 with all databases properly showing in the side schema panel. When I launched MySQL server after installation of wampserver 5.7.14, the password for root was overridden and no database except sys is showing. Also I found another user (mysql.sys) has been created (found in Users and Privileges). Then I looked for databases in path "ProgramData\MySQL\MySQL Server 5.7\Data", all databases are present in the folder (thank god they are not deleted). Problem is now for my website I get this error:
"Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration"
Exception Details: System.Data.Entity.Migrations.Infrastructure.AutomaticMigrationsDisabledException: Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.
I know this is not related to migrations because my database already exists but I don't know how to solve the problem that MySQL can see the databases in its "ProgramData\MySQL\MySQL Server 5.7\Data" again.
When you installed WAMPServer on a system that already had a MYSQL Server instance installed on it, you created a second MySQL Server instance. See your service you will have one called wampmysqld or wampmysqld64 and another called MYSQL.
Now, whichever service you start first will be the MySQL Server that Workbench, or anything else is talking to. And you will only see the databases that this MySQL Server instance knows about.
Correct Solution:
Stop WAMPServer
Start the MYSQL installed with Workbench
Backup all YOUR databases, NOT the ones created by MySQL like mysql, sys, information_schema, performance_schema
Stop this MYSQL Server.
Uninstall this MySQL Server
Start WAMPServer
Restore your databases to this MySQL Server instance
All should start working as expected now.
Connect your Workbench to WAMPServers MySQL Server
Update
Did a robust workaround, though not very suggestible but database is now accessible in MySQL workbench. Though I'm having the same error when opening the website on local web server. One thing that I did not mention before that environment is Windows based. what I did is copied database from the ProgramData MySQL path to "..\wamp64\bin\mysql\mysql5.7.14\data" path and refreshed schema in workbench. Any advice why I'm still having problem in web server.
I am attempting to remotely connect to a MySQL database using ruby on rails.
In my database.yml:
development:
adapter: mysql
database: peer
host: host
port: 3306
username: root
password: password
I then go to do a rake db:migrate and get this error
Mysql::Error: The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have it working: CREATE TABLE `schema_migrations` (`version` varchar(255) NOT NULL) ENGINE=InnoDB
Now after some searching, I found that this was an error on Windows Servers with MySQL and I needed to go into the my.ini file and comment out skip-innodb. When I went to do that however, that line wasn't in that file but in a different one named "my-innodb-heavy-4g.ini"
I found the command in the line, but it was already commented out. And now I am at a loss on what to do next.
This application is going to be connected to multiple databases as well, I just wanted to see if I could connect to the remote one first.
Stop MySQL, rename my.ini to something else, rename "my-innodb-heavy-4g.ini" to my.ini, restart MySQL. Assuming, of course, that your MySQL server was built with InnoDB in the first place.
Edit: it appears that the OP is using a server deliberately built without InnoDB support. See e.g. here, a 5.0 reference manual, under section "2.3.2. Enterprise Server Distribution Types":
This section does not apply to MySQL
Community Server users.
...
mysql-classic: Released under a commercial license, does not include
InnoDB.
...and the poster now says their server is indeed a 5.0 "mysql-classic".
So, it appears that the only way to use InnoDB under these conditions is to upgrade the server to something more functional (and ideally a bit more recent, but that's no big deal).