Server/netwerk configuratie-/snelheidsproblemen bij webshop

[GertW]

Sorry voor de wazige titel, maar dit lijkt me het probleem aardig goed te beschrijven.

Ik werk sinds een paar maanden bij een webshop hier in nederland. Ik werk hier als programmeur, maar serveronderhoud etc behoort ook tot mijn taken. Ik zal even de huidige situatie uitleggen en dan de problemen omschrijven die we tegenkomen.

Huidige hardware:
-1 db server in colo
-1 webserver in colo
-1 webserver lokaal

Huidige software:
-MySQL 4.1 op de DB server
-OS op alle servers is Debian
-Verder redelijk standaard config op de servers (Apache/PHP), maar dit is ook niet verschrikkelijk boeiend...

Huidige gebruik:
-lokaal 50 gebruikers (in het magazijn zijn de zwaarste gebruikers(20 mensen))
-via colo op drukke momenten minimaal 400 gelijktijdige bezoekers
-minimaal 250 orders per dag

Huidige database:
-Het hele bedrijf draait op 1 database met ongeveer 60 tabellen (bij export een .sql bestand van 800MB)
-Heel veel producten (bijna 30.000)

Website(s):
-Website (in PHP) voor de klanten, waar bestellingen kunnen worden gedaan e.d.
-Backoffice (webbased in PHP) voor de werknemers, hier gebeurt eigenlijk alles, inscannen van binnengekomen producten/verzamelen van bestellingen/verkoop dingen, eigenlijk alles wat er binnen het bedrijf gebeurt, gaat via de backoffice. Voor de nieuwsgierigen, het is een volledig eigen ontwikkeld product (zowel website als backoffice)

Draaiende scripts e.d.:
-Er draaien een aantal onderhoudsscripts die gemiste inserts en dergelijke alsnog uitvoeren, evenals een paar andere dingen (deze draaien elke 5 minuten).
-Backups, deze draaien elke 2 uur, zodat we relatief weinig orders missen mocht het mis gaan. Dit merk je redelijk goed op de website en in de backoffice. Duurt ongeveer 2 á 3 minuten en dan is de snelheid weer terug.

Onze problemen:
-Snelheidsproblemen(!!), vooral in de backoffice
-We willen graag meerdere database servers, maar hoe?

Snelheidsproblemen uitgebreid:
-Vooral in de backoffice is het vaak traag, het is al een stuk sneller sinds we alle queries van zowel de backoffice en de public website hebben herschreven (joins gebruikt/indexing verandert/queries samengevoegd, geloof het of niet, maar sommige queries zijn van 20 seconden naar 0.2 seconden gegaan, uiteraard met dezelfde resultaten ). Voor zover we kunnen nagaan heeft het probleem dat er nu nog bestaat te maken met table locking. Vooral in het magazijn gebeuren heel erg veel schrijfbewerkingen op de database (inserts/updates), en deze moeten nu regelmatig op elkaar wachten! De hele database is wel in MyISAM formaat, daarom wordt de hele tabel ook gelocked. We hebben zitten denken om over te schakelen naar InnoDB omdat deze werkt door middel van row locking en ook nog eens transaction ondersteuning heeft. Het enige probleem is dat we bang zijn voor deadlocks, hoe vaak komt dit in de praktijk voor? Wat adviseren jullie om dit snelheidsprobleem op te lossen? Ook vermoeden we dat, omdat al die data over dat ene internetlijntje naar de database server moet, dit ook een deel van de traagheid kan zijn.

Meerdere database servers uitgebreid:
-Omdat we nu maar 1 database server hebben, hebben we een probleem als deze eruit zou klappen. Het hele bedrijf is er afhankelijk van en klapt deze eruit dan ligt het hele bedrijf dus plat! Dit is geen optie, tevens denken wij dat dit ook een deel van ons snelheidsprobleem is.

Ons plan was om colocated een master erbij te hangen en zo master-master te gaan draaien. Later bedachten we ons dat master-master-master misschien nog beter is (circular replication) maar dan 2 DB servers colocated en 1 DB server lokaal. Dit levert uiteraard ook weer een raar probleem op als onze lokale internetverbinding eruit klapt, de circel is verbroken en replication werkt niet meer!
Toen het volgende plan: master-master-slave, master in colo, slave in colo (*geconfigureerd als backup master die het over kan nemen als de colo master eruit klapt) en master lokaal. Als de replication tussen 2 masters wordt verbroken zou dit in theorie automatisch weer rechtgetrokken moeten worden als de verbinding weer hersteld is. Hoe werkt dit in de praktijk? Heeft iemand hier ervaring mee?

