VNC stopt er mee :(
Back-Up website
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.
Het kan anders ook nog handig zijn om te kijken naar cluster oplossingen die doordat beide databases in een cluster zitten door je database zelf gelijk getrokken worden. Dit is wel lastig met shared hosting.
We kunnen dan simpel door DNS records aan te passen door gaan op de andere server.
Gewijzigd op 01/01/1970 01:00:00 door Robert Deiman
De tweede oplossing die je aandraagt zou dan een goed alternatief zijn, ik zou het alleen iets anders aanpakken. Het CSV bestand enkel uploaden naar de default server en deze daar met een unieke naam gewoon laten staan. Op de backup server draai je mbv een cron job met regelmatig interval een PHP script dat die CSV bestanden controleert. In de database zou ik dan de namen van reeds geimporteerde CSV bestanden opslaan zodat je kunt zien of er nieuwe CSV bestanden bij gekomen zijn op de default server en zo ja, deze natuurlijk importeren.
Het hangt er een beetje vanaf hoe groot de CSV bestanden zijn en met wat voor interval deze geupload worden of er teveel dataverkeer gegenereerd wordt. Zo ja, overweeg dan bijvoorbeeld om het CSV bestand wel twee keer te uploaden maar over het algemeen heeft dat niet mijn voorkeur. Liever 1 bestand op 1 locatie, dan twee (mogelijk) dezelfde bestanden op verschillende locaties ;-)
Is dat niet bereikbaar?
Is dat effectief uitgevallen?
En ook over welke server heb je het dan?
De fileserver, databaseserver, webserver, ... ?
Ondanks dat je de TTL van een domein op 3600 zet kan het zomaar zijn dat DNS servers van, bijvoorbeeld, ISP's een langere TTL aanhouden voor eerder opgezochte domeinen die in een lokale database staan (soms wel tot 24 uur!).
Gevolg: je site gaat plat, je veranderd de DNS en de gebruiker komt nog steeds op de server die plat is.
Vervolgens gaat je site weer online en is net de lokale DB van die ISP vernieuwd en komt de bezoeker nog 24 uur uit op de back-up server (dat is niet zo'n groot probleem).
De forward server kijkt of je hoofdserver online is, als dat niet zo is dan word je doorverwezen naar de backupserver.
Die CSV bestanden worden dagelijks geüpload en zijn per stuk ongeveer 5 Mb groot. Beide servers zijn zowel DB als File (hosting) server, waarbij de 1e een shared hosting account is.
Na verwerken van de CSV wordt die in 1e instantie hernoemd naar CSV.old waardoor het verwerkingssysteem hem niet meer opnieuw in gaat lezen. Dat gebeurt op de eigenlijke server in elk geval. Wat jij aandraagt kan ook, maar: Voor het verwerken van een CSV zal de shared server hem toch binnen moeten halen? Dus voor dataverkeer e.d. maakt het niet uit of ik dat met upload doe, of vanaf de originele locatie toch?
@Hipska
Wanneer de server offline is is die van buitenaf niet bereikbaar. We hebben van de week 2x problemen gehad in het datacentrum (iets met een switch is mij verteld). Daarom wouden we buiten het datacentrum op onze shared hosting een schaduwkopie van de website draaien, zodat we bij problemen deze kopie aan kunnen schakelen.
Offline == niet bereikbaar, maar kan ook zijn dat de server offline is of kapot..
@Klaasjan
Ik weet dat dat kan, maar instellingen e.d. worden Niet meegenomen naar shared hosting, terwijl VMware die wel kopieert. Toch bedankt voor het meedenken misschien dat het wat is.
@Elwin
Ik weet dat je dan nog afhankelijk bent van een provider voor wat betreft DNS, wij hebben onze DNS records bij TransIP (evenals domeinen) en daar staat de TTL op 5 minuten. De website zal dan wel niet door iedereen meteen gevonden worden, maar door een deel in elk geval wel.
Natuurlijk zullen we eerst contact opnemen met de hoster/ het datacentrum over de aard van de problemen en de tijd die ze (denken) nodig te zijn het op te lossen.
Dat die nog uitkomt op de Back-Up server is verder niet zo'n groot probleem, alles heeft een tijdstempel en kan met die tijdstempel ook later nog worden bijgevoegd in de database. We houden op de back-up server precies bij welke toevoegingen/ aanpassingen en aanmeldingen er zijn geweest.
De CSV bestanden verwerken we Wél altijd op de eigen server, vandaar ook deze vraag.
@tim
Zie reactie van Eddy Erkelens, je bent dan nog geheel afhankelijk van die ene server, en daar willen wij juist vanaf.
@Allen
Bedankt voor jullie reacties, ik ben wat verder aan het kijken geweest en ik kan van de DB een back-up maken, die ongeveer 30mb groot is (volledig gezipt als tar.gz) Deze kan ik bijv. 1keer per week uploaden/ verwerken op de backup server. Het gaat er daarbij om dat de boel redelijk actueel is, maar helemaal bij hoeft die niet te zijn, er staat ook een melding op met wanneer de boel is bijgewerkt.
Misschien dat dat een oplossing is, maar die 30Mb is +- gelijk aan het uploaden van 7 * 4.6Mb, dus misschien dat we dat wel doen, om de database steeds gelijk te houden. Een paar kleine aanpassingen/ toevoegingen en ook de overige acties worden op de back-upserver weggeschreven. (misschien doen we dat nog wel met een bestand waarin we alle wijzigingen bijhouden, zodat we die indien nodig snel kunnen verwerken op de backup server (bestand wordt automatisch per mail verzonden) en de csv bestanden gewoon live verwerken.
We zien wel, maar we gaan er in elk geval uitkomen.
Het heeft alleen wat aandacht nodig.
Zelf heb ik het een keer zo gemaakt dat als de ene server niet reageerde dat hij direct overging op de andere, Hij haalde dan de laatste gegevens op en runde gewoon door zonder dat je er wat van merkte.
Ondertussen werd er gecheckt of de andere server alweer on was.
Toen vonden we een oplossing dat we 2 servers aan elkaar konden laten verbinden.
De query's die uitgevoert werden werden doorgestuurt naar server 1 en daar doorgestuurt naar server 2 in een soort wachtrij..
Als server 2 dan teveel query's had staan... zette server 1 die in de wacht en voerde die de query's uit als de andere klaar waren.
Ook hielden wij rekening met het ophalen van gegevens.
Dus gingen we ervanuit dat de database altijd 0.3 zoog aan gegevens ophalen zodat daar ook niks mis mee kon gaan.
Dit klinkt misschien allemaal een beetje ingewikkeld.. Maar heb het zo makkelijk mogelijk uitgelegt.
Als u belang heeft bij dit systeem kan ik de informatie voor u opzoeken van hoe en wat. waar wij deze ook vandaan hebben gehaalt.
hier kunt u dan een prive bericht voor sturen.
Het systeem zelf heb ik helaas niet meer in bezit omdat ik toen alles verkocht heb.
@Felix
Wat jij bedoeld met Master/ Slave gaf ik al aan in de beginpost. Dat is het probleem met Shared hosting, die database stellen ze niet zomaar zo in.
'Tim:
Opzich is dit niet zo heel moeilijk.
je hebt me wel zeer niewsgierig gemaakt!
'Tim:
Ik ga morgen even voor je opzoeken
maar hoe lang laat je mij nog in spanning wachten de dag is zo wat om :(
Gewijzigd op 01/01/1970 01:00:00 door RvW Of toch niet
Dit is wellicht iets duurder; maar backupsystemen schrijven; zelf je dns omgooien e.d. kost ook tijd - en manuren zijn niet goedkoop.
2. Dit is natuurlijk een flauw antwoord dus misschien een suggestie hoe het zou kunnen werken.
Gebruik rsync
Rsync kan heel efficient bestanden overzetten. Alleen de bestanden die veranderd zijn tov de vorige keer dat je een rsync gedaan hebt zullen worden overgezet - en dan alleen de gedeelten van dat bestand dat veranderd is. Dus als je csv bestanden of SQL dumps redelijk gelijk zijn is rsync misschien wel een winner; in principe worden van een dump alleen de delen die veranderd zijn overgezet - en niet wat in de vorige dump.sql staat.
De workflow is dan alsvolgd:
1. maak een dump van de productie sql
2. rsync
3. dump de oude oude database op de backup
4. restore de nieuwe versie van de productiesql op de backup
3. Heb je master-master synchronisatie nodig? (dwz; moeten er aanpassingen mogelijk zijn op de backup of is de backup read-only?) Dit maakt het een stuk eenvoudiger - anders krijg je behoorlijke hoofdpijn als er zowel op de productie als op de backup verschillende veranderingen mogelijk zijn. In zo'n geval zou je bijna op mysql niveau master-master synchronisatie toe moeten passen en dat is niet binnen je shared hosting accountje mogelijk waarschijnlijk.
Ik hoop dat je er iets aan hebt.
Maar toch post ik ff een linkje!
http://rsync.samba.org/