According to this document
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-remote-database-to-optimize-site-performance-with-mysql
To connect from external ip to mysql I have to change to public ip of the server
bind-address = your_database_IP
I put here my public IP server.
So my question is does it lose performance. Does it understand that this ip actually its on ip so it will act like local database? Or it will think it is external ip so goes in internet and comes back again ?
Connection possibilities:
Socket -- the fastest, but only works when client and server are on the same hardware (or, in some cases, the same VM)
TCP/IP on the same hardware, but through the TCP/IP stack, so slightly slower for queries.
Domain name lookup, and other issues dealing with establishing remote (not same machine) connection. This action is done only during connecting. So, it might slow down establishing the connection, but not the queries. Note: the translation from "foo.com" to "1.2.3.4", if needed, is done once, only during the establishment of the connection. An explicit IP address is faster, but less flexible.
Proxy server / load balancer / etc -- these sit between the client and the server, and add some delay (and some benefit) during all queries.
Connection pooling in the client -- some overhead or savings on connecting.
Connection pooling in the server -- some overhead or savings on connecting. (Whether to reuse a process (thread) versus create a new one.)
The beauty of TCP/IP is that you can send a message to any IP address you know; the 'network' will figure out how to get there (anywhere in the world). It may take one route now, another route the next time. So it is "reliable", but inconsistent is speed. It also has a good level of "guaranteed delivery". Once connected, that is what queries do -- send to a known IP address and get replies.
(See the other comments for more info.)
Related
we have mysql-server(5.5.47)that hosted on physical server. It listen external internet interface(with restrict user access), mysql server intensively used from different places(we use different libraries to communicate with mysql). But sometimes whole mysql server(or network) stuck and stop accept connection, and a clients failed with etimedout(connect)/timeout(recv), even direct connection from server to mysql with mysql cli not working(stuck without any response — seems to be try to establish connections).
First thought was that it is related to tcp backlog, so mysql backlog was increased — but this not help at all.
Issue not repeatable, so last time when this issue happened we sniff traffic, and what we get:
http://grab.by/STwq — screenshot
*.*.27.65 — it is client
*.*.20.80 — it is mysql server
From session we can assume that tcp connection established, but server retransmit SYN/ACK to client(from dump we see that server receive ACK, why retransmit ?), but in normal case mysql must generate init packet and send to client, after connection was established.
It is only screen from 1 session, but all other sessions mostly same, SYN -> SYN/ACK -> ACK -> and server retransmit SYN/ACK up to retries_count.
After restart mysql all get normal immediately after restart. So not sure it is related to network or mysql.
Any thoughts would be appropriate.
Thank you!
I saw the following statement on StackOverflow and was wondering about its meaning:
If you connect via 'localhost', the connection will automatically be established via the MySQL socket, which is really cheap anyways.
The discussion thread was pretty old, so I didn't want to comment on it.
Basically what I understand is, that using 'localhost' when connecting to your mysql database has certain advantages - such as "automatically established connections via MySQL socket". What does that mean exactly?
Currently I'm using
mysql_connect("73.21.24.201", [...]);
(changed to a random IP Address)
Does it make any difference? Can I change it to "localhost" without having to worry about it? (The mysql server is obviously on the same server/ip address as my website/application)
When you connect to 'localhost' you'll connect using a Unix socket, which is just a communications channel for the local processes to use. The big advantage of this is that you can disable networking completely in MySQL, and negate any processing overhead and security risks that go along with that.
When MySQL starts, it creates a socket file (typically at a place like /var/lib/mysql/mysql.sock) that your client program needs to be able to find. On a typical PHP (you didn't say, but I'm assuming) setup, it should know where to find this socket. If not, check /etc/my.cnf and /etc/php.ini to make sure the values match.
And finally, if that is PHP, stop using mysql_*() functions in PHP right now! They have been deprecated for years and are inefficient and insecure.
Consider a MySQL server that accepts remote connections.
What happens if you have a publicly facing MySQL server, and grant access to e.g.:
'sqluser'#'localhost'
If an attacker now sets his rDNS to "localhost", will he able to access this database?
Is there an extra check that also tries to resolve the rDNS back to the IP?
Regardless, database servers shouldn't be internet facing, but this a what-if-question.
It appears that MySQL uses forward-confirmed reverse DNS (FCrDNS) to counter these kind of attacks.
Most of the logic for the hostname checks can be found in sql/hostname.cc. Moreover, several checks are also performed to make sure that the rDNS doesn't contain an IP or is otherwise poisoned.
I'm running EC2 with MySQL RDS to serve dynamic websites' content.
The server was down due to 'too many connection' error on RDS database.
As it was urgent, I restart database server straight away and the problem gone.
However, I'm unable to see what queries produce those connection (as I didn't run SHOW PROCESS LISTS before reboot RDS).
CloudWatch show 250+ connections during period of issue which is obviously huge distinction from normal operating on other days.
I try to address the issue by see log in RDS, but there is quite a minimal message there.
The error message
2014-05-03 06:10:08 3628 [Warning] IP address '173.244.206.19' has been resolved to the host name '173.244.206.19.static.midphase.com', which resembles IPv4-address itself.
From above, 173.244.206.19 is not in our IP list both public and private. (but connection open to 0.0.0.0 secured with password which I'm going to limit IP remote in security group soon)
Questions
Is 173.244.206.19.static.midphase.com is something to do with RDS by default. I think this is obviously an attack sign but just would like to confirm.
What does 'resembles IPv4-address itself' mean? As this is RDS database server only, why server does need to resolve DNS?
Are there any way to digging into this for further detail (e.g. to see specific query).
I'm going to prevent this by only limit the IP access along with CloudWatch alarm setting for 10+ connections. Anything else I should do.
Thank you for reading through this guys. I'm the only developer in company start-up which take care for all front-end/backend/application/network. Therefore, apology if there are dummy questions out here.
However, your help would be really appreciated and will save a bit of my life writing the report.
You are maybe the target of a DDOS attack or a brute-force password discovery attempt.
I would report this to AWS support - as they can help to mitigate the effect of the attack.
As a best practice, we do not recommend to use 0.0.0.0/0 as source IP address for incoming connection rule in Security Group.
Try to restrict which IP addresses are authorised to connect to your database.
If you are accessing from on prem network, specify only your on-prem address range.
If you're accessing your database from an app server installed on EC2, use the ID of the App Server Security Group (sg-xxxx) as source authorised to connect to your database.
In Comet/Reverse Ajax/PubSub underlying technology/fundamental is Long polling. So connection is kept open for a minute or so..
And as per my little knowledge about networking and OS, TCP/IP supports only 65535 ports, so my question is how any server can support more then 65535 connections concurrently?
In application I am building, All users are going to connect at same time, and wants live updates from server.. like stock treading realtime updates..
Cheers,
You are correct in that there are 65535 unique port numbers, but a TCP server application allows many clients to connect to the same port on a server. For example, in a web server all clients connect to port 80. Connections are uniquely identified by the 4-tuple (src-address, src-port, dest-address, dest-port).
You will definitely want to read about the so-called C10K problem when designing your implementation.
each connection is attributed as follows:
source ip (could be any)
source port (could be any in range 1024-65535)
destination ip (your server ip)
destination port (specific port your app is running on)
so the number of connections to the server is limited by the number of all possible ips multiplied by the 64000 (roughly). no server can handle that as of yet... :)