PFZ.nl - PHP Community: Database koppeling tussen 2 mysql servers - Discussie - Forum - PFZ.nl - PHP Community

Ik ben op zoek naar tips voor de volgende situatie.
We hebben momenteel een dedicated server met > 20 shops hierop
Nu hebben we een 2e dedicated server elders aangevraagd.
Hierop willen we ook shops opzetten en eventueel een paar verhuizen van de ene naar de andere server.

De sites zijn op basis van osCommerce gemaakt en betreft een multistore versie.
We hebben dus een backoffice met alle producten, klanten etc.
Wat de bedoeling is, is dat als een product bewerkt word (en andere bewerkingen in de backoffice), dit ook zichtbaar moet worden op de 2e dedicated server (oftewel de mysql moet gesynchroniseerd worden)
De hoofd database is vrij groot en ik wil alleen specifieke tabellen synchroniseren en dus niet de complete database

Nu kan ik zelf zon 2 mogelijkheden bedenken:
1) Script die backup maakt van tabbellen en importeert op nieuwe server (ééns in de 3 uur bijv zou wel wenselijk zijn)
2) In alle scripts ( 50 + ) de query op beide servers uitvoeren ( dit is mijn minste favoriet, erg veel werk, maar wel realtime de wijzigingen beschikbaar op de andere database )

Graag hoor ik jullie suggesties :)

3) gebruik MySQL's eigen replicatiemechaniek. :-)

bedankt voor je reactie maar de mysql replicate kan toch alleen maar complete database doen ?
En dat willen we niet

Ik betwijfel *zeer* sterk dat je losse tabellen wilt repliceren (de kans dat je inconsistentie krijgt is veel te groot), en je hebt dan twee single-points-of-failure. Als de tweede server uitvalt ligt de helft van je klanten plat.
Als je de complete database repliceert laat je de helft van de klanten op de ene server productie draaien, en staat een kopie van al hun data klaar op de tweede voor als de eerste server uitvalt.

Anyhoes, assumption is the mother etc: http://dev.mysql.com...licate-do-table

Ja oke op die manier.
Maar in principe hadden wij de gedachten om de klanten op de hoofdserver te laten omdat daar ook de backoffice op draait en dan vanuit 2e server een koppeling maken naar de hoofdserver bij inloggen voor de klantgegevens.
En de producten zelf wouden we dan op zowel 1ste als 2e server hebben staan.
De bedoeling is namelijk dat de mysql server van de hoofdserver minder belast word.
Dus de producten moeten ook echt uit de 2e server gehaald worden voor de andere sites.
En de huidige 20 sites halen de gegevnes uit de hoofdserver.

Maar via replication zou je in ieder geval een complete synchronisatie doen ( en hoevaak word er gesynchroniseerd want dat kon ik ook niet vinden)
En als hoofddatabase uitvalt gaat hij dan niet een lege database synchroniseren waardoor de andere databse ook leeg knalt ?

Quote

De bedoeling is namelijk dat de mysql server van de hoofdserver minder belast word.

Belasting komt alleen uit de hoeveelheid queries die je draait. Databases die je wel repliceert maar niet gebruikt, hebben ook geen invloed op de performance van de server.

Maar heb je p de huidige server alle beschikbare resources al volledig benut? Het gebeurt veel te vaak dat systemen worden opgeshaald naar meerdere servers om performance te verbeteren, terwijl b.v. de databaseservr simpelweg niet de juiste indexes had, of niet genoeg geheugen toegewezen had. Je moet echt flink je best doen om een server te belasten tot het punt waarop het niet meer werkbaar is.

Quote

Maar via replication zou je in ieder geval een complete synchronisatie doen ( en hoevaak word er gesynchroniseerd want dat kon ik ook niet vinden)

Replicatie is een continu process, elke update op de master wordt direct doorgezet naar de slaves.

Quote

En als hoofddatabase uitvalt gaat hij dan niet een lege database synchroniseren waardoor de andere databse ook leeg knalt ?

Wellicht is het verstandig om je een beetje te orientere op wat replicatie is en waar het voor toegepast wordt.
Replicatie stuurt mutaties door dus als de master stopt zijn er daar geen mutaties meer om door te sturen naar de slaves.

Een van de bekendste toepassingen van replicatie is om backupservers synchroon te houden met een master om te taak van de master over te nemen als hij uitvalt. Daar zou je niets aan hebben als de replicatie het uivallen van de maste ook repliceert :-)

Op 27-01-2012 12:37 schreef Ruud van Dijk:

De hoofd database is vrij groot en ik wil alleen specifieke tabellen synchroniseren en dus niet de complete database

Wat is "groot"?

Dit is (in 2012) mijn definitie:
Alles kleiner dan 16GB is klein, 16GB kun je in iedere server in RAM zetten zonder dat je daar heel veel kosten aan hebt. RAM kost je hooguit een paar honderd euro in aanschaf (en dan is het al duur!) en gaat jaren mee.

Een database van medium formaat past op een enkele schijf, dus ergens tussen de 300GB en 1TB groot. 2TB schijven zijn nog een uitzondering, tel ik nog even niet mee. Je gebruikt uiteraard wel meerdere schijven in RAID 10 voor veiligheid en performance, maar je hebt voldoende schijf ruimte om te groeien.

Een grote database is groter dan 1TB en je gebruikt of denkt aan een SAN voor de opslag. De echt grote databases beginnen bij een PB.

my2c

