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 get this error when I try to source a large SQL file (a big INSERT query).
mysql> source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 2
Current database: *** NONE ***
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 3
Current database: *** NONE ***
Nothing in the table is updated. I've tried deleting and undeleting the table/database, as well as restarting MySQL. None of these things resolve the problem.
Here is my max-packet size:
+--------------------+---------+
| Variable_name | Value |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+
Here is the file size:
$ ls -s file.sql
79512 file.sql
When I try the other method...
$ ./mysql -u root -p my_db < file.sql
Enter password:
ERROR 2006 (HY000) at line 1: MySQL server has gone away
max_allowed_packet=64M
Adding this line into my.cnf file solves my problem.
This is useful when the columns have large values, which cause the issues, you can find the explanation here.
On Windows this file is located at: "C:\ProgramData\MySQL\MySQL Server
5.6"
On Linux (Ubuntu): /etc/mysql
You can increase Max Allowed Packet
SET GLOBAL max_allowed_packet=1073741824;
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet
The global update and the my.cnf settings didn't work for me for some reason. Passing the max_allowed_packet value directly to the client worked here:
mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql
In general the error:
Error: 2006 (CR_SERVER_GONE_ERROR) - MySQL server has gone away
means that the client couldn't send a question to the server.
mysql import
In your specific case while importing the database file via mysql, this most likely mean that some of the queries in the SQL file are too large to import and they couldn't be executed on the server, therefore client fails on the first occurred error.
So you've the following possibilities:
Add force option (-f) for mysql to proceed and execute rest of the queries.
This is useful if the database has some large queries related to cache which aren't relevant anyway.
Increase max_allowed_packet and wait_timeout in your server config (e.g. ~/.my.cnf).
Dump the database using --skip-extended-insert option to break down the large queries. Then import it again.
Try applying --max-allowed-packet option for mysql.
Common reasons
In general this error could mean several things, such as:
a query to the server is incorrect or too large,
Solution: Increase max_allowed_packet variable.
Make sure the variable is under [mysqld] section, not [mysql].
Don't afraid to use large numbers for testing (like 1G).
Don't forget to restart the MySQL/MariaDB server.
Double check the value was set properly by:
mysql -sve "SELECT ##max_allowed_packet" # or:
mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"
You got a timeout from the TCP/IP connection on the client side.
Solution: Increase wait_timeout variable.
You tried to run a query after the connection to the server has been closed.
Solution: A logic error in the application should be corrected.
Host name lookups failed (e.g. DNS server issue), or server has been started with --skip-networking option.
Another possibility is that your firewall blocks the MySQL port (e.g. 3306 by default).
The running thread has been killed, so retry again.
You have encountered a bug where the server died while executing the query.
A client running on a different host does not have the necessary privileges to connect.
And many more, so learn more at: B.5.2.9 MySQL server has gone away.
Debugging
Here are few expert-level debug ideas:
Check the logs, e.g.
sudo tail -f $(mysql -Nse "SELECT ##GLOBAL.log_error")
Test your connection via mysql, telnet or ping functions (e.g. mysql_ping in PHP).
Use tcpdump to sniff the MySQL communication (won't work for socket connection), e.g.:
sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings
On Linux, use strace. On BSD/Mac use dtrace/dtruss, e.g.
sudo dtruss -a -fn mysqld 2>&1
See: Getting started with DTracing MySQL
Learn more how to debug MySQL server or client at: 26.5 Debugging and Porting MySQL.
For reference, check the source code in sql-common/client.c file responsible for throwing the CR_SERVER_GONE_ERROR error for the client command.
MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
arg, arg_length))
{
set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
goto end;
}
I solved the error ERROR 2006 (HY000) at line 97: MySQL server has gone away and successfully migrated a >5GB sql file by performing these two steps in order:
Created /etc/my.cnf as others have recommended, with the following contents:
[mysql]
connect_timeout = 43200
max_allowed_packet = 2048M
net_buffer_length = 512M
debug-info = TRUE
Appending the flags --force --wait --reconnect to the command (i.e. mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).
Important Note: It was necessary to perform both steps, because if I didn't bother making the changes to /etc/my.cnf file as well as appending those flags, some of the tables were missing after the import.
System used: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 for osx10.8 (i386)
Just in case, to check variables you can use
$> mysqladmin variables -u user -p
This will display the current variables, in this case max_allowed_packet, and as someone said in another answer you can set it temporarily with
mysql> SET GLOBAL max_allowed_packet=1072731894
In my case the cnf file was not taken into account and I don't know why, so the SET GLOBAL code really helped.
You can also log into the database as root (or SUPER privilege) and do
set global max_allowed_packet=64*1024*1024;
doesn't require a MySQL restart as well. Note that you should fix your my.cnf file as outlined in other solutions:
[mysqld]
max_allowed_packet=64M
And confirm the change after you've restarted MySQL:
show variables like 'max_allowed_packet';
You can use the command-line as well, but that may require updating the start/stop scripts which may not survive system updates and patches.
As requested, I'm adding my own answer here. Glad to see it works!
The solution is increasing the values given the wait_timeout and the connect_timeout parameters in your options file, under the [mysqld] tag.
I had to recover a 400MB mysql backup and this worked for me (the values I've used below are a bit exaggerated, but you get the point):
[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000
Blockquote
I had the same problem but changeing max_allowed_packet in the my.ini/my.cnf file under [mysqld] made the trick.
add a line
max_allowed_packet=500M
now restart the MySQL service once you are done.
A couple things could be happening here;
Your INSERT is running long, and client is disconnecting. When it reconnects it's not selecting a database, hence the error. One option here is to run your batch file from the command line, and select the database in the arguments, like so;
$ mysql db_name < source.sql
Another is to run your command via php or some other language. After each long - running statement, you can close and re-open the connection, ensuring that you're connected at the start of each query.
If you are on Mac and installed mysql through brew like me, the following worked.
cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf
Source: For homebrew mysql installs, where's my.cnf?
add max_allowed_packet=1073741824 to /usr/local/etc/my.cnf
mysql.server restart
I had the same problem in XAMMP
Metode-01: I changed max_allowed_packet in the D:\xampp\mysql\bin\my.ini file like that below:
max_allowed_packet=500M
Finally restart the MySQL service once and done.
Metode-02:
the easier way if you are using XAMPP. Open the XAMPP control panel, and click on the config button in mysql section.
Now click on the my.ini and it will open in the editor. Update the max_allowed_packet to your required size.
Then restart the mysql service. Click on stop on the Mysql service click start again. Wait for a few minutes.
Then try to run your Mysql query again. Hope it will work.
I encountered this error when I use Mysql Cluster, I do not know this question is from a cluster usage or not. As the error is exactly the same, so give my solution here.
Getting this error because the data nodes suddenly crash. But when the nodes crash, you can still get the correct result using cmd:
ndb_mgm -e 'ALL REPORT MEMORYUSAGE'
And the mysqld also works correctly.So at first, I can not understand what is wrong. And about 5 mins later, ndb_mgm result shows no data node working. Then I realize the problem. So, try to restart all the data nodes, then the mysql server is back and everything is OK.
But one thing is weird to me, after I lost mysql server for some queries, when I use cmd like show tables, I can still get the return info like 33 rows in set (5.57 sec), but no table info is displayed.
This error message also occurs when you created the SCHEMA with a different COLLATION than the one which is used in the dump. So, if the dump contains
CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
you should also reflect this in the SCHEMA collation:
CREATE SCHEMA myschema COLLATE utf8_unicode_ci;
I had been using utf8mb4_general_ci in the schema, cause my script came from a fresh V8 installation, now loading a DB on old 5.7 crashed and drove me nearly crazy.
So, maybe this helps you saving some frustating hours... :-)
(MacOS 10.3, mysql 5.7)
Add max_allowed_packet=64M to [mysqld]
[mysqld]
max_allowed_packet=64M
Restart the MySQL server.
If it's reconnecting and getting connection ID 2, the server has almost definitely just crashed.
Contact the server admin and get them to diagnose the problem. No non-malicious SQL should crash the server, and the output of mysqldump certainly should not.
It is probably the case that the server admin has made some big operational error such as assigning buffer sizes of greater than the architecture's address-space limits, or more than virtual memory capacity. The MySQL error-log will probably have some relevant information; they will be monitoring this if they are competent anyway.
This is more of a rare issue but I have seen this if someone has copied the entire /var/lib/mysql directory as a way of migrating their DB to another server. The reason it doesn't work is because the database was running and using log files. It doesn't work sometimes if there are logs in /var/log/mysql. The solution is to copy the /var/log/mysql files as well.
For amazon RDS (it's my case), you can change the max_allowed_packet parameter value to any numeric value in bytes that makes sense for the biggest data in any insert you may have (e.g.: if you have some 50mb blob values in your insert, set the max_allowed_packet to 64M = 67108864), in a new or existing parameter-group. Then apply that parameter-group to your MySQL instance (may require rebooting the instance).
For Drupal 8 users looking for solution for DB import failure:
At end of sql dump file there can commands inserting data to "webprofiler" table.
That's I guess some debug log file and is not really important for site to work so all this can be removed. I deleted all those inserts including LOCK TABLES and UNLOCK TABLES (and everything between). It's at very bottom of the sql file. Issue is described here:
https://www.drupal.org/project/devel/issues/2723437
But there is no solution for it beside truncating that table.
BTW I tried all solutions from answers above and nothing else helped.
I've tried all of above solutions, all failed.
I ended up with using -h 127.0.0.1 instead of using default var/run/mysqld/mysqld.sock.
If you have tried all these solutions, esp. increasing max_allowed_packet up to the maximum supported amount of 1GB and you are still seeing these errors, it might be that your server literally does not have enough free RAM memory available...
The solution = upgrade your server to more RAM memory, and try again.
Note: I'm surprised this simple solution has not been mentioned after 8+ years of discussion on this thread... sometimes we developers tend to overthink things.
Eliminating the errors which triggered Warnings was the final solution for me. I also changed the max_allowed_packet which helped with smaller files with errors. Eliminating the errors also sped up the process incredibly.
if none of this answers solves you the problem, I solved it by removing the tables and creating them again automatically in this way:
when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT
then just use this backup with your db and it will remove and recreate the tables you need.
Then you backup just data, and do the same, and it will work.
How about using the mysql client like this:
mysql -h <hostname> -u username -p <databasename> < file.sql
im trying to parse pdf to text via PHP and XPDF (pdftotext.exe). On my localhost everythings works well, but when im trying to move everything on server, im getting into troubles.
First of all i checked some settings on server and safe_mode is off, exec is not disabled and permissions are rwxrwxrwx.
Then im trying this
$command = "\\\\149.223.22.11\\cae\\04_Knowledge-base\\tools\\pdftotext.exe -enc UTF-8 ". $fileName . " \\\\149.223.22.11\\cae\\04_Knowledge-base\\output.txt";
$result = exec($command,$output,$args);
echo shell_exec($command);
which isnt working. When i look into $result, $output, are empty, but $args returns 1 which coresponds to Incorrect function by this document windows system error codes
Whole command looks like \\149.223.22.11\cae\04_Knowledge-base\tools\pdftotext.exe -enc UTF-8 \\149.223.22.11\cae\04_Knowledge-base\testpdf\04_egerland_final_paper.pdf \\149.223.22.11\cae\04_Knowledge-base\output.txt and when is dirrectly inputed into commandline, its working.
So im a bit out of ideas. Have someone any hint?
edit 20160201 - aditional trying
So i made aditional tests and when im trying to run similar command with exec from localhost (target .exe file, input and output file is in same location, only im using localhost not server) its working. Im now checking differences in server settings. So can here be problem, that localhosts Server Api is Apache 2.0 Handler and server is CGI/FASTCGI?
So it was all mistake on my side. I badly checked IIS permissions and forgot to assign user to virtual directory which i wana to access. So my only advice and more wisdom from this is to double (maybe triple) check if you have all permissions set correctly.
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
I have a file named index.php which using a mysql server gets a simple username. The mysql server is running on centOS and I have two different systems running apache serving as web servers.
One is my own windows pc using a "wamp" solution which uses the mysql server refereed before and the other is the centOS server itself.
I use this so I can develop in my laptop and run the final on the centOS box.
The problem is this:
Accessing centOS box I get (on hxxp://centos):
out_sider 1lu�s 2oi
Using wamp on windows I get (on hxxp://localhost):
out_sider 1luís 2oi
The mysql database is configured correctly seeing that both use the same and I used svn repository to move files from windows to centOS so the file is the same.
Does anyone have any suggestions?
Thanks in advnce
My first guess is its probably a locale thing, try adding or updating locale settings of the centOS, or try controlling it from PHP.
str = iconv(mb_detect_encoding(str)/*or insert the encoding type if you know it*/, "UTF-8", str);
and try also:
str = mb_convert_encoding (str, "UTF-8");
Also try connecting and querying the MYSQL server directly, to rule out the fact that it maybe the MYSQL table charset (on centOS) or something.