[tomisak]

Hej,

jag har en separat dedikerad server för apache-server (webbserver) och en separat för mysql-server (databassserver). Webbservern har två nätverkskort, eth0 ut mot internet och eth1 är kopplad med en GB ethernet kabel till databasservern.

I min route-tabell på webbservern finns följande:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1

Databasservern har IP-adress 192.168.0.2

Men när jag i min webbapplikation försöker göra mysql_connect mot 192.168.0.2 så tar det enormt lång tid innan databasservern svarar. Dock får jag svar till sist. Det är nästan så att jag misstänker att webbservern först försöker hitta 192.168.0.2 ute på internet och när det misslyckas så letar den på det lokala nätverket.

Någon som har någon idé om vad som går snett?

EDIT: Jag vill inte att databasservern skall vara tillgänglig från internet, utan enbart via webbservern.

[grazzy]

Lägg till båda burkarna i dina hosts-filer, tex
192.168.0.1 www
192.168.0.2 db

[najk]

Låter som något dns fel, så prova grazzys tips, annars får du kika på hur din databaserver är konfgurerad gällande dns.

[tomisak]

Uppdaterade bägge hosts-filerna och nu verkar jag få svar direkt.

Däremot blir det nu:
Lost connection to MySQL server during query

Verkar dock vara på rätt spår.


EDIT: Hittade nåt om etc/networks. Måste det lokala nätverket finnas med där?

[grazzy]

Troligen nån timeout som är satt för lågt, kolla "show variables like '%timeout%'" (eller wait).

[tomisak]

Tror egentligen inte att det är något direkt fel i mysql-konfigurationen. Har tagit samma my.cnf som jag använt tidigare då mysql-servern låg på samma fysiska server som apache.


mysql> show variables like '%timeout%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| innodb_lock_wait_timeout | 50 |
| interactive_timeout | 28800 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| sync_replication_timeout | 0 |
| wait_timeout | 28800 |
+--------------------------+-------+


+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50 |
| wait_timeout | 28800 |
+--------------------------+-------+


Jag tror att felet ligger i själva nätverkskonfigurationen.

EDIT: Hittade nåt om etc/networks. Måste det lokala nätverket finnas med där?

[tomisak]

skip-networking var påslaget på databasservern och när jag tog bort det så fick jag kontakt igen.

Men jag förstår inte riktigt ändå hur det hänger ihop:

- Innan jag la till i hosts-filerna så fick jag ju kontakt, även om det tog extremt lång tid
- Efter jag la till i hosts-filerna så blev jag tvungen att slå av skip-networking

Någon som kan reda ut hur detta hänger ihop?

[tomisak]

Sorry för dubbelpost men det som händer nu när jag släpper på lite trafik är att webbserverns load går i taket samtidigt som databasservern är i princip idle.

Detta händer redan vid låg trafik. När jag är ensam så svara mysql-servern snabbt, men så fort det blir några användare så blir det problem.

Jag har läst att detta kan hända när man har ett enda nätverkskort (att mysql-frågorna får vänta på apache-requests). Men eftersom jag har två nätverkskort så borde väl detta kunna undvikas....?

----
EDIT: En annan skum sak som jag la märke till är att min databasserver har SwapTotal = 0. Detta har jag aldrig sett tidigare. Är det normalt?

[tomisak]

Nu är jag ganska säker på att det lokala nätverket fungerar bra. Men fortfarande blir det så när jag släpper på trafik att loaden på www-servern går i taket medan databas-servern är i princip idle.

Eftersom jag har samma konfig på httpd.conf och my.cnf som innan, när de låg på samma server, är jag nu inne på spåret att det är detta som det beror på. Alternativt php-konfigurationen. Någon som har input på detta?

[SimonP]

Har du testat att ställa om nätverkskortens hastighet till fast link speed, 10mbit eller 100 mbit? Om autosensen strular kan man ju få mkt konstiga problem.