Een ander idee van mijn kant is de database helemaal overhoop trekken en opdelen in een losse catalogus database (op 1 of 2 slaves in colo, die de data van een master lokaal krijgen, op de public website heb je op dit deel van de database namelijk toch geen schrijfbewerkingen (niet van de bezoekers/klanten) en een update elke 5 minuten is genoeg), en een losse order/klanten/voorraad/etc database (dit in master-master, 1 in colo en 1 lokaal, omdat je op dit deel van de database van beide kanten schrijfbewerkingen hebt.). Dit is programmeertechnisch wel weer gigantisch veel werk, maarja, als dit de oplossing blijkt dan moet dat maar! Zijn er nog andere manieren om meerdere database servers te plaatsen en data overal hetzelfde te laten zijn? Zou een lokale database server echt veel uitmaken kwa snelheid?

Hebben jullie nog ideeën om onze problemen te laten verdwijnen? Laat ze alstjeblieft weten! Ik zal jullie ook op de hoogte houden van de vorderingen en keuzes van onze kant, zodat het voor iedereen leerzaam kan zijn!

[ Voor 2% gewijzigd door GertW op 15-11-2007 11:27 . Reden: Stonden wat dingetjes verkeerd ]

[Qwerty-273]

GertW schreef op donderdag 15 november 2007 @ 09:54:
-Snelheidsproblemen(!!), vooral in de backoffice

Je zal je server goed moeten monitoren waar exact de huidige snelheidsproblemen zich bevinden, ligt het aan de db, aan de uitvoeren van bepaalde queries, geheugen te kort, te veel i/o verkeer, etc. etc.?

De hele database is wel in MyISAM formaat, daarom wordt de hele tabel ook gelocked. We hebben zitten denken om over te schakelen naar InnoDB omdat deze werkt door middel van row locking en ook nog eens transaction ondersteuning heeft. Het enige probleem is dat we bang zijn voor deadlocks, hoe vaak komt dit in de praktijk voor?

Tja als je veel bewerking doet, en je met tabellocks werkt, dan heb je nou eenmaal grote vertragingen. Iedereen staat te wachten tot een proces een actie heeft uitgevoert op 1 row terwijl de andere rows (of dit er nou 10, 1.000 of 1.000.000 zijn maakt niet uit) nu ook geblokkeerd zijn.Rowlocking zou een welkome oplossing zijn. Daarmee zou je al een grote snelheidswinst kunnen behalen.
bv. een tabel met 10 rows er in, 1 process lockt de complete tabel maar bewerkt slechts 1 row, de andere 9 processen die elk een andere row moeten bewerken staan in de wacht. Met rowlocking ipv tabellocking zou je dus dit onderdeel dus 10x sneller kunnen maken (aangenomen dat men gelijktijdig alle 10 de rows moet bewerken - wat haast niet in de praktijk zal voorkomen).

Deadlocks kan je natuurlijk aan de db kant afvangen en eventueel bij het ontstaan van een deadlock een beheerder automagisch in laten lichten (zover dat algebeurt natuurlijk - in de praktijk zie ik vaak weinig deadlocks maar dat ligt eigenlijk alleen aan werking van de applicatie - lock je bij bewerken gelijk alle rows die je nodig hebt, of doe je dit row voor row - waarbij de laatste sneller een deadlock kan veroorzaken)

_{Het overmatig gebruiken van de ! kan soms vervelend lezen}

[thund3rball]

my 2 cents..

ben geen DB specialist, maar misschien heb je wat aan onderstaande.

- heb je de server(s) al eens gemonitord op hoeveelheid geheugengebruik/cpu gebruik/drukte op disks? SQL databases hebben vaak baat bij genoeg resources...
- je front en back-end voor je powerusers staan een stuk uit elkaar, wat gebeurt er als deze naast elkaar staan en via bijv. gigabit verbonden zijn? kun je dit testen?
- gaat een nieuwere versie van MySQL misschien beter met locking om?

