MySQL connection error, af en toe, zonder reden

[eweps]

Een van mijn script geeft continu na een aantal uur de volgende error:

Warning: mysql_connect() [function.mysql-connect]: Host '---ipadres---' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'

Er staat geen cronjob ingesteld op het betreffende domein, en als ik zelf vaak refresh dan krijg ik de error niet. Pas als ik hem even niet bezoek heb ik de error weer. Ik moet vervolgens de hosts flushen, of mysql opnieuw opstarten.

Het gaat hier om het maken van verbinding met een andere server:

$remote_dbcn = mysql_connect($remote_conf['db_host'],$remote_conf['db_user'],$remote_conf['db_pass']);

Direct na het verbinden en het ophalen van de gegevens wordt de connectie meteen weer verbroken door: mysql_close():

Wat kan het probleem zijn? Het volgende http://developer.spikesource.com/wik...nection_errors
heb ik al gevonden, dit is in elk geval goede uitleg voor iemand die bovenstaand probleem niet snapt. Uiteraard is een oplossing de max connect errors hoger zetten. Liever los ik het anders op.

Wat ik momenteel ook al doe is het volgende:

if(@fsockopen('---ipadres---', '3306', $errno, $errstr, 5))
{
}

om de connect heen, echter kan hij wel altijd de database poort bereiken. Ik bouw nu nog even in dat hij een mailtje stuurt zodra de connectie niet gemaakt kan worden, dit bepaald in elk geval het tijdstip dat de connectie niet lukt.

Ik hoop dat iemand dit al vaker mee heeft gemaakt en hier een oplossing voor heeft bedacht.

Alvast bedankt.

[Hugh]

Je kan ook proberen om gebruik te maken te maken van persistente connecties (via mysql_pconnect); de verbinding met de SQL server zal niet worden gesloten wanneer de executie van het script klaar is. In plaats daarvan zal de link open blijven voor toekomstig gebruik (mysql_close() zal geen links sluiten die werden gemaakt door mysql_pconnect()).
Misschien helpt het bij jou.

[Ramon Fincken]

pconnect is niet altijd een goede oplossing.

Loop je pagina's eens na en check of je zeker altijd je close statement maakt.

Ook handig om de algemene SQL na te lopen, als je een update doet op een username bijvoorbeeld in een ledentabel, gooi er dan een LIMIT 1 bij
[ maar dat lost je too many connections niet op uiteraard .. ]

[eweps]

Let op: de error betreft geen: too many connections, maar: many connection errors. De connecties worden dus teveel onderbroken.

Het gaat om 1 php pagina die eerst met een database van buitenaf verbinding maakt en vervolgens met een lokale database. Tussendoor wordt de verbinding gesloten met mysql_close();

Ik zal de SQL inderdaad nog eens nalopen. Bedankt tot zover. Mocht iemand anders nog iets weten, graag!

de verbinding met de SQL server zal niet worden gesloten wanneer de executie van het script klaar is. In plaats daarvan zal de link open blijven voor toekomstig gebruik

Dat lijkt me niet de oplossing, maar ik zal het toch eens proberen!


Heb ondertussen even wat code erin gezet dat een mail stuurt wanneer de connectie niet gemaakt kan worden, zodat ik later kan zien op welk tijdstip dit was. Teven stuurt hij het IP-adres mee, dan kan ik zien wat de pagina aanstuurt.

Edit:

Wanneer ik de pagina een paar keer vernieuw, of het scherm sluit en opnieuw bezoek gebeurd er niks. Wacht ik dan ongeveer een tijd en bezoek ik hem opnieuw dan ligt hij er ineens uit.

Edit:

Bij heel vaak vernieuwen met ctrl f5 krijg ik de error ook. Tevens maakt mysql_pconnect() geen verschil.

Even voor de duidelijkheid, ik gebruik de volgende code om verbinding te maken:

if(@fsockopen('---ipadres---', '3306', $errno, $errstr, 5))
{
	/* MySQL settings */
	$remote_conf['db_host'] = '---ipadres---';
	$remote_conf['db_user'] = '---db_user---';
	$remote_conf['db_pass'] = '---db_pass---';
	$remote_conf['db_name'] = '---db_name---';
	// connect to database
	$remote_dbcn = @mysql_connect($remote_conf['db_host'],$remote_conf['db_user'],$remote_conf['db_pass']);
	if($remote_dbcn)
	{
		$remote_dbsl = mysql_select_db($remote_conf['db_name']);
		// retrieve downtime
		$remote_res = mysql_query("SELECT `id` FROM `table` WHERE `skip` = '0' ORDER BY `name1`, `name2` ASC");
		while($remote_row = mysql_fetch_assoc($remote_res))
		{
			$remote_id				= $remote_row['id'];
			$remote_tot_downtime_min	= $remote_row['tot_downtime_min'];
			$remote_downtime[$remote_id]	= $remote_tot_downtime_min;
		}
		// close mysql connection
		mysql_close($remote_dbcn);
	}
}

[Ramon Fincken]

$remote_res = mysql_query("SELECT `id` FROM `table` WHERE `skip` = '0' ORDER BY `name1`, `name2` ASC");
while($remote_row = mysql_fetch_assoc($remote_res))
{
$remote_id = $remote_row['id'];
$remote_tot_downtime_min = $remote_row['tot_downtime_min'];
$remote_downtime[$remote_id] = $remote_tot_downtime_min;
} 

je doet een SELECT op `id` maar .. je leest deze uit

$remote_id = $remote_row['id'];
$remote_tot_downtime_min = $remote_row['tot_downtime_min'];
$remote_downtime[$remote_id] = $remote_tot_downtime_min; 

oftewel

