Sql synchronisatie

[jbdeiman]

Ik werk momenteel aan een grote website, waarbij heel sterk wordt geleund op de SQL database. Nu is het geval dat we elke dag (middels een CSV bestand die uit een programma komt) updates doorvoeren in die database.
In de afgelopen week is de server (wegens problemen in het datacenter) 2 keer offline geweest, waarvan de 1e keer een dag (bijna) en de 2e keer vandaag, welke overigens vrij snel weer opgelost was.

Nu willen we ervoor zorgen dat we middels de DNS instellingen (deze regelen wij zelf) over kunnen schakelen naar een 2e pakket, welke gewoon op shared hosting daait. (omdat we er alleen in het geval van storingen gebruik van willen maken)
Nou willen we eigenlijk bereiken dat de data in de database op de Back-Up server gelijk wordt getrokken (gesynchroniseerd met een mooi woord) met die van het origineel. Nou mijn vraag:
Is dat synchroniseren eenvoudig te doen, of gaat dat heel lastig? Hoe zit het met grote hoeveelheden dataverkeer die evt. ontstaan bij het over- en weer synchroniseren (database is nu een dikke 200Mb groot en wordt elke dag groter) van de data in de database?

Een andere oplossing is om de upload zowel naar onze eigen server als die shared hosting te doen (is ong. 5 Mb per dag) en middels een cronjob het bestand te verwerken en hernoemen/ wissen, zodat dat bestand maar 1 keer verwerkt kan worden?

Ik zat zelf te denken dat de 2e oplossing de handigste is, maar misschien hebben jullie daar een ander (beter) beeld van hoe dat in zijn werk gaat. Het is voor mij de 1e keer dat ik met zoiets in aanraking kom.

[BtM909]

SQL database? Welke precies

Daarnaast is je probleem niet zozeer passend in WEB, maar in andere subfora. Als je nog even aangeeft over welke database je het precies hebt, dan moven we je topic naar een betere plek

[jbdeiman]

MySQL is de betreffende database. Ik dacht niet dat dat zoveel uit zou maken, vandaar dat ik het niet noemde.

[jeroenikke]

http://dev.mysql.com/doc/refman/5.0/en/replication.html

[jbdeiman]

Dank, dat is weer voldoende leesvoer denk ik de komende uren..:) Ik ga daarmee aan de gang en zal jullie laten horen of het werkt/ lukt/ mogelijk is met wat ik heb.

[BtM909]

jbdeiman schreef op vrijdag 05 juni 2009 @ 14:12:
MySQL is de betreffende database. Ik dacht niet dat dat zoveel uit zou maken, vandaar dat ik het niet noemde.

Tuurlijk wel, hoeveel soorten databases zijn er denk je die SQL lusten Elk platform heeft weer andere mogelijkheden tot synchroniseren

Ik verplaats dit topic naar PRG, omdat daar op dit moment enorm veel kennis rondloopt over MySQL

[jbdeiman]

Goed, ik heb wat rondgeneusd en gelezen en nu maar de vraag aan de shared hosting provider gesteld of het daar mogelijk is om (voor de Replication) de Database als Slave in te stellen. Ben benieuwd of dat kan, dat zou wel de mooiste oplossing zijn.

natuurlijk sta ik ook open voor andere oplossingen, dedicated hosting is geen optie, omdat we niet met 2 eigen servers willen draaien.

[BBrunekreeft]

Zoek op deze site even de "SQLyog Job Agent (SJA) for Linux" op.
Met dat tooltje kun je (eventueel i.c.m. een cron job) de database synchroniseren naar een eigen lokale kopie.
Gebruik het zelf ook, en het werkt heel aardig (en snel)

[jbdeiman]

@Bbrunekreeft
Volgens mij heb je het niet helemaal begrepen? Het is de bedoeling dat we van die website een kopie draaien op een shared hosting pakketje, waarbij we de SQL database (MySQL dus) gelijk willen hebben en houden met de dagelijks bijgewerkte database op de originele server.
Het moet dus niet gesynchroniseerd worden naar een lokale kopie, maar juist online gebeuren.

[cariolive23]

database is nu een dikke 200Mb groot en wordt elke dag groter

Dat is gelukkig nog microscopisch klein, de omvang mag geen problemen geven.

1) Ga een beter datacenter uitzoeken, dan kun je afscheid nemen van het center dat problemen geeft.
2) Replicatie, is reeds genoemd, ga je daar eens in verdiepen. Zoek wel uit welke vorm van replicatie je nodig hebt en ga dit heel erg goed testen!!! Je zult niet de eerste zijn die dankzij replicatie uiteindelijk met diverse corrupte/onbruikbare databases blijft zitten... Dan ben je nog veel verder van huis.
3) Is het alleen de database die op meerdere locaties moet staan, of moet je ook code en plaatjes synchroniseren?

[BBrunekreeft]

