I have a joomla 2.5 site created locally on my machine, that I've migrated to a vps running nginx, php and mysql. Here is what i did in order:
1. Uploaded all the joomla files in the public_html
2. Changed all the files permission to 644 and all the folders to 755
3. Imported the database.sql to mysql using these commands:
--> mysql> create database databasename;
--> mysql> GRANT ALL PRIVILEGES ON
databasename.* TO username#localhost IDENTIFIED BY 'password';
--> mysql> flush privileges;
--> mysql> exit
--> user#vps:~$ mysql -p -u username database_name < file.sql
I can see all my tables inside the database already, and changed all the needed information on my joomla configuration.php but when i open my site, i get this error:
Table 'databasename.s1t3j0s_session' doesn't exist SQL=INSERT INTO `s1t3j0s_session` (`session_id`, `client_id`, `time`) VALUES ('rh249ehb2tbsqkdff34v177d76', 0, '1357339991')
Where did i got it wrong?
I have migrated wordpress site to the same server with no error.
I've been having trouble with it for weeks. What I needed was a backup copy on my system. However, when I uploaded the database from the remote server onyto my localhost I was getting error messages relating to the session table not existing (the same error that you are getting).
I tried all of the tips relating to deleting and re-creating the tables, but this did not work.
The only solution which worked 100% - which I finally discovered today, was to re-install Joomla 2.5 (I used a fresh install), and then do the following:
Instead of uploading the database from site containing the correct content, instead go through the SQL file itself (i.e. the one you will have exported for upload before encountering problems), and manually process each one of the insert statements into your SQL console directly (I'm using PHPMyadmin). In other words, don't attempt to import the whole file as you normally would. To do this will just result in errors.
For some reason, Joomla 2.5 has an issue with tables that are already populated with data being replaced by a dump file or replacement, sometimes duplicate, data. Hence the need for a fresh install....
Before processing each of the install statements individually (this can take a while - it took me about an hour and a half), go through each of the Joomla tables and make sure that NONE of them are populated with any data whatsoever (therefore when you process the install statements they will not be replacing existing data - because you will have removed all data from populated tables).
So long as you make sure that no INSERTED data has been added to the tables prior to the migration, this will solve your problem.
So to summise:
1/ Get a fresh J2.5 install.
2/ Delete all popolated table data from every joomla table.
3/ Copy and paste each of the insert statements from the exported mysql file containing the correct data. Process each statement individually (this is optional, but highly recommended: to do it this way enables you to counter and pinpoint any individual errors if and when they occur - without having to look through the entire mysql file)
...Go to your site: bingo - it should work!
Make sure the value of $dbprefix in configuration.php under the Joomla directory has the correct value by checking it against the actual db prefix used (open phpMyAdmin and choose the Joomla database to check for this).
Just truncate the data in the session table and do the process again. You have nothing to worry about truncating because there are no valuable data. Session table sometimes messes up stuff.
On Unix, table names are case sensitive. On Windows, they are not. Fun, isn't it? Kinda like their respective file systems. Do you think it's a coincidence?
Caveat: it probably depends on table type; MyISAM.
Field names are case-insensitive regardless.
I had this problem,
in my case, I imported the database through the cpanel and later on got this error message. I later found out that importing database through the cpanel didnot import the tables, just the database name. So I went to the phpmyadmin and import the database there once again, and solved.
Related
The problem is, that one MYI and one MYD file from MySQL database has been accidentally deleted. The only file left intact is FRM one. Only one table from the whole database is damaged that way, all other tables are OK and the database works generally fine, except the table with deleted files, which is obviously inaccessible.
There's a full database dump in pure SQL format available.
The question is, how do I re-create these files and table in safe and proper manner?
My first idea was to extract the full create table command from the dump and run it on live database. It's not so easy, as the whole dump file has over 10GB, so any operations within its content are really pain in . Yes, I know about sed and know how to use it - but I consider it the last option to choose.
Second and current idea is to create copy of this database on independent server, make a dump of the table in question and then use resulting SQL file to create the table again on the production server. I'm not quite experienced with MySQL administration tasks (well, just basic ones), but for me this option seems to be safe and reasonable.
Will the second option work as I expect?
Is it the best option, or are there any more recommendable solutions?
Thank you in advance for your help.
The simplest solution is to copy the table you deleted. There's a chance mysqld still has an open file handle to the data files you deleted. On UNIX/Linux/OS X, a file isn't truly deleted while some process still has an open file handle to it.
So you might be able to do this:
mysql> CREATE TABLE mytable_copy LIKE mytable;
mysql> INSERT INTO mytable_copy SELECT * FROM mytable;
If you've restarted MySQL Server since you deleted the files, this won't work. If the server has closed its file handle to the data file, this won't work. If you're on Windows, I have no idea.
The next simplest solution is to restore your existing 10GB dump file to a temporary instance of MySQL Server, as you said. I'd use MySQL Sandbox but some people would use a virtual machine, or if you're using an AWS environment, launch a spot EC2 instance or a small RDS instance.
Then dump just the table you need:
mysqldump -h tempserver mydatabase mytable > mytable.sql
Then restore it to your real server.
mysql -h realserver mydatabase < mytable.sql
(I'm omitting the user & password options, I prefer to put those in .my.cnf anyway)
Running WAMP localhost server With php 5.6.18 and MySQL 5.7.11 In project that im working on now i need to get some column data form information_schema.COLUMNS table, but information_schema DB is completely empty - 0 rows for every table in this DB For additional information - I have like 10 differnet DB on this MySQL, some are imported some are made from scratch in phpmyadmin.So im completely lost - tried to google but no luck.Maybe i miss something essential and trivial like some configuration of MySQL?
Execute this query:
mysql> SHOW GRANTS;
This will show you that either you are not logging in as the user you intend to use, or that this user lacks permissions on the tables in question.
In this case, the user may have no permissions at all. MySQL has a special permission called USAGE, which may seem slightly deceptively named if you aren't familiar with what it means. It means you can "use" the server -- that is, you can log in. But that is all it means. If you possess only the USAGE ON *.* privilege, this means you have permission to log in to the server, but no permissions on anything else.
The information_schema is integrated with the permissions system. You can't see information about database objects for which you don't have permissions. An empty information_schema.columns table suggests a permissions issue for the user you are using to connect to the server.
Sometimes this may be issue when you copy and paste the database's folders in mysql folder. Don't copy that way. The best way to export the databases using "export" command in "phpmyadmin" or use "mysqldump" command in mysql command line client to copy the data or export data from one to another.It will generate "yourdata.sql" file at the last , You can import that data using "export command in "phpmyadmin" . In your method is successful for "MyISAM" database driver in mysql. Modern mysql servers default database driver is "InnoDB" and it not success in when copy the database data folder on to another machine. If you have copy of previous copy of the databases from the old machine, try to export the "yourdata.sql" file using export method in "phpmyadmin" web interface.
I faced same problem when I transfer/shifted my mysql folder to other location.
And configured DB to point Mysql folder accordingly.
However, Information_schema was not getting updated though rest DB queries were running fine.I could't find proper solution but the way around was from mysql editor (like workbench) do inspect schema.
You will get an option in bottom to 'Information Outdated' and then click on Analyze table. You will find that Information_schema start calculating correct size and other details.
Hello Stackoverflow,
I was trying to connect to my MySQL database through Coda 2. I connected, created a database called 'database1' (for example), then I tried to create a table called 'user', but I get this error:
MySQL said: Table 'user' is read only
I was surprised because it had worked previously with other databases long time ago. I went to my xampp files, //xampp/mysql/data/database1/ and then I found out that user.ibd is there alone. So I first tried to change the properties of the files by disabling read-only. The problem is that when I did that, close the properties windows, and opened again I would get the read-only check box on. So I gave up on that. So I said ok, I will just create the database from my server instead. So I when to phpmyadmin, I see that database1 is created but there is no table called 'user'. So I try to create a table and I get this error:
#1813 - Tablespace for table '`database1`.`user`' exists. Please DISCARD the tablespace before IMPORT.
I then I found out I cannot even do much with phpmyadmin from my server. I tried reinstalling xampp, but it was impossible for me to remove the origianal because it was "already" in use. Please help me and thank you!
EDIT: I can apparently create databases but not tables. Just to clear that up.
You can try using CLI and logged into mysql and create a new database and a table. If it's working, there's something wrong with your phpmyadmin not mysql. Make sure you logged in as the same user (whom have root privileges) when creating the database and table.
Is it possible to duplicate a MySQL database from their files? [I know mysqldump would be the best method to duplicate a db, but that's not possible as all we have is the backed up files from the mysql folder].
We have the ibdata1 file, the ib_log* files, and the full directories for the three db's we want to restore from the backed up files (folders seem to contain all needed frm and par files). Obviously already tried just to copy all the files into /var/lib/mysql and though it appeared the structure was intact attempts to access the data were unsuccessful.
i.e. show databases will show the db's, use dbname works, and show tables properly displays the tables, but when trying to access the data from [any] table (via query) it says ERROR 1146 (42S02): Table 'dbname.dbtable' doesn't exist - despite mysql having happily showed us the table does exist when we did show tables.
Should also point out the service was stopped prior to copying files and all files chown'ed to have mysql as owner and then the service restarted prior to attempting to access the data.
To answer your question indirectly, there is some information here regarding setting up replication using a raw file copy. So I guess the answer is possibly yes, but it may depend.
http://dev.mysql.com/doc/refman/5.0/en/replication-howto-rawdata.html
Not wishing to add to your current pain, but were you relying on a backup that you have never tried / don't know how to restore?
I've got a database (all MyISAM tables) and the machine where MySQL was running is no longer bootable. However, we have all the MySQL data files from the data directory. How can I restore the data from the MYD and FRM files, or whatever other files I should be looking at in the data directory?
I've been doing some searching on this and it sounds like for MyISAM I should just be able to copy the database subdirectory from the old MySQL data directory to the new MySQL data directory. However, that's not working for me. A database with the name of the database I'm trying to recover shows up in the list of databases in phpMyAdmin, but all the tables show "in use" and have no information (e.g., number of rows, number of bytes, column information, etc.). Any operation on those tables (e.g., SELECT * FROM {table}, REPAIR {table}, CHECK {table}) returns a "no such table" error.
One of the tools I ran across in my search is DBACentral by MicroOLAP. It's got component that's supposed to restore data from FRM/MYD files, but when I tried to run it, it didn't list any tables that it could recover from my FRM/MYD files.
This is on a developer workstation that's running Vista Business 32bit. MySQL version is 5.0.27. After fixing the machine, I went and got the exact same version of MySQL (v5.0.27), thinking that if I'm just going to drop in the binary data files I should do it with the same version of MySQL. It still didn't work.
Any insights would be greatly appreciated... thanks!
-Josh
Install the same version of mysql.
Remove mysql directory from data directory of the server and copy it from the crashed server. This is the key element
copy directory of database you want to recover into data directory of new server
start mysql.
switch to mysql database: USE mysql; and run REPAIR TABLE <table name> on every table.
Do the same with database you want to recover
tip: make sure the 2 directories have the same permissions like data directory
If you did not save mysql database (mysql directory in your old server's data dir, then you can try to:
create database with the same name as database you want to recover.
Then you can create each table (it would be good to use the same structure - you'd have bigger chance of recovery).
then stop mysql server and delete files from database directory and overwrite them with files from old server
start mysql and repair each table.
I wound up giving up. I think the answer is that, with my particular version of MySQL, this doesn't work. Hopefully things have improved since then.