$remote_tot_downtime_min = $remote_row['tot_downtime_min'];
$remote_downtime[$remote_id] = $remote_tot_downtime_min; 

kom je nooit aan toe tenzij je tot_downtime_min erbij doet in je SELECT



vervolgens waarom maak je geen PHP file op die remote server die de juiste SQL doet en met || tussen de waarden de boel echo't ?

Dan hoef je alleen die pagina remote uit te lezen ( CURL heeft voorkeur ) en dan heb je op deze server geen mysql dingen te doen ..



update: die || kun je dan exploden en uitlezen of in een fijne array zetten ..

[eweps]

Beste Ramon,

Bedankt voor je bericht. tot_downtime_min lees ik inderdaad uit in mijn SELECT. Heb de meeste waarden even vervangen, maar deze variabele was ik inderdaad vergeten.

Uiteraard kan ik ook een pagina uitlezen, hier heb ik zelf ook al aan zitten denken. Maar.. als de connect wel werkt, zou dit dan niet sneller zijn? Je moet anders immers ook een connectie maken maar dan lokaal op de server + het bestand ophalen.

En ik vraag me ook af hoe dit probleem kan ontstaan en wat een goede mogelijke oplossing is.

[Ramon Fincken]

Geen dank

ok we hebben dus een functie die er soms uitklapt. Oorzaak onduidelijk.

Ik zou.. als ik deze situatie zelf had toch die echo / pagina uitlezen eens proberen. Dat scheelt je SQL statements over een lijn gooien en kun je daarbij ook nog eens beter beveiligen doordat je het direct op een locale machine draait.

Wellicht kun je deze pagina's even als hulpbron gebruiken:
http://nl3.php.net/features.remote-files
http://nl2.php.net/explode

Ramon


update: Eventuele error logs nalopen en op die errors googlen kan ook raadzaam zijn..

[eweps]

Error logs nalopen heb ik nog niet geprobeerd, ik verwacht echter niet dat daar iets spannends in te zien is.

Je doelt neem ik aan op de logs van de remote server?

Mocht niemand anders zoiets hebben meegemaakt dan ga het inderdaad maar met cUrl oplossen.

[Ramon Fincken]

Ok laat maar even weten of je nog ergens vastzit.

Bij mijn weten heeft ook nog niet iedere webserver beschikking over CURL dus dat zou ik eerst even uitzoeken als dat onzeker is.

Succes!

[eweps]

cUrl heb ik al meerdere malen gebruikt en werkt prima, dat zal het probleem niet zijn.

Toch wil ik eerst nog even dit proberen op te lossen(nu er toch al een hoop vrije tijd in zit kan ik er net zo goed even mee doorgaan).

Bedankt tot zo ver.

De remote database server was een VPS met weinig geheugen, ik heb hem nu aan een eigen server gekoppeld om te kijken of het probleem niet toevallig aan de hoeveelheid geheugen ligt. Als het probleem zich op deze server niet voor doet zal ik toch de VPS leverancier aan zijn broekspijp moeten trekken.

edit:

Verbinding met een eigen server gaat wel goed en blijft ook goed gaan. Het geheugen gebruik op de VPS is nog geen 70%. Kan het ook nog aan iets anders liggen dan aan het geheugen?

Het volgende heb ik ook nog gevonden, zie niet direct iets maar mocht iemand anders iets zien wat hier van toepassing is:

http://dev.mysql.com/doc/refman/5.0/...on-errors.html

[SebastiaanStok]

mysql_pconnect is iets waar je in een webhosting omgeving niet aan moet wagen!
Er was in het verleden een heel mooi artikeltje over, maar die is helaas niet meer online

Ik zal het in het kort uitleggen, je maakt een verbinding maar die word niet meer gesloten en in theorie moet een andere die weer overnemen. Helaas gebeurd dit niet... en loopt het aantal verbinding dus op tot hij vol zit, en je niet meer kan verbinden.


Terug te komen op jouw probleem, staat er niets van een verbindings limit per uur ingesteld?

[eweps]

Er staat waarschijnlijk wel een limiet ingesteld, maar het betreft hier een fout die ontstaat bij onderbrekingserrors tijdens de verbinding. Bij meer dan 10 errors van hetzelfde ipadres wordt het ipadres als host geblokkeerd.

Nou kan ik die limiet wel omhoog gooien, maar ik los liever de oorzaak op. Ik heb in elk geval al gemerk dat de error op een normale server niet ontstaat.(Meer geheugen)

Op de VPS waar de database op draait staan ook geen foutmeldingen in de MySQL log.

[SebastiaanStok]

Dan kan het inderdaad een aan geheugen tekort liggen.
Als het geheugen op is dan kan hij niets meer verwerken, of het geheugen is misschien defect?

Misschien een vreemde vraag, maar staat de maximum hoeveelheid te gebruiken geheugen niet hogen dan het totaal zelf

Of misschien is het een bug in MySQL server/client.
Kan je iets meer informatie geven over de configuratie zowel MySQL als het systeem zelf

[eweps]

Ik zal daarvoor eens een mailtje sturen naar de VPS leverancier, heb hem zelf niet geïnstalleerd namelijk.

max geheugen gebruik door mysql staat in mysql.conf als ik het mij goed herinner, zal me collega daar eens naar laten kijken.

geheugen lijkt me niet defect, vps werkt verder prima.

Bedankt voor je reactie!

[almar]

Als ik jou was zou ik de logging eens aanzetten in MySQL, dan kun je precies nagaan waar het probleem zit. Voor wat betreft de versie, zorg dat je de meest recente versie gebruikt. Het is zo lastig om dit soort problemen op te lossen in verouderde versies, en een upgrade is relatief eenvoudig en snel uitgevoerd.