jbdeiman schreef op vrijdag 05 juni 2009 @ 15:08:
@Bbrunekreeft
Volgens mij heb je het niet helemaal begrepen? Het is de bedoeling dat we van die website een kopie draaien op een shared hosting pakketje, waarbij we de SQL database (MySQL dus) gelijk willen hebben en houden met de dagelijks bijgewerkte database op de originele server.
Het moet dus niet gesynchroniseerd worden naar een lokale kopie, maar juist online gebeuren.

Dan draai je de cron job en SJA op je backup server.
Kan ook

[Redshark]

Hoe je het aanpakt is nog even de vraag maar let je er ook op dat veel hostingpartijen geen externe MySQL toegang toestan?

[jbdeiman]

@Cariolive23
De omvang levert in zoverre problemen op dat we zo min mogelijk kosten willen maken om toch een backup te kunnen draaien. Dat betekend tevens dat we het dataverkeer zo laag mogelijk moeten en willen houden. Elke dag een maand lang meer dan 200 Mb (en met een maand zo'n 300 Mb denk ik, misschien iets minder of meer) uploaden betekend al een hoeveelheid dataverkeer van meer dan 6 gyg (vooral wanneer we een paar maand verder zijn, het systeem moet future proof zijn, dan komen we aan nog veel meer dataverkeer als we echt steeds de hele database dumpen)
Vandaar dat ik vraag om een oplossing hiervoor.

1) Helaas hebben we een VPS tot onze beschikking, waarop we dus wel onze instellingen kunnen wijzigen e.d., maar het ding niet fysiek verplaatsen.
2) Op onze server zelf heb ik een 2-tal kopieën van de database staan (echte kopieën, waardoor het een kwestie is van een andere database selecteren in de config file en alles draait helemaal)
3) De rest synchroniseren lukt al wel en is al geregeld, het gaat nu alleen om de database. Ik heb net echter contact gehad met een (eventuele) provider, maar die geeft aan dat replicatie niet gebeurt op shared hosting. In elk geval niet bij hun, iemand die een provider weet waarbij dat wel kan?

@Bbruneskreeft
Zoals ik al aangaf willen we liefst op een shared hosting, omdat dat goedkoop is, verder prima (kan voldoen) voldoet om tijdelijk in te springen bij problemen, puur voor noodgevallen, zodat de site zoveel mogelijk in de lucht blijft, of op zijn minst kan blijven.
Met shared hosting gaat jou oplossing niet werken, maar toch bedankt voor het meedenken.


@Redshark
Dat is dus precies waarom het zo'n probleem vormt met het maken van een backup. We hebben al een account ergens bij zo'n hoster (daar zijn we begonnen) waarmee we dus de back-up willen regelen.

[ Voor 18% gewijzigd door jbdeiman op 05-06-2009 15:38 ]

[cariolive23]

