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"
Related
I have created some PHP code for my website to call a stored procedure in my database. This will get text from a table so that I can dynamically update the text on the web page without modifying it in code.
This part works very well so far. However, When I open the MySQL error log I see the following message printed:
Aborted connection 161 to db: 'dbname' user: 'username' host: 'localhost' (Got an error reading communication packets)
I have checked the firewall, which is inactive.
I have attempted using 127.0.0.1 instead of localhost in the PHP code.
I have cleared the results using "mysqli_free_result($result);", this did seem to remove one of the two errors I got per query.
I have checked the max allowed packet size, which is 16M.
I have un-commented the extension mysqli in the php.ini file.
PHP:
<?php
$servername = "localhost";
$username = "username";
$password = "password ";
$dbname = "dbname";
// Create connection
$conn = mysqli_connect($servername, $username, $password, $dbname);
// Check connection
if (!$conn) {
die("Connection failed: " . mysqli_connect_error());
}
$sql = "Call StoredProcedure('primarykey',#OutValue);";
$result = mysqli_query($conn, $sql);
if (mysqli_num_rows($result) > 0) {
// output data of each row
while($row = mysqli_fetch_assoc($result)) {
echo $row["ColumnHeader"];
}
} else {
echo "0 results";
}
mysqli_free_result($result);
$t_id = mysqli_thread_id($conn);
mysqli_kill($conn,$t_id);
mysqli_close($conn);
?>
SQL:
CREATE DEFINER=`username`#`hostname` PROCEDURE `StoredProcedure`(IN PrimaryKey
VARCHAR(50), OUT Result VARCHAR(50))
BEGIN
start transaction;
select ColumnName
from dbname.tablename
where PrimaryKeyColumn = PrimaryKey;
commit;
END
As I mentioned, I am getting the expected result from my query and it is perfectly functional, so I am not sure what can be the cause.
The server is running MySQL version 5.7.27-0ubuntu0.18.04.1((ubuntu)). Any help with this would be greatly appreciated!
Update - 11/Sep/2019:
I have attempted to check how long the execution of the my PHP script takes. To do this I added the following code borrowed from this thread:
Tracking the script execution time in PHP.
// Script start
$rustart = getrusage();
// Code ...
// Script end
function rutime($ru, $rus, $index) {
return ($ru["ru_$index.tv_sec"]*1000 + intval($ru["ru_$index.tv_usec"]/1000))
- ($rus["ru_$index.tv_sec"]*1000 + intval($rus["ru_$index.tv_usec"]/1000));
}
$ru = getrusage();
echo "This process used " . rutime($ru, $rustart, "utime") .
" ms for its computations\n";
echo "It spent " . rutime($ru, $rustart, "stime") .
" ms in system calls\n";
However, the result was the following:
This process used 0 ms for its computations It spent 1 ms in system calls
Which should not cause any timeouts.
I also activated the general log file on the server and i did see that the it would track the query as follows:
Command Type, Detail
Connect, username#hostname on dbname using Socket
Query, Call StoredProcedure('PrimaryKey', #result)
I am curious about there being no log saying disconnect though I do not know if this is default behaviour from MySQL.
Another curious thing I discovered was that MySQL Workbench states my query time for the stored procedure is on average 7ms but all resources I could find states that PHP waits for the query to finish before continuing.
Query, Total Time, Max Time, Avg Time
CALL StoredProcedure ( username # hostname ) , 98.94, 66.26, 7.07
In short, I still have not found any solutions to the issue, but potentially some leads that could eventually lead to a resolution.
Update - 18/Sep/2019:
After more digging on the issue I've come across the following thread:
https://dba.stackexchange.com/questions/144773/mysql-aborted-connection-got-an-error-reading-communication-packets
It is suggesting that due to MySQL and PHP being installed on the same server, they are competing for RAM. Considering my server is running on a Raspberry Pi 3 model B, this seems like a plausible explanation for the issue I am facing.
I'm having an intermittent problem with quite a complex search system. Every once in a while a PHP Daemon I wrote, which adds new content to our database and an RT index for sphinx throws a mysterious exception.
Message is simply "Statement could not be executed".
The code that causes it is (trimmed):
<?php
$itemIds = Array( 79555 );
$index = 'doc';
$adapter = $this->dbAdapter;
$qi = function($name) use ($adapter) {
return $adapter->platform->quoteIdentifier($name);
};
$checkSql = '
SELECT * FROM
'. $qi( $index ) . '
WHERE
id = ' . (int)$itemIds[0];
$checkStatement = $this->dbAdapter->query($checkSql);
$result = $checkStatement->execute();
The exception doesn't seem to occur on any particular trigger, but persists from the time it's first thrown to the time I restart the daemon. I've outputted the sql generated by Zend\DB\Adapter and bar ids being different, there seems to be no diference in the queries from ones that succeed to ones that fail.
There's no associated error in the sphinx logs (that I can see) and if I load neutron/sphinxsearch-api/sphinxapi.php and run GetLastError() it returns a blank string.
My thinking is that it's a connection error - or possibly a misconfiguration with the sphinx config making it timeout, but I'm not sure.
This sounds like you are using persistant connections. At times a connection might be dropped, but your code doesnt account for this, and is still trying to use a connection that has been closed. Maybe try checking for the error, and if get it, reconnects.
In short, make the code resilient to the connection occasionally having been closed.
I'm having issue using the SDK for PHP.
If I try to estabilish a connection it takes ages...
Here some code:
$old = microtime (true);
$db = new Couchbase(...);
echo microtime (true)-$old."
";
$old = microtime (true);
$db->get(...);
echo microtime (true)-$old;
The output is this:
2.2835459709167 (couchbase establishing)
0.0011978149414062 (get command)
Why does the connection to couchbase take so long time?
The initial connection does take a while, but there is a flag for using persistent connections with the Couchbase() object. It's the last parameter. Generally, it's a good idea to set it to true.
The project is considering setting it to true by default in a future release.
Check which value you're using for the server host, if you use, for example:
$cb = new Couchbase("couchbase_hostname:8091", "user", "pass", "default" , true);
the issue may be the DNS resolution for "couchbase_hostname", try passing the host IP, you didn't paste the whole script code so I can't tell which value you're passing.
When I run the script below with the added line,
$count = 1;
I get a value of 1 on the screen, but when I take that line out I don't get get anything at all. tried moving it above the $count=mysql_num_rows($result); and I still didn't get a value.
$sql="SELECT EMAIL FROM CUSTOMER WHERE email='$myemail' and password='$mypassword'";
$result=mysql_query($sql);
$count=mysql_num_rows($result);
$count = 1;
echo $count;
What am I doing wrong here? I have never used PHP until now. The error is:
Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)
This means that your MySQL server socket (/var/run/mysqld/mysqld.sock) is either missing or corrupt.
It could also mean that MySQL service is not working right, try restarting in SSH using:
$ service mysqld restart
If it says the service is missing, then say:
$ service mysql restart
I would guess at an a error with your SQL query (var_dump($count); would return false in this case).
To check this, I would do 2 things:
After your query do if(!$result) echo mysql_error( ); - this will show you any errors that happen while talking to the database
To check your SQL is being formed correctly, create it in a variable (e.g. $sql = "SELECT email ...";) and echo it out.
EDIT: Ahh just seen the update - it's a connection issue. Check that your mysql_connect( ) has the right host, username & password. Otherwise it could be a problem on your system (e.g. firewall or similar)
EDIT 2: As has been rightly pointed out, mysql_connect details would cause a different connection error to the one you're seeing. I've had a quick Google for it, and this cropped up http://lists.mysql.com/mysql/204035. Not sure it'll be any use as I've not read it through, but it does describe some steps for the solving this problem on someone else's system.
When you can't connect successfully to the database, return value from mysql_query function ($result) would not be a valid value. so when you give it to mysql_num_rows function, it fails & returns FALSE value, which has no visual effect on output screen!
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)