I am new to WordPress, and I am trying to setup it at my local machine.
I am getting error like "Error establishing a database connection".
I tried all solutions from WP blogs,
created new user with all privileges
tired with root user.
created and deleted the target database multiple times.
Nothing is working.
Does anyone know anything else I can try?
Error establishing a database connection doesn't get any simpler than that. Your password, database name, user name, or host is wrong. See http://codex.wordpress.org/Common_WordPress_Errors#Error_Establishing_Database_Connection
Are you sure about using localhost as the server? Are you using MAMP or WAMP?
Try using Adminer http://www.adminer.org/ on your PC/Mac to find the database name, etc., and to admin the database when needed.
If you know can use a shell, try logging into the MySQL server and trying
mysql> show databases;
to list all databases to check your database name.
And try
mysql> mysqlserverinfo --server=root:pass#localhost -d --format=vertical
to get port info, etc. See http://dev.mysql.com/doc/mysql-utilities/1.6/en/mysqlserverinfo.html
I used MAMP for the MySQL server, and used its phpMyAdmin interface to create the database for WordPress and specify its user and password.
Host, for the new database, was "%" on the "User" tab of phpMyAdmin, which it said was supposed to allow any value, and did let me get a certain way through the process. But, I ended up going into "Login Information" under the "User" tab in phpMyAdmin, and changing "%" to "localhost".
That allowed me to finish setting up WordPress.
For future readers, if you are on OSX Yosemite (possibly other versions of OSX as well) and get "Error establishing a database connection" with a local WordPress installation, you may need to do the following:
sudo mkdir /var/mysql
sudo chmod 755 /var/mysql
sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock
Yosemite looks in the wrong location for the mysql.sock file, so creating this symlink to the correct location solves the problem.
The reason the missing symlink is a problem for WordPress specifically is because in your wp-config.php file, define('DB_HOST', 'localhost'); will not work. An alternative workaround is to change this value in your wp-config file to define('DB_HOST', '127.0.0.1');.
The OP didn't say what details they changed in their wp-config file to solve the problem (perhaps it was this DB_HOST parameter) so I just thought I'd post this since I wasted a lot of time trying to figure it out!
I tried all these suggestions and still couldn't get it to work. However, I had installed MySQL v8.0.12 and noticed that in the 'Users and Privileges' section, under the user I had set up, the 'Authentication Type' for the password was set to some kind of 'sha2' setting.
After trying 100 different things, I eventually fixed this by uninstalling then re-installing MySQL, and during the re-installation, specifically choosing the option button that refers to maintaining compatibility with previous versions of MySQL.
I think this resulted in my passwords not being automatically hashed, which enabled Wordpress to successfully connect to my MySQL database.
What worked for me:
-I moved the wp-config.php file into another folder
-Refreshed the browser and Wordpress will try to re-install
-choose a language
-A message should say Wordpress is already installed and will take you to the database setup page.
-Enter the same db name, username, password, and host (usually localhost).
-Got to www.yoursite.com/admin and you should be able to log in.
I had this issue and I have searched a lot but no one mentioned a fix like mine!
I checked my disk size and I found that my disk size was 100% used. I tried to clean up some of the files but still there were very large files taking up a lot of space. I kept looking and found that the mysql ./data folder occupied 90% of my disk space. It was the binlog files! Very large files I ended up cleaning them up using the Reset Master method. There is another method PURGE BINARY LOGS which didn't work for me. I had to use Reset Master. Just follow the steps and make sure you have a good backup. Good Luck.
Try this before anything! It fixed my issue.
sudo service mysql restart
Related
I just did a fresh install of Apache server 2.2.
Everything works. When I go to localhost I get: "It Works!"
I just installed mySQL5.5 and when I go to localhost:3306 I just get gibberish:
J���
5.5.22�'���4[LM{D~p�ÿ÷!�€����������6[I=4/+,9z{|�mysql_native_password�!��ÿ„#08S01Got
packets out of order
I see many posts on the internet with users with similar problems, but I can't figure out a solution.
Can anyone help?
The mysql service is not a web interface - you cannot connect using a browser. You will need to install a mysql client of some kind.
If you try to start phpmyadmin then do it like this:
localhost/phpmyadmin
I'm a jsp beginner.
I have a same problem with you.
I guess it's kind of port problem.
For me, I had set the port for Apache server connector as 9090.
Later, when I installed mysql, the port for mysql was 3306 as its default port.
In my jsp file,
i loaded jdbc driver like 'jdbc:mysql://localhost:9090/dbname'
and then i call 'http://localhost:9090/my.jsp' on my web browser.
That's when I got the same problem with you.
I fixed the port part in my jsp file like 'jdbc:mysql://localhost:3306/dbname'
and I could get it all right.
I think you need to check the port for your Apache server.
You can check out \conf\server.xml file in your Apache directory.
The part starts with "Connector port=8080...." in server.xml file.
If so, you need to put 'http://localhost:8080... on your browser.
Try just to write http://localhost/ without the port and it will work , Or go to your phpmyadmin and click on My websites and it will take you immediately to your localhost
I'm having exactly the same problem, so far I have :
1)Manually changed the Collation (it seemed to be defaulting to cp850)
2)altered the ini/cnf file (located under services.msc -> MySQL)
3)Changed the max_packet_size to 2G
3)rebooted the server.
As a start to this please run this script from MySQL
'SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';'
It should bring up a table of your collations, they should all read utf8
Possible causes
I want to create a dev environment of my website on the same server. But I have a 7Gb of database which contains 479 tables and I want to make a copy of that database to the new DB.
I have tried this with the help of PHPmyadmin >> Operations >> copy database to functionality. But every time it will fail and return the error
Error in processing request Error code: 500 Error text: Internal Error.
Please let me know there is any other method/ solution to copy this database to a new database from cpanel please advise
Create an export of your database. This should be easily done thru PhpMyAdmin interface. Once you downloaded the DB export, you need to create a new DB where you will put your exported data. This, too, should be easily done thru PhpMyAdmin user interface.
To upload it, we cannot use Import -> Browse your computer because it has a limit of 2MB. One solution is to use Import -> Select from the web server upload directory /var/lib/phpMyAdmin/upload/. Upload your exported data in this directory. After that, your uploaded data should be listed in the dropdown next to it.
If this fails too, you can use the command line import.
mysql -u user -p db_name < /path/to/file.sql
Limited to phpMyAdmin? Don't do it all at once
Large data-sets shouldn't be dumped (unless it's for a backup), instead, export the database without data, then copy one table at a time (DB to DB directly).
Export/Import Schema
First, export only the database schema via phpMyAdmin (uncheck data in the export options). Then import that onto a new database name.
Alternatively, you could use something like below to generate statements like below, once you've created the DB. The catch with this method is that you're likely to lose constraints, sprocs, and the like.
CREATE TABLE [devDB].[table] LIKE [prodDB].[table]
Copy data, one table at a time.
Use a good editor to create the 470 insert statements you need. Start with a list of table names, and use the good old find-and-replace.
INSERT INTO [devDB].[table] SELECT * FROM [prodDB].[table];
This may choke, depending on your environment. If it does, drop and recreate the dev database (or empty all tables via phpMyAdmin). Then, run the INSERT commands a few tables at a time.
Database Administration requires CLI
The real problem you're facing here is that you're trying to do database administration without access to the Command Line Interface. There are significant complicated details to migrating large sets of data efficiently, most of which can only be solved using tools like mysqldump.
NOTE: I have just read your comment, and as I can understand you don't have access to command line. Please check Solution Two, this will definitely work.
The only solution that will work for you (which work for me at 12GB database) is directly from the command line:
Solution One
mysql -u root -p
set global net_buffer_length=1000000; --Set network buffer length to a large byte number
set global max_allowed_packet=1000000000; --Set maximum allowed packet size to a large byte number
SET foreign_key_checks = 0; --Disable foreign key checking to avoid delays, errors and unwanted behavior
source file.sql --Import your sql dump file
SET foreign_key_checks = 1; --Remember to enable foreign key checks when the procedure is complete!
If you have root access you can create bash script:
#!/bin/sh
# store start date to a variable
imeron=`date`
echo "Import started: OK"
dumpfile="/home/bob/bobiras.sql"
ddl="set names utf8; "
ddl="$ddl set global net_buffer_length=1000000;"
ddl="$ddl set global max_allowed_packet=1000000000; "
ddl="$ddl SET foreign_key_checks = 0; "
ddl="$ddl SET UNIQUE_CHECKS = 0; "
ddl="$ddl SET AUTOCOMMIT = 0; "
# if your dump file does not create a database, select one
ddl="$ddl USE jetdb; "
ddl="$ddl source $dumpfile; "
ddl="$ddl SET foreign_key_checks = 1; "
ddl="$ddl SET UNIQUE_CHECKS = 1; "
ddl="$ddl SET AUTOCOMMIT = 1; "
ddl="$ddl COMMIT ; "
echo "Import started: OK"
time mysql -h 127.0.0.1 -u root -proot -e "$ddl"
# store end date to a variable
imeron2=`date`
echo "Start import:$imeron"
echo "End import:$imeron2"
Source
Solution Two
Also, there is another option which is very good for those who are on shared hosting and don't have command line access. This solution worked for me on 4-5GB files:
MySQL Dumper: Download (You will able to backup/restore SQL file directly from "MySQL Dumper" you don't need phpmyadmin anymore).
Big Dump: Download (Just restore from Compress file and SQL file, need BIGDUMP PHP file editing for big import $linespersession = 3000; Change to $linespersession = 30000;)
Solution Three:
This solution definitely works, it is slow but works.
Download Trial version of (32 or 64 bit): Navicat MySQL Version 12
Install -> and RUN as Trial.
After that Add your Computer IP (Internet IP, not local IP), to the MySQL Remote in cPanel (new database/hosting). You can use wildcard IP in cPanel to access MySQL from any IP.
Goto Navicat MySQL: click on Connection put a connection name.
In next "Hostname/IP" add your "Hosting IP Address" (don't use localhost).
Leave port as it is (if your hosting defined a different port put that one here).
add your Database Username and Password
Click Test Connection, If it's successful, click on "OK"
Now on the Main Screen you will see all the database connected with the username on the left side column.
Double click on your database where you want to import SQL file:
Icon color of the database will change and you will see "Tables/views/function etc..".
Now right click on database and select "Execute SQL file" (http://prntscr.com/gs6ef1).
choose the file, choose "continue on error" if you want to and finally run it. Its take some time depending on your network connection speed and computer performance.
The easiest way is to try exporting the data from phpmyadmin. It will create the backup of your data.
But Sometimes, transferring large amount of data via import/export does result into errors.
You can try mysqldump to backup the data as well.
I found a few links for you here and here.
This is the mysqldump database backup documentation.
Hope it helps. :D
You can use mysqldump as follow
mysqldump —user= —password= --default-character-set=utf8
You can also make use of my shell script, which actually wrote long back for creating back-up of MySQL database on regular basis using cron job.
#!/bin/sh
now="$(date +'%d_%m_%Y_%H_%M_%S')"
filename="db_backup_$now".gz
backupfolder=“"
fullpathbackupfile="$backupfolder/$filename"
logfile="$backupfolder/"backup_log_"$(date +'%Y_%m')".txt
echo "mysqldump started at $(date +'%d-%m-%Y %H:%M:%S')" >> "$logfile"
mysqldump —user= —password= --default-character-set=utf8 | gzip > "$fullpathbackupfile"
echo "mysqldump finished at $(date +'%d-%m-%Y %H:%M:%S')" >> "$logfile"
chown "$fullpathbackupfile"
chown "$logfile"
echo "file permission changed" >> "$logfile"
find "$backupfolder" -name db_backup_* -mtime +2 -exec rm {} \;
echo "old files deleted" >> "$logfile"
echo "operation finished at $(date +'%d-%m-%Y %H:%M:%S')" >> "$logfile"
echo "*****************" >> "$logfile"
exit 0
I have already written an article on Schedule MySQL Database backup on CPanel or Linux.
Here's how I handled that problem when I faced it... Unfortunately this only works for Mac OS.
Download Sequel Pro - Completely free, and it has worked really well for me for over a year now.
Remotely connect to your server's database. You will probably need to add your ip address to the "Remote MYSQL" section in CPANEL. If you don't have the credentials, you can probably get them from your website's config file.
Once you're in the server, you can select all of your tables, secondary click, and select Export > As SQL Dump. You probably won't need to edit any of the settings. Click "Export".
Login to your local servers database, and select "Query" from the top menu.
Drag and drop the file that was downloaded from the export and it will automatically setup the database from the sql dump.
I hope this helps. It's a little work around, but it's worked really well for me, especially when PMA has failed.
Since the requirements include PHPMyAdmin, my suggestion is to:
select the database you need
go to the "Export" tab
click the "Custom - display all possible options" radio button
in the "Save output to a file" radio button options, select "gzipped" for "Compression:"
Remove the "Display comments" tick (to save some space)
Finish the export
Then try to import the generated file in the new Database you have (if you have sufficient resources - this should be possible).
Note: My previous experience shows that using compression allows larger DB exports/import operations but have not tested what is the upper limit in shared hosting environments (assuming this by your comment for cPanel).
Edit: When your export file is created, select the new database (assuming it is already created), go to the "Import" tab, select the file created from the export and start the import process.
If you have you database in your local server, you can export it and use BigDump to inserting to new database on the global server BigDump
I suspect that PHPMyAdmin will handle databases of that size (PHP upload/download limits, memory constraints, script execution time).
If you have acccess to the console, i would recommend doing export/import via the mysql command line:
Export:
$ mysqldump -u <user> -p<pass> <liveDatabase> | gzip > export.sql.gz
And Import:
$ gunzip < export.sql.gz | mysql -u <user> -p<pass> <devDatabase>
after you have created the new dev database in e.g. PHPMyAdmin or via command line.
Otherwise, if you only have access to an Apache/PHP environment, I would look for an export utility that splits export in smaller chunks. MySQLDumper comes to mind, but it's a few years old and AFAIK it is no longer actively maintained and is not compatible with PHP 7+.
But I think there is at least a pull request out there that makes it work with PHP7 (untested).
Edit based on your comment:
If the export already exists and the error occurs on import, you could try to increase the limits on your PHP environment, either via entries in .htaccess, changing php.ini or ini_set, whatever is available in your environment. The relevant settings are e.g. for setting via .htaccess (keep in mind, this will work only for apache environments with mod_php and also can be controlled by your hoster):
php_value max_execution_time 3600
php_value post_max_size 8000M
php_value upload_max_filesize 8000M
php_value max_input_time 3600
This may or may not work, depending on x32/x64 issues and/or your hosters restrictions.
Additionally, you need to adjust the PHPmyadmin settings for ExecTimeLimit - usually found in the config.default.php for your PHPMyAdmin installation:
Replace
$cfg['ExecTimeLimit'] = 300;
with
$cfg['ExecTimeLimit'] = 0;
And finally, you probably need to adjust your MySQL config to allow larger packets and get rid of the 'lost connection' error:
[mysqld] section in my.ini :
max_allowed_packet=256M
For some reason my production DB decided to spew out this message. All application calls fail to the DB with the error:
PreparedStatementCallback; SQL [ /*long sql statement here*/ ];
Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2);
nested exception is java.sql.SQLException: Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2)
I have no idea, what this even means. There is no file #sql_3c6_0.MYI in /tmp and I can't create one with a # character for some reason. Has anyone heard about it or seen this error? What could be wrong and some possible things to look at?
The MySQL DB seems to be up and running and can be queried via the console but the application can't seem to get through to it. There was no change to the application code/files. It just happened out the blue. So I'm not even sure where to start look or what resolution tactics to apply. Any ideas?
I meet this error too when I run a wordpress on my Fedora system.
I googled it, and find a way to fix this.
Maybe this will help you too.
check mysql config : my.cnf
cat /etc/my.cnf | grep tmpdir
I can't see anything in my my.cnf
add tmpdir=/tmp to my.cnf under [mysqld]
restart web/app and mysql server
/etc/init.d/mysqld restart
Often this means your /tmp partition has run out of space and the file can't be created, or for whatever reason the mysqld process cannot write to that directory because of permission problems. Sometimes this is the case when selinux rains on your parade.
Any operation that requites a "temp file" will go into the /tmp directory by default. The name you're seeing is just some internal random name.
On Fedora with systemd MySQL gets private /tmp directory. In /proc/PID_of_MySQL/mountinfo you will find the line like:
156 129 8:1 /tmp/systemd-namespace-AN7vo9/private /tmp rw,relatime -
ext4 /dev/sda1 rw,seclabel,data=ordered
This means a temporary folder /tmp/systemd-namespace-AN7vo9/private is mounted as /tmp in private namespace of MySQL process. Unfortunately this folder is deleted by tmpwatch if not used frequently.
I modified /etc/cron.daily/tmpwatch and inserted the exclude pattern -X '/tmp/systemd-namespace*' like this:
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
-X '/tmp/systemd-namespace*' \
-X '/tmp/hsperfdata_*' 10d /tmp
The side effect is that unused private namespace folders will not be deleted automatically.
The filename looks like a temporary table created by a query in MySQL. These files are often very short-lived, they're created during one specific query and cleaned up immediately afterwards.
Yet they can get very large, depending on the amount of data the query needs to process in a temp table. Or you may have multiple concurrent queries creating temp tables, and if enough of these queries run at the same time, they can exhaust disk space.
I do MySQL consulting, and I helped a customer who had intermittent disk full errors on his root partition, even though every time he looked, he had about 6GB free. After we examined his query logs, we discovered that he sometimes had four or more queries running concurrently, each creating a 1.5GB temp table in /tmp, which was on his root partition. Boom!
Solutions I gave him:
Increase the MySQL config variables tmp_table_size and max_heap_table_size so MySQL can create really large temp tables in memory. But it's not a good idea to allow MySQL to create 1.5GB temp tables in memory, because there's no way to limit how many of these are created concurrently. You can exhaust your memory pretty quickly this way.
Set the MySQL config variable tmpdir to a directory on another disk partition with more space.
Figure out which of your queries is creating such big temp tables, and optimize the query. For example, use indexes to help that query reduce its scan to a smaller slice of the table. Or else archive some of the data in the tale so the query doesn't have so many rows to scan.
Tremendous thanks to ArturZ for pointing me in the right direction on this. I don't have tmpwatch installed on my system so that isn't the cause of the problem in my case. But the end result is the same: The private /tmp that systemd creates is getting removed. Here's what happens:
systemd creates a new process via clone() with the CLONE_NEWNS
flag to obtain a private namespace. Or maybe it calls unshare()
with CLONE_NEWNS. Same thing.
systemd creates a subdirectory in /tmp (e.g.
/tmp/systemd-namespace-XRiWad/private) and mounts it on /tmp.
Because CLONE_NEWNS was set in #1, this mountpoint is invisible to
all other processes.
systemd then invokes mysqld in this private namespace.
Some specific database operations (e.g. "describe ;") create
& remove temporary files, which has the side effect of updating the
timestamp on /tmp/systemd-namespace-XRiWad/private. Other database
operations execute without using /tmp at all.
Eventually 10 days go by where even though the database itself
remains active, no operations occur that update the timestamp on
/tmp/systemd-namespace-XRiWad/private.
/bin/systemd-tmpfiles comes along and removes the "old"
/tmp/systemd-namespace-XRiWad/private directory, effectively
rendering the private /tmp unusable for mysqld while the public /tmp
remains available for everything else on the system.
Restarting mysqld works because this starts everything over again at step #1, with a brand new private /tmp directory. However, the problem eventually comes back again. And again.
The simple solution is to configure /bin/systemd-tmpfiles so that it preserves anything in /tmp with the name /tmp/systemd-namespace-*. I did this by creating /etc/tmpfiles.d/privatetmp.conf with the following contents:
x /tmp/systemd-namespace-*
x /tmp/systemd-namespace-*/private
Problem solved.
For me this issue came after a long period of not using mysql nor the webserver. So I was sure that my settings where correct; Simply restarting the service fixes this issue; The weird part about the issue is that one can still connect to the database, and even query/add tables using the mysql tool. for example :
mysql -u root -p
I restarted using :
systemctl start mysqld.service
or
service mysqld restart
or
/etc/init.d/mysqld restart
Note : depending on the machine/environment on of these commands should restart the service.
A better way worked for me.
chown root:root /tmp
chmod 1777 /tmp
/etc/init.d/mysqld restart
That is it.
See here :http://nixcraft.com/databases-servers/14260-error-1-hy000-cant-create-write-file-tmp-sql_9f3_0-myi-errcode-13-a.html
http://smashingweb.info/solved-mysql-tmp-error-cant-createwrite-to-file-tmpmykbo3bl-errcode-13/
it's very easy, you just grant the /tmp folder as 777 permission.
just type:
chmod -R 777 /tmp
On an Ubuntu box, I started getting this error after moving /tmp to a different volume (symlink). Even after setting the required permission 1777, the issue was not resolved.
MySQL is protected by AppArmor, which was disallowing writes to the new tmp location /mnt/tmp.
I had to add the following lines to /etc/apparmor.d/abstractions/user-tmp to fix this
owner /mnt/tmp/** rwkl,
/mnt/tmp/ rw,
On debian 7.5 I got the same error. I realized the /tmp folder owner and permissions were off. As another answer suggested I did as follows (must be root):
chown root:root /tmp && chmod 1777 /tmp
I did not even have to restart mysql daemon.
I'm using mariadb. When I try to put this line at /etc/my.cnf:
[mysqld]
tmpdir=/tmp
It solved the error generated from website frontend related to /tmp.
But, it has backend problem with /tmp. Example, when I try to rebuild mariadb from the backend, it couldn't read the /tmp dir, and then generated the similar error.
mysqldump: Couldn't execute 'show fields from `wp_autoupdate`': Can't create/write to file '/tmp/#sql_1680_0.MAI' (Errcode: 2 "No such file or directory") (1)
So this one work for both front end and back end:
1. mkdir /var/lib/mysql/tmp
2. chown mysql:mysql /var/lib/mysql/tmp
3. Add the following line into the [mysqld] section:
tmpdir = /var/lib/mysql/tmp
4. Restart mysqld (eg. Centos7: systemctl restart mysqld)
Its due to access control security policies specifically when SELinux is enabled it won't allow external executables to create temporary files in the system locations.
Disable SELinux by issuing below command:
echo 0 >/selinux/enforce
You can now start mysql it wont give any permission related errror while reading/writing to /tmp or system directories.
In case you wish to enable the SELinux security back change 0 to 1 in above command.
Check permission issues, mysql config.
Also check if you haven't reached disk space, quota limits.
Note: Some systems are limiting number of files (not just space), deleting some old session files helped fixed the issue in my case.
For those using VPS / virtual hosting.
I was using a VPS, getting errors with MySQL not being able to write to /tmp, and everything looked correct.
I had enough free space, enough free inodes, correct permissions. Turned out the problem was outside my VPS, it was the machine hosting the VPS that was full. I only had "virtual space" in my file system, but the machine in the background which hosted the VPS had no "physical space" left. I had to contact the VPS company any they fixed it.
If you think this might be your problem, you could test writing a larger file to /tmp (1GB):
dd if=/dev/zero of=/tmp/file.txt count=1024 bs=1048576
I got a No space left on device error message, which was a giveaway that it was a disk/volume in the background that was full.
I had the same issue and it was caused because our DB server run out of space. Clearing up some disk space solved the issue.
My Problem I am Having:
I load the database page for one of my innoDB databases from within phpMyAdmin and it loads EXTREMELY slow. We're talking like up to 5 minutes of load time. This only happens on the MAIN page, meaning, when you view the database and the left sidebar that shows all the tables shows up.
After that initial load time, each individual table can be clicked on and load almost immediately. But those tables are loaded in an iframe without reloading the left sidebar of database tables which is why they load so quickly.
After that initial load time, each individual table can be opened in a new tab/window immediately, but doing it that way does not include the left sidebar of database tables, which I am sure is the reason they load so quickly.
What I Expect To Be Happening:
I expect to be able to load the main page of my innoDB database from within phpMyAdmin without it taking 5 minutes to load.
What I've tried:
I've had this issue for months and it drives me crazy every day. I've come to live with it actually. I simply load that initial page immediately every day, and go do something else so i don't have to watch it, because it just makes me angry.
I have my timeout set to about 15 minutes, so if I think its been longer than 10 minutes, I will open where it says "localhost" in a different tab, which brings me to the login screen, log back in, and then it brings me to the list of databases, which loads quickly. This is because if I simply load that main page, then log in, it will bring me back to that index page and i'll wait another 5 minutes for it to load. Grr..
OK so, I Googled and Googled and found tons of suggestions about making innoDB not do row counts and stuff like that. I've tried all of them. Nothing is working! :(
I found something called "$cfg['Server']['IgnoreSomeISrows'] = true;" which did not help whatsoever. I don't even know what it did, but it didn't work, so I removed it, but I forgot to remove that part and so I just left it there. No, commenting it out does not help either thank you.
Some Version Info:
OS
CentOS release 6.5 (Final)
Database:
Server: Localhost via UNIX socket
Software: MySQL
Software version: 5.1.71-log - Source distribution
Protocol version: 10
Web Server
Apache/2.2.15 (CentOS)
Database client version: libmysql - 5.1.71
PHP extension: mysqli Documentation
phpMyAdmin
Version information: 3.5.8.2, latest stable version: 4.1.5
Personally I also experience extremely slow with phpmyadmin, when I view in "View" Table. What I did is upgrade the phpmyadmin to the latest version, then my problem is solved. Maybe u can give a try for phpymadmin v4
Thank you Tom Kim for leading me to the answer.
There wasn't enough room in comments so I will elaborate with an additional answer on exactly what I did to solve my issue. I do not know why the yum version of phpMyAdmin was causing me distress.
backup your config file (if you have made one)
remove the yum version(s) of phpMyAdmin (there are 2 different ones)
download the latest version of phpMyAdmin from their website
unzip it and move it into the normal place
replace (or create) the config file
add a virtual host entry for it and make sure to restrict access to you ONLY YOUR IP ADDRESS for security purposes
restart Apache
Have some tequila to celebrate! preferably reposado because it's the best type :) (this part is VERY important)
Here is my answer in bash form:
(I assume you have phpMyAdmin or phpmyadmin already installed and configured... I won't give you a config file, but I'll give you the vhost file, its mostly based on the one from the yum version of phpMyAdmin):
mkdir /tmp/phpMyAdminNew;
cp /usr/share/phpMyAdmin/config.inc.php /tmp/phpMyAdminNew/config.inc.php;
yum remove phpMyAdmin phpmyadmin;
cd /tmp;
wget -O /tmp/phpMyAdminNew/phpMyAdmin-4.1.5-all-languages.zip http://sourceforge.net/projects/phpmyadmin/files/phpMyAdmin/4.1.5/phpMyAdmin-4.1.5-all-languages.zip;
unzip -d /tmp/phpMyAdminNew /tmp/phpMyAdminNew/phpMyAdmin-4.1.5-all-languages.zip;
mv /tmp/phpMyAdminNew/phpMyAdmin-4.1.5-all-languages /usr/share/phpMyAdminNew
cp /tmp/phpMyAdminNew/config.inc.php /usr/share/phpMyAdminNew/config.inc.php
echo -e 'Alias /my_secret_phpmyadmin_portal /usr/share/phpMyAdminNew\n\n<Directory /usr/share/phpMyAdminNew/>\n\t<IfModule mod_authz_core.c>\n\t\t# Apache 2.4\n\t\t<RequireAny>\n\t\t\tRequire ip 127.0.0.1\n\t\t\tRequire ip ::1\n\t\t\t# Require ip xxx.xxx.xxx.xxx\n\t\t</RequireAny>\n\t</IfModule>\n\t<IfModule !mod_authz_core.c>\n\t\t# Apache 2.2\n\t\tOrder Deny,Allow\n\t\tDeny from All\n\t\tAllow from 127.0.0.1\n\t\tAllow from ::1\n\t\t# Allow from xxx.xxx.xxx.xxx\n\t</IfModule>\n</Directory>\n\n<Directory /usr/share/phpMyAdminNew/setup/>\n\t<IfModule mod_authz_core.c>\n\t\t# Apache 2.4\n\t\t<RequireAny>\n\t\t\tRequire ip 127.0.0.1\n\t\t\tRequire ip ::1\n\t\t\t# Require ip xxx.xxx.xxx.xxx\n\t\t</RequireAny>\n\t</IfModule>\n\t<IfModule !mod_authz_core.c>\n\t\t# Apache 2.2\n\t\tOrder Deny,Allow\n\t\tDeny from All\n\t\tAllow from 127.0.0.1\n\t\tAllow from ::1\n\t\t# Allow from xxx.xxx.xxx.xxx\n\t</IfModule>\n</Directory>\n\n# These directories do not require access over HTTP - taken from the original\n# phpMyAdmin upstream tarball\n\n<Directory /usr/share/phpMyAdminNew/libraries/>\n\tOrder Deny,Allow\n\tDeny from All\n\tAllow from None\n</Directory>\n\n<Directory /usr/share/phpMyAdminNew/setup/lib/>\n\tOrder Deny,Allow\n\tDeny from All\n\tAllow from None\n</Directory>\n\n<Directory /usr/share/phpMyAdminNew/setup/frames/>\n\tOrder Deny,Allow\n\tDeny from All\t\nAllow from None\n</Directory>\n\n# This configuration prevents mod_security at phpMyAdmin directories from\n# filtering SQL etc. This may break your mod_security implementation.\n#\n#<IfModule mod_security.c>\n#\t<Directory /usr/share/phpMyAdminNew/>\n#\t\tSecRuleInheritance Off\n#\t</Directory>\n#</IfModule>' > /etc/httpd/conf.d/phpMyAdminNew.conf;
rm -rf /tmp/phpMyAdminNew
service httpd graceful
clear; echo -e '\n\n##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~~~##\n ##~~~~~~~~~~~~~~~~~~~##\n ###~~~~~~~~~~~~~~~###\n ####~~~~~~~~~~~####\n #####~~~~~~~~#####\n ##################\n ## TEQUILA SHOT ##\n ##################\n\n';
I'm developing a web site that is based around a MySQL db.
Because I wanted to do it off-line first, I installed WAMP server on my machine. This has Apache, an SQL server, and PHP.
I created a database on my off-line machine. The database is calledOffDB, created by user OffUser, with password OffPwd. I have exported it to an SQL file (less than one MB).
I want to import this db into my online db, which is called OnDB, created by user OnUser, with password OnUser. When I try to import in PHPMyAdmin, I get the following error:
"User OnUser doesn't have permissions to access databse OffDB"
In the off-line PHPMyAdmin, I added a new user, OnUser, with password OnPwd, and granted it all permissions to OffDB. Then I exported OffDB again, and atempted to import again. It failed with the same error. Same thing if I add new off-line user OnUser, with password OffPwd, and grant it permission - upon import I always get the error.
How can I solve that?
You need to add the OffUser and OffDB to the live server, not the other way around.
Alternatively, make a backup that does not specify the database name and users (for the latter, look for options involving GRANTs, and disable those). mysqldump should have options for that, at least if you use the mysqldump <database_name> variant, as should PHPMyAdmin.