Elke dag een maand lang meer dan 200 Mb (en met een maand zo'n 300 Mb denk ik, misschien iets minder of meer) uploaden

Dat is dus géén replicatie, maar gewoon een backup van server A naar server B sturen. Dat is totaal wat anders en absoluut niet vergelijkbaar met database replicatie. Vergeet deze term, zorgt voor heel erg veel verwarring.

Wanneer je database replicatie toepast, krijg je alleen dataverkeer van de veranderingen in je database en niet van data die er reeds in staat. Tuurlijk, eenmalig moet je beginnen met een baseline, er is een moment waarop je de huidige 200 MB moet importeren in de andere database. Maar dat doe je slechts 1x.

Het dataverkeer valt bij replicatie wel mee, mits je niet overdreven veel wijzigingen in je database hebt.

Wanneer je dagelijks een backup naar de andere server wilt sturen (en dus GEEN replicatie wilt toepassen), ga je de backup uiteraard comprimeren, scheelt een flinke lading dataverkeer. Met deze aanpak kun je echter wel 24 uur achter de feiten aanlopen en dus data verliezen.

Maar, wat wil je nu precies? Backupjes heen en weer sturen of databasereplicatie?

[jbdeiman]

Ik wil eigenlijk databasereplicatie, maar de shared hosting ondersteunt dat dus niet. Vandaar dat we verder proberen te kijken naar een andere (simpele) oplossing. Maar zoals ik al zei is dus die optie voor steeds 200mb uploaden niet reëel. Vandaar ook dat ik met 't probleem zit zoals hier was geschetst.

Ik wil eigenlijk replicatie, maar gezien de shared hosting provider dat niet ondersteunt, moeten we dat op een andere manier doen....

[cariolive23]

maar de shared hosting ondersteunt dat dus niet.

Duh!!! Wat had je dan verwacht? Vaak krijg je niet eens externe toegang tot een database, toch wel handig wanneer je denkt aan replicatie.

Wanneer replicatie afvalt en je geen externe toegang krijgt tot jouw database, dan is er eigenlijk geen andere optie dan ftp. Een webservice zou ook nog kunnen, maar dat lijkt mij totaal niet geschikt.

Wat je zou kunnen doen, is een bestand opbouwen me alle INSERT, UPDATE en DELETE queries die je uitvoert en deze eens per X tijd uploaden naar de andere server. Daar pak je de bestanden op die in de queue staan en je voert de verschillende queries in de juiste volgorde uit. Uiteraard kun je ook een CSV bestand aanmaken met de juiste opdrachten, net wat jij handiger vindt. Ga de boel wel even comprimeren voordat je gaat uploaden, scheelt in het dataverkeer.

Wat ga je trouwens doen wanneer server A uitvalt, jullie server B activeren en vervolgens server A weer moet worden gebuikt? Hoe ga je de nieuwe/gewijzigde data van server B in server A krijgen? Daar moet je ook nog een mechanisme voor hebben.

[jbdeiman]

@cariolive23
Hetzelfde eigenlijk als bij data van A naar B krijgen. We draaien de boel naast elkaar, zetten de gegevens over naar B, activeren B (de "datacontainer" van A waarin wijzigingen bijgehouden worden maken we eerst even leeg) wanneer B actief is (duurt dus heel even) kijken we weer bij A of er nog wat veranderd is. Alle data heeft een datetime stempel, dus B weer bijwerken is maar een kleinigheidje.

[cariolive23]

Alle data heeft een datetime stempel

Die gaat in MySQL tot op de seconde nauwkeurig, hoeveel queries kun je per seconde ook al weer uitvoeren? Die stempel is dus niet betrouwbaar, het is niet nauwkeurig genoeg. Vooral met meerdere updates van 1 record kun je in de problemen komen.

bijwerken is maar een kleinigheidje.

Ik hoop het voor je, ik verwacht het alleen niet, zeker niet omdat je geen replicatie toepast. Ga dit eerst maar eens heel goed testen. Je hebt namelijk een grote kans dat er data op server A staat die nog niet in server B staat, server A onbereikbaar wordt en server B de boel gaat overnemen en server B weer andere data gaat bevatten. Nu zit je met 2 servers die beide data bevatten die op de andere server niet aanwezig is. Dat kunnen ook updates zijn van records die eigenlijk wel op de andere server hadden moeten staan. Hoe denk jij dit recht te trekken? Zelfs met replicatie (master-master, die situatie heb je nu) is dit een lastig probleem. Wanneer je daar nog nooit mee te maken hebt gehad, dan is dit zeker geen kleinigheidje. Of is het acceptabel dat je data kwijt raakt? Dat maakt de boel wel 100x eenvoudiger, dan gooi je de zooi van server A weg en zet je de data van server B daarin. Probleem opgelost, maar wel wat data verdwenen.

Ik zou eerst maar eens zorgen voor een goed bereikbare server, dat is vele malen eenvoudiger dan zelf het wiel uitvinden met een soort van replicatie/synchronisatie.

Edit: Zonder replicatie wordt het toch al een probleem, hoe wil je een UPDATE op server B uitvoeren wanneer het betrokken record nooit is aangemaakt op server B? INSERT op server A, server A valt weg voordat deze data op server B staat, UPDATE op server B: Deze zal keurig mislukken... En dan? Dat kan uiteraard ook met een DELETE op server A die nooit op server B is verwerkt. Het record dat ten onrechte niet op server B is verwijderd, kan echter wel invloed hebben op overige data op server B wanneer server B online is.

Advies: Ga gewoon met backups werken en vergeet het idee van replicatie zonder echte replicatie. Dat is gedoemd te mislukken en daar kom je achter op het moment dat je het nodig hebt. Beetje zonde van de tijd die je er nu insteekt, die kun je beter besteden aan een verhuizing naar een betrouwbare provider.

[ Voor 22% gewijzigd door cariolive23 op 05-06-2009 16:48 ]

[jbdeiman]

cariolive23 schreef op vrijdag 05 juni 2009 @ 16:38:
[...]
Die gaat in MySQL tot op de seconde nauwkeurig, hoeveel queries kun je per seconde ook al weer uitvoeren? Die stempel is dus niet betrouwbaar, het is niet nauwkeurig genoeg. Vooral met meerdere updates van 1 record kun je in de problemen komen.

Back-ups hebben we al draaien, dus veel raken we nooit kwijt. De server zelf is over het algemeen goed te bereiken, maar bij problemen in het datacenter willen we gewoon een mogelijkheid hebben de boel over te zetten.
Bij het systeem is het niet waarschijnlijk dat in eenzelfde seconden hetzelfde record wordt bijgewerkt, dat heeft met het soort systeem te maken, maar bij deze maakt dat verder niet uit. Als alles op de volgorde wordt ingevoerd zoals in het "update.sql" bestandje, dan klopt alle data verder. Dat heb ik wel eerst bekeken voor ik de vraag stelde.
Ik ben al bezig aan een systeempje dat vanaf een andere server (2 verschillende) kijkt of die de website nog kan bereiken. Lukt dat niet, dan probeert die het 5 min later nog eens (anders elk uur) en wanneer die dan ook niet te bereiken is krijg ik een sms dat de server down is. Zijn we er toch nog vroeg bij.