Objective: Update prices of products between databases: Shop's server DB has the latest prices and website's DB need to be updated accordingly with any "each 24 hours" script (I'll look this up later).
I'm using Ionos as hosting for the website, and The server is shared, so I can't touch php.ini or add files for php.
I'm trying to connect to a SQL server DB, but since it requires dll libraries to be installed and to modify the php.ini, I can't do that.
I can't either make it from the other side, If I make it from an external server in order to update the prices of the website, they don't allow to make connections out of the context of the server.
So, I know that the solution is to upgrade the hosting's plan and pay more and so on, so I have a virtual server for my own. But before doing that, is there any other way to establish this connection without using php? Is there something else that allows me to create a DB connection?
The fatal errors appears as soon as sqlsrv_connect is read as there is no library to load this function.
$serverName = "x, 0000";
$connectionInfo = array( "Database"=>"x", "UID"=>"x", "PWD"=>"xxx");
$conn = sqlsrv_connect( $serverName, $connectionInfo);
Edit: Comes to my mind... Maybe a solution would be to tell this php file to load php.ini and so on from another server if that's possible?
You could possibly call a JSON endpoint on your DB server (secure the endpoint though (out of scope for my answer)) https://3v4l.org/Gpi28
<?php
// MSSQL server side
$data = [
1 => 'hello',
2 => 'world',
];
// Imagine $data above is the array of rows returned by the db query
header('Content-Type: application/json');
echo json_encode($data);
exit;
// IONOS Side
$json = file_get_contents('http://your-database-server/some/url/or/other');
$data = json_decode(true);
// Now do your updates
// NB This is an INSECURE example, people who know the URL can see this data!
The connection to the database is very fragile, so I try to test the connection before make a link to it. I found pg_connect and mysql_ping and how-do-i-ping-the-mysql-db-and-reconnect-using-pdo, but none has anything to do with MSSQL or function that I can use.
Is there a way I can test the database before I connect to it?
You might set the timeout to a very small number and call something like
SELECT 1;
or
SELECT GETDATE();
and see, if there is some result coming back...
If the connection is broken, such tiny requests should break as well.
In case fragile does not mean broken, you might measure a standard call and compare the execution speed...
You could try to ping the server + corresponding port to see if server accepts connections.
$host = '127.0.0.1'; // ip address, could be localhost
$port = 1433; // your mssql port
$timeout = 1; //time to wait in seconds for response
if($fp = fsockopen($host,$port,$errCode,$errStr,$timeout))
{
// Server is OK - responding
} else {
// Server not respoded on given port in given time limit
}
fclose($fp);
I have a page where few thousands of users can hit a method at the same time . I do have following code where I connect every time . Since this will go to a seperate memcache server will this cause slowdowns is there a way to connect just once and reuse that connection ? Do I have to close connection after every request ?
$primary_connected = $memcache_primary->connect($primary_memcache_server, 11211);
if($primary_connected){
$data = $memcache_primary->get($key);
if ($data != NULL) {
return data;
}
}
else{
/////Get data from database
}
If you are using the PHP memcached class (the one with the d on the end, not memcache) then yes, you can open a persistent connection.
You can pass a persistent ID to the constructor which will open a persistent connection and subsequent instances that use the same persistent ID will use that connection.
$memcached = new Memcached('method_name_or_persistent_identifier');
$memcached->addServer(...);
// use it
Hope that helps.
See Memcached::__construct() for more details.
I have a Master - Slave setup for a web application written in PHP. I have a pool of slaves I use for reading, and a Master that is used for writes (and reads if a write has been sent this request). I would like to incorporate an automated system for removed crashed servers from the read pool. Currently I am using:
foreach($readers as $reader)
{
$fp = #fsockopen($reader['host'],3306,$errno,$errstr,1);
if(!$fp)
{
//Remove from pool
}
unset($fp);
}
My primary question is there a more reliable method. I have had quite a few false positives, and vice versa because it is not actually checking for a MySQL server, but rather just a connection on port 3306. Is there a way to check for a MySQL server without raising an exception, which is the behaviour of the PDO and MySQLi extensions in PHP.
You could just use mysql_connect() and check the result for false, and close the connection right away on success. You can make a dummy account with no privileges for that if you like.
That's really the only reliable way, especially if you want to distinguish a running MySQL server from any other random process listening on port 3306.
You could use mysql_ping() to check if a current DB Connection you have open is still alive
Here is the example posted at http://www.php.net/manual/en/function.mysql-ping.php
<?php
set_time_limit(0);
$conn = mysql_connect('localhost', 'mysqluser', 'mypass');
$db = mysql_select_db('mydb');
/* Assuming this query will take a long time */
$result = mysql_query($sql);
if (!$result) {
echo 'Query #1 failed, exiting.';
exit;
}
/* Make sure the connection is still alive, if not, try to reconnect */
if (!mysql_ping($conn)) {
echo 'Lost connection, exiting after query #1';
exit;
}
mysql_free_result($result);
/* So the connection is still alive, let's run another query */
$result2 = mysql_query($sql2);
?>
The best way to check if any service is alive is to actually use it. So for MySQL try to connect and execute some fast query, for web server try to fetch some file, for PHP try to fetch some simple script...
For MySQL master/slave setup, one of the solutions is to actually check the state of replication. You can check how many transactions is the slave behind master and decide to stop using that slave when/while it has old data. (I don't do the replication myself, but I think you need to compare the variables Read_Master_Log_Pos and Relay_Log_Pos)
I recently discovered that a sql query that was running fine earlier is now timing out after 60 seconds and throwing an error. The query is slow but runs as part of a nightly job so that's not a problem in itself (so please don't suggest I optimize it).
I'm able to reproduce the error consistently by running "select SLEEP(120);" from PHP as shown below. However, running the same statement from a MySQL client is successful (returns 0). I've tried adjusting wait_timeout (set to 28800), but have had no luck. I've also rebooted both the db server and machine itself.
The fact that it always times out at exactly 60 seconds suggests to me that it is likely to be a setting and not a limited resources issue.
I'm running:
Windows Server 2003
MySql 5.1.36-community
PHP 5.3
Below are my test code, the output and the results from SHOW VARIABLES
Thanks!
CODE:
set_error_handler("sqlErrorHandler");
set_time_limit(12000);
$link = mysql_connect("$MYSQL_Host","$MYSQL_User","$MYSQL_Pass");
mysql_select_db($MYSQL_db, $link);
echo "mysql_ping = " . (mysql_ping($link) ? "LIVE" : "DEAD") . "<br /><br />";
$sql = "SELECT SLEEP(120);";
$start = microtime(true);
mysql_query($sql, $link);
echo "**query done**<br />";
allDone();
function allDone(){
global $start, $sql;
$end = microtime(true);
echo "sql : $sql<br />";
echo "elapsed : " . ($end - $start) . "<br />";
echo "<br />";
}
function sqlErrorHandler($errno, $errstr, $errfile, $errline){
global $link;
echo "Error : $errno<br />$errstr<br />";
echo "mysql_ping : " . (mysql_ping($link) ? "LIVE" : "DEAD") . "<br />";
echo "<br />";
allDone();
}
OUTPUT :
mysql_ping = LIVE
Error : 2
mysql_query() [function.mysql-query]: MySQL server has gone away
mysql_ping : DEAD
sql : SELECT SLEEP(120);
elapsed : 60.051116943359
Error : 2
mysql_query() [function.mysql-query]: Error reading result set's header
mysql_ping : DEAD
sql : SELECT SLEEP(120);
elapsed : 60.0511469841
**query done**
sql : SELECT SLEEP(120);
elapsed : 60.051155090332
SHOW VARIABLES:
Variable_name=Value
auto_increment_increment=1
auto_increment_offset=1
autocommit=ON
automatic_sp_privileges=ON
back_log=50
basedir=C:\\Program Files\\MySQL\\MySQL Server 5.1\\
big_tables=OFF
binlog_cache_size=32768
binlog_format=STATEMENT
bulk_insert_buffer_size=8388608
character_set_client=utf8
character_set_connection=utf8
character_set_database=latin1
character_set_filesystem=binary
character_set_results=utf8
character_set_server=latin1
character_set_system=utf8
character_sets_dir=C:\\Program Files\\MySQL\\MySQL Server 5.1\\share\\charsets\\
collation_connection=utf8_general_ci
collation_database=latin1_swedish_ci
collation_server=latin1_swedish_ci
completion_type=0
concurrent_insert=1
connect_timeout=10
datadir=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\
date_format=%Y-%m-%d
datetime_format=%Y-%m-%d %H:%i:%s
default_week_format=0
delay_key_write=ON
delayed_insert_limit=100
delayed_insert_timeout=300
delayed_queue_size=1000
div_precision_increment=4
engine_condition_pushdown=ON
error_count=0
event_scheduler=OFF
expire_logs_days=0
flush=OFF
flush_time=1800
foreign_key_checks=ON
ft_boolean_syntax=+ -><()~*:""&|
ft_max_word_len=84
ft_min_word_len=4
ft_query_expansion_limit=20
ft_stopword_file=(built-in)
general_log=OFF
general_log_file=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1.log
group_concat_max_len=1024
have_community_features=YES
have_compress=YES
have_crypt=NO
have_csv=YES
have_dynamic_loading=YES
have_geometry=YES
have_innodb=YES
have_ndbcluster=NO
have_openssl=DISABLED
have_partitioning=YES
have_query_cache=YES
have_rtree_keys=YES
have_ssl=DISABLED
have_symlink=YES
identity=0
ignore_builtin_innodb=OFF
init_connect=
init_file=
init_slave=
innodb_adaptive_hash_index=ON
innodb_additional_mem_pool_size=2097152
innodb_autoextend_increment=8
innodb_autoinc_lock_mode=1
innodb_buffer_pool_size=96468992
innodb_checksums=ON
innodb_commit_concurrency=0
innodb_concurrency_tickets=500
innodb_data_file_path=ibdata1:10M:autoextend
innodb_data_home_dir=D:\\MySQL Datafiles\\
innodb_doublewrite=ON
innodb_fast_shutdown=1
innodb_file_io_threads=4
innodb_file_per_table=OFF
innodb_flush_log_at_trx_commit=1
innodb_flush_method=
innodb_force_recovery=0
innodb_lock_wait_timeout=50
innodb_locks_unsafe_for_binlog=OFF
innodb_log_buffer_size=1048576
innodb_log_file_size=19922944
innodb_log_files_in_group=2
innodb_log_group_home_dir=.\\
innodb_max_dirty_pages_pct=90
innodb_max_purge_lag=0
innodb_mirrored_log_groups=1
innodb_open_files=300
innodb_rollback_on_timeout=OFF
innodb_stats_on_metadata=ON
innodb_support_xa=ON
innodb_sync_spin_loops=20
innodb_table_locks=ON
innodb_thread_concurrency=8
innodb_thread_sleep_delay=10000
innodb_use_legacy_cardinality_algorithm=ON
insert_id=0
interactive_timeout=28800
join_buffer_size=131072
keep_files_on_create=OFF
key_buffer_size=50331648
key_cache_age_threshold=300
key_cache_block_size=1024
key_cache_division_limit=100
language=C:\\Program Files\\MySQL\\MySQL Server 5.1\\share\\english\\
large_files_support=ON
large_page_size=0
large_pages=OFF
last_insert_id=0
lc_time_names=en_US
license=GPL
local_infile=ON
log=OFF
log_bin=OFF
log_bin_trust_function_creators=OFF
log_bin_trust_routine_creators=OFF
log_error=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1.err
log_output=FILE
log_queries_not_using_indexes=OFF
log_slave_updates=OFF
log_slow_queries=OFF
log_warnings=1
long_query_time=10.000000
low_priority_updates=OFF
lower_case_file_system=ON
lower_case_table_names=1
max_allowed_packet=1048576
max_binlog_cache_size=4294963200
max_binlog_size=1073741824
max_connect_errors=10
max_connections=800
max_delayed_threads=20
max_error_count=64
max_heap_table_size=16777216
max_insert_delayed_threads=20
max_join_size=18446744073709551615
max_length_for_sort_data=1024
max_prepared_stmt_count=16382
max_relay_log_size=0
max_seeks_for_key=4294967295
max_sort_length=1024
max_sp_recursion_depth=0
max_tmp_tables=32
max_user_connections=0
max_write_lock_count=4294967295
min_examined_row_limit=0
multi_range_count=256
myisam_data_pointer_size=6
myisam_max_sort_file_size=107374182400
myisam_recover_options=OFF
myisam_repair_threads=1
myisam_sort_buffer_size=12582912
myisam_stats_method=nulls_unequal
myisam_use_mmap=OFF
named_pipe=OFF
net_buffer_length=16384
net_read_timeout=30
net_retry_count=10
net_write_timeout=80
new=OFF
old=OFF
old_alter_table=OFF
old_passwords=OFF
open_files_limit=2048
optimizer_prune_level=1
optimizer_search_depth=62
optimizer_switch=index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on
pid_file=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1.pid
plugin_dir=C:\\Program Files\\MySQL\\MySQL Server 5.1\\lib/plugin
port=3306
preload_buffer_size=32768
profiling=OFF
profiling_history_size=15
protocol_version=10
pseudo_thread_id=3230
query_alloc_block_size=8192
query_cache_limit=1048576
query_cache_min_res_unit=4096
query_cache_size=33554432
query_cache_type=ON
query_cache_wlock_invalidate=OFF
query_prealloc_size=8192
rand_seed1=
rand_seed2=
range_alloc_block_size=4096
read_buffer_size=65536
read_only=OFF
read_rnd_buffer_size=262144
relay_log=
relay_log_index=
relay_log_info_file=relay-log.info
relay_log_purge=ON
relay_log_space_limit=0
report_host=
report_password=
report_port=3306
report_user=
rpl_recovery_rank=0
secure_auth=OFF
secure_file_priv=
server_id=0
shared_memory=OFF
shared_memory_base_name=MYSQL
skip_external_locking=ON
skip_networking=OFF
skip_show_database=OFF
slave_compressed_protocol=OFF
slave_exec_mode=STRICT
slave_load_tmpdir=C:\\WINDOWS\\TEMP
slave_net_timeout=3600
slave_skip_errors=OFF
slave_transaction_retries=10
slow_launch_time=2
slow_query_log=OFF
slow_query_log_file=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1-slow.log
sort_buffer_size=262144
sql_auto_is_null=ON
sql_big_selects=ON
sql_big_tables=OFF
sql_buffer_result=OFF
sql_log_bin=ON
sql_log_off=OFF
sql_log_update=ON
sql_low_priority_updates=OFF
sql_max_join_size=18446744073709551615
sql_mode=
sql_notes=ON
sql_quote_show_create=ON
sql_safe_updates=OFF
sql_select_limit=18446744073709551615
sql_slave_skip_counter=
sql_warnings=OFF
ssl_ca=
ssl_capath=
ssl_cert=
ssl_cipher=
ssl_key=
storage_engine=InnoDB
sync_binlog=0
sync_frm=ON
system_time_zone=Eastern Daylight Time
table_definition_cache=256
table_lock_wait_timeout=50
table_open_cache=619
table_type=InnoDB
thread_cache_size=38
thread_handling=one-thread-per-connection
thread_stack=196608
time_format=%H:%i:%s
time_zone=SYSTEM
timed_mutexes=OFF
timestamp=1256827484
tmp_table_size=16777216
tmpdir=C:\\WINDOWS\\TEMP
transaction_alloc_block_size=8192
transaction_prealloc_size=4096
tx_isolation=REPEATABLE-READ
unique_checks=ON
updatable_views_with_limit=YES
version=5.1.36-community
version_comment=MySQL Community Server (GPL)
version_compile_machine=ia32
version_compile_os=Win32
wait_timeout=28800
warning_count=0
The php option mysql.connect_timeout is the reason for this. It's not only used for connect timeout, but as well as waiting for the first answer from the server. You can increase it like this:
ini_set('mysql.connect_timeout', 300);
ini_set('default_socket_timeout', 300);
When I ran into this problem, it wasn't caused by wait_timeout (which was set to the default 8 hours) but by max_allowed_packet with a large INSERT statement. Changing max_allowed_packet from PHP had no effect, but when I changed it in the mysqld section of /etc/my.cnf and restarted the MySQL server, the problem disappeared.
There's a whole bunch of things that can cause this. I'd read through these and try each of them
http://dev.mysql.com/doc/refman/5.1/en/gone-away.html
I've worked for several web hosting companies over the years and generally when I see this, it is the wait_timeout on the server end though this doesn't appear to be the case here.
If you find the solution, I hope you post it. I'd like to know.
This is something I do, (but usually with the MySQLi class).
$link = mysql_connect("$MYSQL_Host","$MYSQL_User","$MYSQL_Pass");
mysql_select_db($MYSQL_db, $link);
// RUN REALLY LONG QUERY HERE
// Reconnect if needed
if( !mysql_ping($link) ) $link = mysql_connect("$MYSQL_Host","$MYSQL_User","$MYSQL_Pass", true);
// RUN ANOTHER QUERY
Increasing SQL-Wait-Timeout worked for me in this case, try this:
mysql_query("SET ##session.wait_timeout=900", $link);
before you first "normal" SQL queries.
My case was a database corruption after a minor upgrade in mysql basically 5.0.x to 5.1.x
with the DB in myisam.
The same lines on query:
MySQL server has gone away
Error reading result set's header
After repairing & optimizing it with mysqlcheck, it returned to normal, without the need to change the socket timeout.
I solved this problem with
if( !mysql_ping($link) ) $link = mysql_connect("$MYSQL_Host","$MYSQL_User","$MYSQL_Pass", true);
I have the same problem with mysqli.
My solution is https://www.php.net/manual/en/mysqli.configuration.php
mysqli.reconnect = On
I noticed something perhaps relevant.
I had two scripts running, both doing rather slow queries. One of them locked a table and the other had to wait. The one that was waiting had default_socket_timeout = 300. Eventually it quit with "MySQL server has gone away". However, the mysql process list continued to show both query, the slow one still running and the other locked and waiting.
So I don't think mysqld is the culprit. Something has changed in the php mysql client. Quite possibly the default_socket_timeout which I will now set to -1 to see if that changes anything.
In our case, the culprit was the global (not "local") MySQL variable "wait_timeout".
Compare the results of the following queries:
SHOW VARIABLES LIKE '%wait%';
to
SHOW GLOBAL VARIABLES WHERE Variable_name LIKE '%wait%';
In our case the first query showed a wait_timeout of 28800, but the 2nd query showed a value of 10 (seconds).
We verified that changing the global variable fixed the problem. Here is a simple PHP script that reproduced our condition:
<?php
$db = mysqli_connect('host', 'user', 'password', 'database');
sleep(10); // number of seconds to sleep
// MySQL server has gone away?
$obj = mysqli_query($db, 'SELECT * FROM some_table');
$results = mysqli_fetch_object($obj);
print_r($results);
As soon as the sleep time exceeded the global wait_timeout value, we would get the error: "Warning: mysqli_query(): MySQL server has gone away".
To change the value, we had to edit the setting in our Amazon RDS dashboard.
I had this problem recently. I stumbled across an option: default_authentication_plugin
For some reason it had set it to caching_sha2_password, but updating the value to mysql_native_password fixed it for me. I'm not sure what the differences are, though, so be careful!
Hope this helps someone!
I was having trouble on a database restore using mysqldumper (php program). I was able to get it working by changing the "mssql.timeout" setting in the php.ini. It was defaulted to 60 and I changed it to 300.
By my experiences when it happens on light queries there is a way to solve the problem. It seems when you start or restart mysql after apache this problem starts to appear and the source of the problem is confused open sockets in the php process.
To solve it:
First restart mysql service
Then restart apache service
It happens if the connection was open for quite sometime but no action was done in the MySQL server. In that case, connection timeout occurs with the error "MySQL server has gone away". The answers above may work and may not work. Even the accepted answer did not work for me. So I tried a trick and it worked fine for me. Logically, in order to avoid this error, we have to keep the MySQL connection running or in short, keep it alive. Assume that we are trying to Bulk insert 250k records. Generally it takes time to create parse data from somewhere and make Bulk query and then insert. In this scenario, most of us use a loop to create the SQL string. So let's count the iteration number and make a dummy database call after a certain iteration. It will keep the connection alive.
for(int i = 0, size = somedatalist.length; i < size; ++i){
// build the Bulk insert query string
if((i%10000)==0){
// make a dummy call like `SELECT * FROM log LIMIT 1`
// it will keep the connection alive
}
}
// Execute bulk insert
Please see this link http://bugs.php.net/bug.php?id=45150
seems like they moved to native MYSQL support in PHP5.3 and it has some trouble working with IPV6.
Try using "127.0.0.1" instead of "localhost"