kortom, wat is de exacte (en enige?) oorzaak van het probleem?

[GertW]

Nou, de database server hebben we zeker al eens gemonitord, maar van enige hardwarematige bottlenecks is eigenlijk geen sprake. We hebben trouwens monYog geprobeert en deze een aantal dagen laten draaien. Deze monitoring tool gaf onze vermoedens dus weer: table locking problemen, en het zijn er veel (alles wacht op elkaar). Misschien dat ik mijn vragen niet zo goed gesteld heb omdat het zo'n gigantische lange TS is geworden, maargoed...

Even samenvattend: Ik ben dus erg benieuwd of we veel problemen kunnen krijgen als we van MyISAM overgaan naar InnoDB. Het lijkt er steeds sterker op van niet, komt het wel voor dan is het redelijk eenvoudig te ondervangen. Daar komt nog bij dat wij allerlei reparatiescripts hebben draaien die dat soort fouten ook weer zouden moeten fixen. Het neemt natuurlijk niet weg dat we het eng vinden om over te stappen, in onze testomgeving lijkt het wel goed te gaan, maar daar werkt geen 20 man in het magazijn die erg veel inserts en updates genereren enzo.

Het andere probleem is dus de extra (database)server(s), wat voor configuratie zou de beste zijn voor ons? Op onze public website komen bijna alleen maar selects voor, alleen tijdens een bestelling wordt er geupdate en geinsert. Nu willen we dit eigenlijk zowizo een beetje uit elkaar trekken, dus alle selects op een losse slave server. Vervolgens de inserts en updates van onze public website op de master laten gaan (die dus samen met de slave in colo gaat).
Zouden we er vervolgens ook nog baat bij hebben om lokaal een databaseserver te plaatsen? Alle data moet nu namelijk over dat ene internetlijntje... We hadden het idee om dit ook een master te laten zijn en daar dan ook weer een lokale slave aan en daar lekker de backups op draaien zodat die in ieder geval ook niet meer merkbaar zijn. Heeft er iemand ervaring met dit soort oplossingen? (Master-Master dus...) En wat gebeurt er als de verbinding een half uur weg valt? Wordt alles hersteld/gesynchroniseert zodra de verbinding terug is?

Hoe zit het eigenlijk met de grotere bedrijven met meerdere (global) locaties en 1 centraal systeem? Met wat voor server configuraties werken deze? Of, laat ik de vraag anders stellen:

-Als jij een centraal systeem zou bedenken voor een webshop, hoe zou jij het server netwerk dan inrichten? Hierbij rekening houdend met 3 á 4 magazijnen, 2 aparte kantoren en 1 front-end (de webshop) en 1 backend (de backoffice). Uiteraard mag je in elk gebouw een aantal servers neerzetten. De eis is dat het overal snel is en betrouwbaar (dat het 5 minuten duurt voordat een nieuw product op de webshop staat ofzo is natuurlijk geen probleem), maar vooral schaalbaar!

Is dit uberhaupt wel (goed) te doen met MySQL (lijkt me wel aangezien Amazon.com en Google het ook gebruiken)? Kunnen we eventueel beter gaan kijken naar PostgreSQL? Of zelfs richting Oracle gaan? Ohja, laten we Microsoft's SQL server oplossingen ook niet vergeten...

Als MySQL het volgende nou eens zou ondersteunen dan zou het hele probleem opgelost zijn: 1 slave kan data ontvangen van meerdere masters. MySQL is er al vanaf 2005 mee bezig en het zou in versie 5.1 komen maar in de documentatie staat alleen maar een lege pagina, weten jullie meer over deze functionaliteit? Op die manier kun je namelijk een mooi web van servers maken.

Ik ben benieuwd wat jullie er van denken!

(Volgens mij heb ik echt een probleem met korte stukjes schrijven, mijn posts worden altijd lang! )

[ Voor 5% gewijzigd door GertW op 16-11-2007 00:49 ]

[Equator]

table locking problemen, en het zijn er veel (alles wacht op elkaar).

Dergelijke problemen heb ik eens grotendeels opgelost met het aanpassen van de table cache van Mysql.

quote: http://www.databasejourna...mysql/article.php/3367871

The table cache
The table_cache remains a useful variable to tweak. Each time MySQL accesses a table, it places it in the cache. If your system accesses many tables, it is faster to have these in the cache. One thing to note is that you may have more open tables than there are database tables on the server. MySQL, being multi-threaded, may be running many queries on the table at one time, and each of these will open a table. A good way to see whether your system needs to increase this is to examine the value of open_tables at peak times. If you find it stays at the same value as your table_cache value, and then the number of opened_tables starts rapidly increasing, you should increase the table_cache if you have enough memory. Look at these three scenarios, during peak times.

Scenario 1

code:

mysql> SHOW STATUS LIKE 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 98    |
| Opened_tables | 1513  |
+---------------+-------+

The table_cache is set to 512, and the server has been running for a long time. If the server is taking strain elsewhere, the table_cache setting could probably be reduced safely.

Scenario 2

code:

mysql> SHOW STATUS LIKE 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 64    |
| Opened_tables | 517   |
+---------------+-------+

The table_cache is set to 64, and the server has been running for a long time. Even though open_tables is at its maximum, the number of open_tables is very low considering that the server has been up for ages. There is probably not much benefit in upping the table_cache. This example came from a development server.

Scenario 3

code:

mysql> SHOW STATUS LIKE 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 64    |
| Opened_tables | 13918 |
+---------------+-------+

The table_cache is set to 64, and the server has been running for a short time. This time the table_cache is clearly set too low. The open_tables is running at maximum, and the number of opened_tables is already high. If you have the memory, up the table_cache.

[ACM]

Equator schreef op vrijdag 16 november 2007 @ 09:27:
Dergelijke problemen heb ik eens grotendeels opgelost met het aanpassen van de table cache van Mysql.

Dat is knap... Want MyISAM's table locking slaat op het write/read locken van de data zodra er een query gedaan wordt, dat je dmv de table cache wellicht wat sneller aan die locks kan komen is een ander verhaal. Bij veel gelijktijdig lezen en schrijven (updates/deletes) ben je doorgaans beter af met InnoDB.

Er zijn een paar dingen die in MyISAM wel en in InnoDB niet werken, maar kwa queries is vziw alleen de Full Text Search mogelijk relevant.

GertW schreef op vrijdag 16 november 2007 @ 00:34:
Ik ben dus erg benieuwd of we veel problemen kunnen krijgen als we van MyISAM overgaan naar InnoDB. Het lijkt er steeds sterker op van niet, komt het wel voor dan is het redelijk eenvoudig te ondervangen.

In principe kan je dat gewoon transparant elke tabel los switchen, hoewel ik het niet tijdens piekuur zou doen omdat je tabel tijdens zo'n switch natuurlijk niet beschreven kan worden.

Daar komt nog bij dat wij allerlei reparatiescripts hebben draaien die dat soort fouten ook weer zouden moeten fixen.

Wat voor fouten?

Het neemt natuurlijk niet weg dat we het eng vinden om over te stappen, in onze testomgeving lijkt het wel goed te gaan, maar daar werkt geen 20 man in het magazijn die erg veel inserts en updates genereren enzo.

MyISAM schaalt gewoon slecht zodra je gaat zitten bewerken, ik zou dus minimaal die tabellen naar InnoDB omzetten die veel updates en selects krijgen. Verder vind ik het vrij knap om queries te verzinnen die 20 seconden duren op 800MB aan data, dus als je ook op je rustige testomgeving zulke queries hebt, zou ik eens goed kijken of die slome queries wel voldoende gebruik maken van indexen.

Zouden we er vervolgens ook nog baat bij hebben om lokaal een databaseserver te plaatsen? Alle data moet nu namelijk over dat ene internetlijntje... We hadden het idee om dit ook een master te laten zijn en daar dan ook weer een lokale slave aan en daar lekker de backups op draaien zodat die in ieder geval ook niet meer merkbaar zijn. Heeft er iemand ervaring met dit soort oplossingen? (Master-Master dus...) En wat gebeurt er als de verbinding een half uur weg valt? Wordt alles hersteld/gesynchroniseert zodra de verbinding terug is?

