I am trying to backup a mysql database on a cloudfoundry app. The database in tunneled via caldecott and i can connect using mysql.
My database is 40k so far and when i use mysqldump it takes ages, i.e. after 10 min and dumping 30% - 60% of the database (depending on the run) it stops with error Lost connection to MySQL server during query (2013)
any hints?
Tricky one, I guess if your route to Cloud Foundry is a little slow you could dump each table in turn. You could do this by opting for no client when creating the tunnel and then issue the mysqldump commands yourself for the individual tables.
Failing that, you might try using VMC from a different node on the internet to see if the connection is any quicker.
Related
I have a MySQL 5.5 database in a web hosting, which I access using PHPMyAdmin (the hosting provider doesn't give me shell access). I back the database up using the "Export" function in PHPMyAdmin.
Recently, however, whenever I try to run the backup, I get an interrupted DB dump, and I see in it a PHPMyAdmin backtrace saying that "MySQL: the server has gone away". The two solutions to this, as I understand it, are:
Changing the "max_allowed_packet" parameter in the server... but I can't do that.
Repair tables... but I checked the status of the tables in the DB, including the ones where the dump usually stops, and they all seem OK.
I can always back it up in chunks, but it's a hassle to do that when the DB has about 40 tables. What can I do to fix this?
When I connect to my Remote HostGator MySQL server without specifying a database schema, it takes about 30 seconds to connect. If I specify a database schema when connecting, it takes only 1 second. In both cases, subsequent queries work fine and fast.
Doing the same with my localhost MySQL server connects fast regardless.
Does anyone know why the connection is slow when you don't specify a database schema during connect?
Unfortunately, I don't have access to the mysql config.ini file on my shared Hostgator server.
When you are connecting the Mysql server remotely without specifying the database schema, your HostGator MySQL server takes time to lookup for all users / passwords, grants to access resources to all databases and host details etc.
But, when you specifically mentioning the database, it just checks all these things for a single database and works fast.
In case of local system, it does all these things within the milliseconds as there in no any connection with a remote server, no DNS lookup, no bandwidth issue etc. hence it is faster.
Am building a project with Django REST Framework. I'm using Amazon RDS for my MySQL database, and for some reason the wait time on my calls are always around 200ms, if I connect to a local MySQL instance the time is around 8ms.
So first I thought it must be the connection time that is the problem, so I added 'CONN_MAX_AGE':60 to my database settings. This definitely made Django not create new connections looking at "SHOW PROCESSLIST;" on the DB, and brought the time down to about 190ms.
The thing is when I make queries to the RDS database vis HeidiSQL the time is around 16ms.
Anyone have any idea what is added all that time?
I have a development environment set up with remote access to a shared dev database.
I'm experiencing VERY slow response time from the remote MySQL server. I've added skip-name-resolve to the my.cnf file, restarted mysqld, and also verified that it is indeed, turned on via 'show variables' at the mysql command line.
Interestingly, if I connect to the command line interface remotely via
mysql -h IPADDRESS -u USERNAME -p
All commands are executed lightning fast.
Select * on a large table comes down the pipe instantaneously.
I'm wondering why the CLI would allow immediate response, but the php connection in my application waits 8-10 seconds before returning any data from the remote MySQL server. It's an Amazon EC2 instance, and it's the Amazon linux ami, seems to be similar to CentOS. Any ideas?
Thanks!
I've just solved same problem I was having, took me 4 days.
Apache was ok
MySQL was ok too
Problem was in my script - gethostbyaddr();
when accessing web server on the localhost is fine.
But when accessing the server from another computer takes ages, so for now I have commented out gethostbyaddr() and it is fast as if run from localhost.
I am guessing gethostbyaddr() is some sort of Windows DNS issue which I'll look into later
I'd start by determining where the slowness comes from. Is it in establishing the connection when you open the db, or is it in returning the results from the select, or both? You don't say what version of PHP you're using or what version MySQL is running on the server. My money would be on that specific combination being problematic. Make sure you're running the latest updates on your AMI.
I have encountered this problem a couple of times, in the last few days. So, it happens occasionally. I have setup mysql on a remote machine, and there is a java program on another machine querying the database to read and write records every few seconds.
I am using phpMyAdmin to administer my database. And, at times, after running some SQL query, the mysql server stops responding. Even the pinging the host machine doesn't succeed. And, I have to ask someone with physical access to the machine to boot it up again.
I checked for log files but couldn't find them in the mysql directory. Is logging disabled by default? What is missing here? And, how can I go about troubleshooting this?
EDIT:
I was able to ping the server after some while. So, the server must have been temporarily busy. It's not a specific query but things like re-ordering the data of a table serially under the browse tab.
Use a mysqlclient to make a connection and keep it open.
I personally use the mysql from the commandline.
If the server becomes unresponsive execute
SHOW PROCESSLIST;
It will list all mysql processes and will show how long queries are waiting/executing.
Optionally use the KILL statement to terminate the query that locking the tables.
KILL $pid
I'd highly recommend using MySQL's own GUI tools for database management, for a vriety of reasons:
They have full support for InnoDB tables, including Foreign Key management
You can use database-level security to make sure only you get into your data (unlike phpMyAdmin, which at best can only be root access installed behind a .htaccess password)
It is official and supported. No extra binaries run on the server, so you run no risk of it crashing and taking the server down with it (unless your query itself is locking it...)