Van egy problema amivel kapcsolatban segitseget kernek.
Adott 3 szerver:
1. WEB szerver
2. MYSQL szerver
3. BACKUP szerver
Mindegyik linux!
A WEB szerveren levo weboldalak mysql szervernek a MYSQL szervert
hasznaljak
Rsync-el keszitek mentes BACKUP serverre a WEB server home particiojarol minden problema nelkul!
A BACKUP szerver egy sima pc. Le szeretnem cserelni uj vasra: kisebb fogyasztasu atom procis cucc nagyobb diszkekkel
Nevezzuk ezt UJBACKUP-nak
Amikor a WEB szerverrol keszitek rsync-el mentest az UJBACKUP szerverre,
a mysql kapcsolodasok/lekerdezesek teljesen belassulnak, sot van hogy total behalnak.
A sima html oldalak teljesen faszan mukodnek, de azok a weboldalak amik
sql-be is matatnanak teljesen belassulnak, vagy akar ki is akadnak
azzal hogy nem tud a php az mysql-hez kapcsolodni
Ilyen problema nem jelentkezik a regi BACKUP gepre menteskor!
HA mentes alatt a WEB szerveren mysql konzol klienssel probalok kapcsolodni SQL-hez, akkor a kovetkezo hibat kapom:
mysql -upero -p -hsql.akarmi.hu
Enter password:
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading
authorization packet', system error: 0
Google-zva a hibara olyan problemakat talaltam, ahol a MYSQL szervert mentettek rsync-el es akkor lepett fel ilyen gond, valszeg a sok IO muvelet miatt, de en nem a MYSQL-t hanem a WEB szervert mentem
se a WEB se a MYSQL-en a load nincs magasan mentes alatt
WEB es SQL szerver egy-egy HP DL380G3-as gep
mindkettoben a halokargya: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) (kernel driver: Broadcom Tigon3)
Lehet halokartyadriver problema WEB-en? De akkor gondolom regi BACKUP-ra is szar lenne a dolog...
mindharom gep ugyanarra a switchre van dugva, probaltam mas portokba dugni oket, nem valtozott semmi
szoftververziok:
UJBACKUP szerver: ubuntu 8.04LTS (gyari kernel)- rsync 2.6.9-6ubuntu2
regi BACKUP: debian lenny (2.6.11.12 grsec pecselt) - rsync 3.0.3-2
WEB: debian etch (2.6.27.10 grsec pecselt)- rsync 2.6.9-2etch2
Van valakinek otlete merre nyomozzak?
Elore is koszonom!
- 1003 megtekintés
Hozzászólások
up
- A hozzászóláshoz be kell jelentkezni
Szsvz. Tul nagy a load, es a tcp kapcsolatok time outtal elszallnak, vagy rakat fos az applikacio query es pl. ciklusbol tobbszor lekerdezi azt amit 1 queryvel is lehet. (lattam már ilyet és sírtam, kapartam a falat.)
my.cnf -ben :
Ha van eleg mem a gyorsitasra:
[mysqld]
skip-locking
key_buffer_size = 2000M
max_allowed_packet = 32M
table_cache = 3072
open_files_limit = 9216
tmp_table_size=1000M
sort_buffer_size = 100M
read_buffer_size = 100M
read_rnd_buffer_size = 100M
myisam_sort_buffer_size = 100M
max_length_for_sort_data=2048
max_sort_length=2048
a connect timeoutra pl:
long-query-time=5
log-slow-queries=ide loggoljon a slow query/slow-query.log
interactive_timeout=300
wait_timeout=300
Az értékekkel játszani! A te gépedre optimalizálni!
Plusz 1 hálókartyat berakni + bonding :)
Több ötletem hirtelen nincs.
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
- A hozzászóláshoz be kell jelentkezni
ertem, csak az a gond hogy regi backup gepre mentes kozben nincs problema, csak az uj backupra
Az fontos, nemtom jol ertelmezted-e a problemat, de en nem a SQL szerverrol hanem egy masik vasrol a WEB szerverrol keszitem a mentes. Velemenyem szerint nem a mysql-t kel tuningolni hanem... na ezt nem tudom :)
- A hozzászóláshoz be kell jelentkezni
"rakat fos az applikacio query"
ezt hogy erted? nincs query, a kapcsoladas nem mukodik, meg konsolrol sem mysql klinessel
- A hozzászóláshoz be kell jelentkezni
Valahol belefutottal egy szuk keresztmetszetbe. Load azert nem magas, mert ez nem CPU intenziv. iotop-ot nezd meg. Esetleg a backupot probald meg 20-as nice-szal elinditani.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni