Re: can't connect to remote mysql db at a particular time period

On 03/06/15 08:03, Anuj Agarwal wrote:
> ERROR 2003 (HY000): Can't connect to MySQL server on 'domain name' (110)
>
> I tried doing the telnet on the mysql port and it's also not working. Giving me connection timeout.
>

Timeout is more indicative of congestion than anything else. If a service is simply not attached to a port, a server ill in general refuse the connnection.

E;g. try telnet to some random port and you will generally see 'connection refused'

A time out means a TCP connection packet was sent and no packet - ACK or NACK - was returned.

That could be for several reasons, of which a non-exhaustive list follows:

• a connection between you and the target is broken. - test with ping or any other method to ascertain the target is reachable.
• a connection between you and the target is congested and suffering severe packet loss. whilst retranmits of established connections are able to retry transmission, actual attempts to set up a stream connection will simply try a few times and then time out, if no response is recieved.
• a connection between you and the target has been deliberately configured to silently drop packets. This is often the case for firewalls.
• the daemon on the receiving end (mysqld) has been swapped out due to memory shortage, to the point where it simply never gets swapped back in in time to send a sensible response. I am not an expert on Linux swap strategy, so I cannot say whether enough daemon would remain in memory to at least respond.
• the daemon at the other end is so short of memory that it cannot fork() to create a process to respond to your demands, without swapping something else out, and the result is that it start to do that, but runs out of time before the client end gives up waiting.

For both the above conditions you should try and run a console on the remote server running e.g. top, to ascertain memory status

• the daemon at the other end is IO bound, due to processing an enormous query, and cannot respond till the disk subsystem has 'caught up'.
• the daemon at the other end is simply CPU bound, and cannot respond fast enough.

For both the above conditions you should try and run a console on the remote server running e.g. top, to ascertain IO and CPU status.

To summarise, something is running out of resource. Memory, CPU or IO bandwidth, or network bandwidth. Or something is deliberately interfering with the network.

If you are at the time able to connect locally to the server using a local mysql client, that suggests its network related.

It could be faulty hardware.

The technique is to use the tools like top to try and see the server general state when the problem occurs, and scan the logs looking for clues

> I have two slaves on remote servers which are working fine during that period of time.
>
> I am running Ubuntu Linux on Microsoft Azure machine. I checked the firewall is not configured to reject connections at any period of time.

-- 
New Socialism consists essentially in being seen to have your heart in 
the right place whilst your head is in the clouds and your hand is in 
someone else's pocket.