Ik zou er niet als eerste aan beginnen... Onze ene databaseserver is vooralsnog dusdanig stabiel gebleken dat het echt alle moeite niet waard lijkt om het voor de backups e.d. te doen. En met jullie databasegrootte en bezoekersaantal (hangt een beetje van je definitie van "gelijktijdige bezoekers" af) lijkt me ook niet zodanig dat je hier moeite voor moet doen.
Met een fatsoenlijke adsl-lijn of desnoods glasvezel horen 20 man maar weinig last te hebben van een trage site door die reden. Ik zou eerst beginnen met het verbeteren van de performance door enerzijds de meest beschreven tabellen om te zetten naar InnoDB en anderzijds te controleren of de queries die dan nog steeds traag zijn dat ook op een rustige omgeving zijn (vergeet niet je query cache uit te zetten bij het testen ).

[GertW]

ACM schreef op vrijdag 16 november 2007 @ 10:46:
Wat voor fouten?

Heel af en toe wordt er een insert of delete gemist, onze reparatiescripts zorgen ervoor dat dat allemaal weer rechtgetrokken wordt. Hoe het precies zit of kan weet ik eerlijk gezegt ook niet, dit is ontwikkeld voordat ik er werkte en heb me er verder nog niet in verdiept.

ACM schreef op vrijdag 16 november 2007 @ 10:46:
Verder vind ik het vrij knap om queries te verzinnen die 20 seconden duren op 800MB aan data, dus als je ook op je rustige testomgeving zulke queries hebt, zou ik eens goed kijken of die slome queries wel voldoende gebruik maken van indexen.

Nou, die queries maakten geen gebruik van indexing, haalden data uit meer dan 10 tabellen, hadden dubbele matches en geen joins. Bij sommige queries moest ik zelfs zwaar over nadenken voordat ik het snapte, zo raar zat het in elkaar. Inmiddels heb ik alles zo aangepast dat dit dus allemaal wel snel werkt. Qua queries is het op dit moment allemaal geoptimaliseert, dus hier hoef ik de eerste tijd niet meer naar te kijken.

Een leuk voorbeeld is misschien de volgende pagina:
Deze pagina had een query waar alle order_id's worden opgehaald (SELECT order_id FROM ...)
Dit duurde een aantal seconden, alle order_id's die opgehaald waren, werden in een array gepleurt, de volgende query zag er vervolgens ongeveer zo uit: "SELECT order_line_id FROM ... WHERE order_id IN ('3534', '46534', 'etcetera'), de order id's kwamen dus uit die array en waren er echt werkelijk 1000en. Nou, dan vind ik het niet gek als je langzame queries hebt
IN is van zichzelf al niet de snelste namelijk (ligt me zelfs iets van bij dat IN geen indexing gebruikt). Nu heb ik het opgelost door de queries samen te voegen en de tabel waar de order_line_id in staat te joinen... klaar!

ACM schreef op vrijdag 16 november 2007 @ 10:46:
Ik zou er niet als eerste aan beginnen... Onze ene databaseserver is vooralsnog dusdanig stabiel gebleken dat het echt alle moeite niet waard lijkt om het voor de backups e.d. te doen. En met jullie databasegrootte en bezoekersaantal (hangt een beetje van je definitie van "gelijktijdige bezoekers" af) lijkt me ook niet zodanig dat je hier moeite voor moet doen.

Met gelijktijdige bezoekers bedoel ik het volgende, ff een voorbeeldje: tussen 12 en 1 's middags hebben we op elk willekeurig moment gemiddeld dat aantal unieke bezoekers. Een extra server komt er zowizo, ook omdat de boel nu plat ligt als onze huidige server eruit klapt, een fail-over dus!
In verband met het hoge aantal writes dat we dus hebben zaten we te denken aan een lokale server zodat het daar ook altijd snel is...

ACM schreef op vrijdag 16 november 2007 @ 10:46:
Met een fatsoenlijke adsl-lijn of desnoods glasvezel horen 20 man maar weinig last te hebben van een trage site door die reden. Ik zou eerst beginnen met het verbeteren van de performance door enerzijds de meest beschreven tabellen om te zetten naar InnoDB en anderzijds te controleren of de queries die dan nog steeds traag zijn dat ook op een rustige omgeving zijn (vergeet niet je query cache uit te zetten bij het testen ).

Haha, query cache staat lokaal inderdaad uit, anders is het lastig query benchmarken natuurlijk