Wanneer je denkt aan replicatie t.b.v. failover, ga dan eerst álle single points of failure in kaart brengen voordat je aan replicatie gaat denken. Het is mooi dat je een tweede database server hebt, maar wanneer er geen applicatie of website meer is die hier gebruik van kan maken, dan is het redelijk zinloos. En het kan je flink wat hoofdpijn bezorgen om de replicatie goed voor elkaar te krijgen, dat moet het wel waard zijn.

Ik kan me niet voorstellen dat je voor 20 webshops al twee database servers nodig hebt vanwege performance, wij doen 80.000 bezoekers per uur op één server. Eén server met veel processorcores en veel RAM (64GB kost al bijna niks meer, 16GB is standaard) en zoveel schijven als jouw budget toelaat, kun je een heel eind komen.

En PgVincent zei het ook al, maar ga je database configureren en optimaliseren! 9 van de 10 perfomance problemen ontstaan door fouten van de ontwikkelaars, fouten van de dba en fouten van de server beheerder. Los deze fouten op en de server gaat ineens 100x sneller. Dit soort verschillen ga je met replicatie echt niet zien, per extra server krijg je meer hoofdpijn en slechts ietsjes meer performance. En vergeet niet dat MySQL gewoon langzaam is, zeker de wat oudere versies.

Oke dat is duidelijk.
Echter hebben wij al een 2e dedicated server dus ik wil deze wel graag benutten.
Onze eerste dedicated server is managed en heeft aardig weinig dataverkeer/maand toegestaan.
Dit is ook reden om de 2e server te gaan gebruiken voor de andere shops.
De dataverkeer kan bij hun ook niet omhoog en daardoor zitten wij elke maand een paar 100 gb over de dataverkeer.
Gezien de service wel goed bij hun is blijven wij bel hun.
Bij storing is de server meestal binnen 1 - 5 min weer online (indien ik er zelf niet meer bij kan komen) + ze zoeken altijd de storing uit.
Uiteraard hopen we met de 2e server ook dat de mysql server iets minder te verduren heeft.
Hoe kunnen we dan toch het beste gebruik maken van onze 2e server? Want de mysql database benaderen vanaf de andere server zal ook dataverkeer vanaf server 1 genereren.
Word dan toch de beste oplossing mysql replicatie?

De queries zal ik sowieso proberen verder te optimaliseren

Quote

Een grote database is groter dan 1TB en je gebruikt of denkt aan een SAN voor de opslag.

Jij met je SAN :-)

Wat jij groot en klein vindt wordt vrijwel helemaal bepaald door jouw ervaringen. Jij werkt met gigantische machines dus voor jou is 16GB helemaal niets. Ik werk met servers die niet meer dan 4GB RAM aan kunnen, en dan is een DB van 2GB al een uitdaging.

En zo verschilt de praktijk van de gemiddelde PFZ bezoeker wel vaker van de jouwe, probeer daar af en toe een beetje rekening mee te houden.

Quote

De dataverkeer kan bij hun ook niet omhoog en daardoor zitten wij elke maand een paar 100 gb over de dataverkeer.

Dan ben je dus gewoon uit je pakket gegroeid en wordt het tijd om te upgraden.
Een tweede server lijkt mij dan feitelijk de ingewikkeldste oplossing...

Quote

Gezien de service wel goed bij hun is blijven wij bel hun.

Begrijpelijk, maar als ze niet kunnen leveren wat je nodig hebt, moet jij dan ingewikkelde oplossingen bedenken terwijl *zij* in gebreke blijven?

Quote

Hoe kunnen we dan toch het beste gebruik maken van onze 2e server? Want de mysql database benaderen vanaf de andere server zal ook dataverkeer vanaf server 1 genereren.

Da's, intern dataverkeer, dat mag een hoster niet meetellen in je quota.

Als je perse bij die hoster wilt blijven dan zou ik onderzoeken of je beide servers in productie kunt zetten. Een database met de master database die alle mutaties in de database ontvangt en repliceert naar de slave server. Dan kunnen beide servers alle websites uitleveren aan bezoekers. Een vereiste daarvoor is wel dat je alle muterende queries van je scripts op de master moet kunnen laten uitvoeren.

Anders houd je de oude server zuiver voor de database en neem je de nieuwe server als webserver, dat houdt de taken gescheiden en daarmee benut je de beschikbare resources hopelijk wat efficienter.

Het is sowieso een zaak die je moet uitproberen op een testomgeving om te zien A) of het kan en B) wat de gevolgen zijn voor je omgeving.

Op 30-01-2012 10:53 schreef PgVincent www.yapf.net:

Jij met je SAN :-)

:p

Quote

Wat jij groot en klein vindt wordt vrijwel helemaal bepaald door jouw ervaringen. Jij werkt met gigantische machines dus voor jou is 16GB helemaal niets. Ik werk met servers die niet meer dan 4GB RAM aan kunnen, en dan is een DB van 2GB al een uitdaging.

De goedkoopste Dell, een R210 als ik het goed heb, kan al 16GB aan en kost maar een paar honderd euro. Vrijwel ieder PC moederboard kan dit al aan. Nieuw spul moet dit aankunnen, met ouder spul heb je de beperking van dat jaartal.

Quote

De goedkoopste Dell, een R210 als ik het goed heb, kan al 16GB aan en kost maar een paar honderd euro. Vrijwel ieder PC moederboard kan dit al aan. Nieuw spul moet dit aankunnen, met ouder spul heb je de beperking van dat jaartal.

Dat het te krijgen is betekent niet dat het ook te benutten is. Als je hoster het niet levert ben je uitgepraat. En begin dan niet over zelf hardware kopen om te gaan co-locaten, dat is nog veel duurder en risicovoller.

Anyhoes, terug on-topic maar weer. :-)