0

I have added a new column to a mySQL database table and added a form field for the new value to the PHP page which is used to display the values of the database fields for a selected record. The application (which is hosted on a shared server of a provider) itself is still working fine (access to mySQL tables is also fine), but when invoking the modified page with the new field, it gives the above mentioned error, in more detail:

Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002] Connection refused in /kunden/XXX/webseiten/shoes/showrun.php:55 Stack trace: #0 /kunden/XXX/webseiten/shoes/showrun.php(55): PDO->__construct('mysql:host=mysq...', 'username', 'password') #1 {main} thrown in /kunden/XXX/webseiten/shoes/showrun.php on line 55

The strange thing is, that the code on line 55 which constructs a new PDO:

$pdo = new PDO('mysql:host=mysql5.my-domain.com;dbname=XXX', 'username', 'password');

is unchanged and exactly the same as in other, unmodified PHP pages, which still work without any errors.

Even more strange is, that when I roll back the changes in the PHP file and upload it again to the server (via WebFTP), so that it is identical to the one which was in place before (and worked without error) the same error message is displayed!

So the problem seems to be caused just by modifiying/uploading the file on the server. The rights on the file and its name and location are exactly like before, when everything was fine.

[Remark: username, password, my-domain and XXX are not the actual values and replaced for security reasons]

What can be the probable reason for this problem? Any help is much appreciated.

@Wilson Hauck: Like requested:

A)
Variable_name                   Value
character_set_connection        utf8mb4
collation_connection            utf8mb4_unicode_ci
connect_timeout                 12
disconnect_on_expired_password  ON
init_connect                    SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci
max_connect_errors              100
max_connections                 400
max_user_connections            50
performance_schema_session_connect_attrs_size   512

B)
Variable_name                   Value
Aborted_connects                77783
Connection_errors_accept        0
Connection_errors_internal      0
Connection_errors_max_connections 0
Connection_errors_peer_address  0
Connection_errors_select        0
Connection_errors_tcpwrap       0
Connections                     12942161
Locked_connects                 0
Max_used_connections            52
Max_used_connections_time       2022-06-22 23:23:19
Performance_schema_session_connect_attrs_lost 0
Ssl_client_connects             0
Ssl_connect_renegotiates        0
Ssl_finished_connects           0
Threads_connected               2

C)
Variable_name                   Value
Uptime                          4618314
emmi59
  • 1
  • 2
  • It seems to be related to host name or username/password. Check host name is correct or use localhost instead – PoryaGrand Jul 23 '22 at 17:26
  • @PoryaGrand: Like mentioned before, the same connect information works with other PHP pages of the same application. And changing the host to localhost doesn't change a thing. But thanks for your comment. – emmi59 Jul 23 '22 at 17:35
  • Please consider posting TEXT results of A) SHOW GLOBAL VARIABLES LIKE '%connect%'; and B) SHOW GLOBAL STATUS LIKE '%connect%'; and C) SHOW GLOBAL STATUS LIKE 'uptime'; – Wilson Hauck Jul 23 '22 at 18:21
  • Obviously, there is no rational explanation to the described behavior. You somehow maimed your php file **and we have no means to tell you how**. What I would question is why new PDO is written in the every file and not included as it should be – Your Common Sense Jul 23 '22 at 18:26
  • @YourCommonSense: Your point regarding including the PDO creation is valid, to my excuse I have to say that the application is quite old (some years) and at this point I am afraid of changing more files now as long as I dont know the cause of the error. I have edited 8 files related to the new feature and only afterwards found out that all these files are somehow "maimed"... – emmi59 Jul 23 '22 at 18:41
  • @emmi59 Consider from MySQL COMMAND PROMPT SET GLOBAL max_user_connections=400; to match user_connections - might be your ticket. Investigate WHY you have 77,783 aborted_connects in 54 days. That is more than 1,000 unhappy connected users that were cut off EVERY DAY for some reason. – Wilson Hauck Jul 23 '22 at 18:47
  • @emmi59 Since you are using a SHARED hosted server, you may have to ask your provider to make this change in the 'shared' global configuration. – Wilson Hauck Jul 23 '22 at 18:54
  • @WilsonHauck don't you understand that it allegedly happens per-file basis, not per connect? Given the other file connects EVERY TIME all right, how should your suggestion help? – Your Common Sense Jul 23 '22 at 19:07
  • Do you test your code locally when developing? If so, to which database server it connects? – Your Common Sense Jul 23 '22 at 19:10
  • Could it be you are trying to exceed 50 max_user_connections and the connection is being refused? – Wilson Hauck Jul 23 '22 at 19:10
  • @WilsonHauck please read the question: **unmodified PHP pages still work without any errors.** BESIDES, when max_user_connections is exceeded, the error message is **different.** The Connection refused error is a **network** error, not a database error – Your Common Sense Jul 23 '22 at 19:12
  • I have a feeling that you are changing the database credentials when developing locally and don't change it back when uploading on the server. What I would suggest is to copy the connection code from the working file, put it in the separate file, and then include this file into the not-working script instead of that manually created connection – Your Common Sense Jul 23 '22 at 19:26
  • @all: The other question to which my question has been associated, does not exactly solve my problem, BUT I found the cause of the problem anyways. Sometime earlier this year the provider upgraded to a new MySQL version and by doing this, changed the hostname of the mysql server. And to keep things running, he obviously ran a script on the server which replaced the old host name with the new one. Of course, this only happened on the server and NOT in my local source directory. So when editing the PHP file to add the new field, I in fact edited an outdated version of the file and then uploaded – emmi59 Jul 23 '22 at 20:22
  • Well the other question actually does. It literally says you have to provide correct credentials. You didn't expect an answer telling you that your provider did change credentials in your code, did you? – Your Common Sense Jul 24 '22 at 05:29

0 Answers0