Langzame queries hebben we op dit moment dus niet meer (met uitzondering van een paar statistiek pagina's die bijvoorbeeld financieele data ophalen van jaren, maar die pagina's worden bijna nooit gebruikt), het zit nu echt in de table-locking en InnoDB lijkt inderdaad de allerbeste oplossing.

Vergeet niet dat bij ons echt alles in de backoffice gebeurt en hier 40 man de hele dag op werkt (waarvan er 20 zware gebruikers zijn). We hebben dus geen losse CRM/Warehouse management/CMS/enz. systemen, alles werkt en draait op die ene database server...

[ACM]

GertW schreef op vrijdag 16 november 2007 @ 11:35:
Qua queries is het op dit moment allemaal geoptimaliseert, dus hier hoef ik de eerste tijd niet meer naar te kijken.

Er is altijd meer te halen, maar het klinkt inderdaad alsof je je aandacht nu eerst op andere dingen kan richten

IN is van zichzelf al niet de snelste namelijk (ligt me zelfs iets van bij dat IN geen indexing gebruikt).

Dat valt reuze mee hoor, er worden ook gewoon indexen gebruikt voor zover mogelijk. Maar MySQL is niet altijd even efficient en soms is een IN net hetgene wat iets triggered waar ie langzamer van wordt (bijv dan ineens een file sort nodig).

Nu heb ik het opgelost door de queries samen te voegen en de tabel waar de order_line_id in staat te joinen... klaar!

Dat is vaak een nuttige verbetering ja

In verband met het hoge aantal writes dat we dus hebben zaten we te denken aan een lokale server zodat het daar ook altijd snel is...

Maar als die lokale server steeds zijn werk moet verzenden naar de server in de colo, is het maar de vraag of een en ander daar sneller van wordt.

Vergeet niet dat bij ons echt alles in de backoffice gebeurt en hier 40 man de hele dag op werkt (waarvan er 20 zware gebruikers zijn).

Dat zal het voor MyISAM niet beter maken nee...

[GertW]

Ik ben nu aan het kijken welke tabellen allemaal over moeten naar InnoDB, en dit gaan we dan in de loop van volgende week doorvoeren als alles goed gaat in de testomgeving.

Qua servers wordt het eerst waarschijnlijk gewoon een master-master oplossing in colo ivm de failover. Mochten er dan nog optimalisaties of andere dingen nodig zijn dan zien we dat vanzelf!

Weten jullie verder nog dingen waar we rekening mee moeten houden of heb je andere tips?

Nu alleen nog mijn andere vraag:
-Als jij een centraal systeem zou bedenken voor een webshop, hoe zou jij het server netwerk en het systeem zelf dan inrichten? Hierbij rekening houdend met 10 magazijnen, 4 aparte kantoren en 1 front-end (de webshop) en 1 backend (de backoffice). Uiteraard mag je in elk gebouw een aantal servers neerzetten. De eis is dat het overal snel is en betrouwbaar (dat het 5 minuten duurt voordat een nieuw product op de webshop staat ofzo is natuurlijk geen probleem), maar vooral schaalbaar!

[ Voor 36% gewijzigd door GertW op 16-11-2007 12:59 ]

[masterpe]

Een aantal dingen kan je naar kijken om het sneller te maken,
1. kijken of het gebruik van caching zoal memcache en xcache een voordeel hebben, dit geeft de mogelijk om veel minder selects te doen, en eventuele tijdeljike gegevens niet in de database hoeven op te slaan.

2. gebruik maken van indexes zal een hoop schelen

3. InnoDB, heeft waarschijnlijk zin

4. Het vermijden van joins zal de load van de server afhalen

Zeker de eerste optie heb ik gemerkt als een grote versneller van de site. Door gebruik van memcache is het mogelijk om de site binnen het kantoor flink te versnellen. Dit omdat er minder over de wan link gaan en veel data wordt locaal opgehaald. Ook de website in de colo zal hier profijt van hebben. Immers zoals je zegt doe je veel selects. Dus kan je heel goed veel van je producten in je caching zetten.

Ik moet ook nog be-amen dat gebruik van een sigle database server vaak beter en stabieler is dan een server in een failover setup of al helemaal in een master-master situatie.

[ Voor 9% gewijzigd door masterpe op 16-11-2007 14:56 ]