Shulou(Shulou.com)05/31 Report--

This article is to share with you about how to solve Syn Flooding problems when MySQL databases encounter. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Syn attack is the most common and easy to be used attack method, taking advantage of the defects of TCP protocol, sending a large number of fake TCP connection requests, often using fake IP to send a large number of SYN packets, the attacked server responds to SYN+ACK, because the other side is a fake IP, the packet will never be received and will not respond, resulting in a large number of SYN_RECV semi-connections of the attacked server, and the default 5 response handshake packets will be retried It is full of TCP waiting for the connection queue, and the resources are exhausted, so that normal business requests cannot be connected.

Syn attacks are common in application servers, but it should be difficult for database servers to encounter similar attacks in the intranet, but sometimes if the application is not in the correct posture to connect to the database, it will be regarded as a Syn attack on the database side and refuse to establish a connection.

[problem description]

When the database suddenly rejects the link, the application reports an error. At the time when the problem occurs, you can see the following error message in the operating system log of the database server, namely / var/log/messages:

Kernel: possible SYN flooding on port 3306. Sending cookies.

[problem Analysis]

On the point of the problem, from the monitoring indicators of the database, the index of Threads Connected has increased. This is also very obvious, because for the database, Syn Flooding means that the application program suddenly initiates a connection to the database, and the operating system cannot handle it, so report to Syn Flooding. From the performance index of the database, the number of connections will definitely have a sudden increase. The response is to analyze how these sudden increases come from, to cut peaks and fill valleys to make connections more stable.

[solution]

On the database server, make the following adjustment: this adjustment means: increase the buffer of TCP semi-connection. The default value is 2048, and we adjust it to 8192 to make the system more resistant to sudden pressure. Tcp_syn_retires and Tcp_synack_retires defaults to 5, which means the server needs to send packets five times before the retry is terminated. We adjust this parameter to 2. 5. Retry only once to allow the faulty package to go wrong as early as possible to reduce the number of cached connections.

Echo 8192 > / proc/sys/net/ipv4/tcp_max_syn_backlog

Echo 2 > / proc/sys/net/ipv4/tcp_syn_retries

Echo 2 > / proc/sys/net/ipv4/tcp_synack_retries

This parameter adjustment takes effect immediately and there is no need to restart. Of course, after the server is restarted, these parameters will also fall back to their default values. After this adjustment, the anti-pressure ability of the database side has been strengthened, but the problem has not been completely solved.

We also make adjustments on the client side:

In order to reduce the pressure on the number of connections to the database, we usually recommend that the connection pool be configured as follows:

TestWhileIdle= "false". Do not check the health of the connection string when you are idle

MinIdle= "0". The minimum number of idle connections in the connection pool

MaxAge= "30000". A link can be recycled in more than a few milliseconds.

InitialSize= "1". The minimum number of initial connections in the connection pool

TimeBetweenEvictionRunsMillis= "5000". Run interval of recycling threads (milliseconds)

For the current scenario, we recommend that you increase the minIdle parameter from 0 to 5. Let the connection pool usually have 5 free connections, so that these 5 free connections will be used first when initiating a request to the database. To achieve the function of cutting peak and filling valley. Of course, the side effect is that the usual number of connections to the database will increase. The specific adjustment to how much is appropriate needs to be combined with the actual database connection load. For. Net programs, there are also corresponding connection pooling parameters that can be adjusted: the minPoolSize parameter can also be adjusted to 5. 5.

After this adjustment, basically most of the database Syn Flooding problems can be solved.

Of course, these are all means of tuning and can only be minor improvements to the system. Improve the ability to resist pressure. The final analysis depends on where the connection pressure comes from. And why there is a sudden need to establish a large number of connections to the database. For such a sudden scenario, whether it is appropriate to use a database. The alternative is to add a buffer with Redis in front of it. Avoid sudden connection requests to the database. This involves the transformation of the application.

Thank you for reading! This is the end of the article on "how to solve the Syn Flooding problem when the MySQL database encounters Syn Flooding". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it out for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.